Overview
In an event driven enterprise, business event affecting the overall business process can occur in any order and any time. Applications that exchange data in automated business processes need to communicate with each other using an event driven architecture. An event driven SOA (Service Oriented Architecture) provides integration architect an abstract view of applications and integration components to be dealt with high level services. In SOA, applications are loosely coupled with each other. These applications can operated independently.
The common goal of various technologies like SOA, EAI (Enterprise Application Integration), B2B (Business To Business) and web services is to integrate desperate applications that can be pervasive across an extended enterprise and beyond.
SOA Defined
OASIS (the Organization for the Advancement of Structured Information Standards) defines SOA as the following:
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
When coupled with "architecture," service-orientation takes on a technical connotation. "Service-oriented architecture" is a term that represents a model in which automation logic is decomposed into smaller, distinct units of logic. Collectively, these units comprise a larger piece of business automation logic. Individually, these units can be distributed.
Let’s take an example of an average town. Individual companies are service-oriented in that each provides a distinct service that can be used by multiple consumers. Collectively, these businesses comprise a business community. A business community need not be served by a single business outlet providing all services. By decomposing the community into specialized, individual outlets, we achieve an environment in which these outlets can be distributed. Even in a distributed business community, if we impose overbearing dependencies, we could inhibit the potential of individual businesses. Although we want to allow outlets to interact and leverage each other's services, we want to avoid a model in which outlets form tight connections that result in constrictive inter-dependencies. By empowering businesses to self-govern their individual services, we allow them to evolve and grow relatively independent from each other.
This example gives two important points about SOA viz.
- SOA is different than Distributed Computing/Architecture because in later distributed components are dependent on each other while SOA allows autonomous existence of individual services.
- Units of logic are still required to conform to a set of principles that allow them to evolve independently, while still maintaining a sufficient amount of commonality and standardization. Within SOA, these units of logic are known as services.
Services defined
How services encapsulate logic?
A Service is encapsulation of business logic. The concern addressed by a service can be small or large. Therefore, the size and scope of the logic represented by the service can vary. Further, service logic can encompass the logic provided by other services. In this case, one or more services are composed into a collective.
How services related?
Within SOA, services can be used by other services or other programs. Regardless, the relationship between services is based on an understanding that for services to interact, they must be aware of each other. This awareness is achieved through the use of service descriptions. Services are related with each other using service description. A service description in its most basic format establishes the name of the service and the data expected and returned by the service. This provides information about where the service is running, what are the inputs expected by the service and what are the outputs expected as a result of the Service Call.
The manner in which services use service descriptions results in a relationship classified as loosely coupled.
How service communicate?
SOA is based on messaging. A Service communicate with external world using messages. Messages are independent units of communication. These messages are XML messages. After a service sends a message on its way, it loses control of what happens to the message thereafter. That is why we require messages to exist as "independent units of communication." This means that messages, like services, should be autonomous. To that effect, messages can be outfitted with enough intelligence to self-govern their parts of the processing logic.
Services that provide service descriptions and communicate via messages form a basic architecture. So far, this architecture appears similar to past distributed architectures that support messaging and a separation of interface from processing logic. What distinguishes ours is how its three core components (services, descriptions, and messages) are designed. This is where service-orientation comes in.
Services Designed
How to design a service?
This is most important question in SOA. Following picture depicts the design considerations/issues related to a service.
Service Oriented Design Principles
- Loose coupling Services maintain a relationship that minimizes dependencies and only requires that they retain an awareness of each other.
- Service contract Services adhere to a communications agreement, as defined collectively by one or more service descriptions and related documents.
- Autonomy Services have control over the logic they encapsulate.
- Abstraction Beyond what is described in the service contract, services hide logic from the outside world.
- Reusability Logic is divided into services with the intention of promoting reuse.
- Composability Collections of services can be coordinated and assembled to form composite services.
- Statelessness Services minimize retaining information specific to an activity.
- Discoverability Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms.
How services are built?
All major vendor platforms currently support the creation of service-oriented solutions, and most do so with the understanding that the SOA support provided is based on the use of Web services. Web Services can be written in any language and can be called from any platform/language. The most important aspect is web services written in different languages can communicate with each other without any issue as service requested needs only the service description to call another web service.
How Service Oriented Principles related with each other ?
Following diagrams explain the interrelations between SOA design principles in most simplistic manner.
Service Reusability:
Service Contract:
Service Loose Coupling:
Service Abstraction:
Service Composability:
Service Autonomy:
Service Statelessness:
Service Discoverability:
Thus one the SOA design principle makes sure other principles are followed while creating a Service Oriented System.
In larger organizations where various IT projects occur concurrently, the need for custom standards is paramount. If different development projects result in the creation of differently designed applications, future integration efforts will be expensive and potentially fragile. This is a lesson many IT departments have already learned through past legacy nightmares.
In larger organizations where various IT projects occur concurrently, the need for custom standards is paramount. If different development projects result in the creation of differently designed applications, future integration efforts will be expensive and potentially fragile. This is a lesson many IT departments have already learned through past legacy nightmares.
Standards organizations that contribute to SOA
There are various organizations which contribute to evolution of SOA principles/guidelines viz.
The World Wide Web Consortium (W3C)
Organization for the Advancement of Structured Information Standards (OASIS)
The Web Services Interoperability Organization (WS-I)
| W3C | OASIS |
WS-I
| |
| Established | 1994 | 1993 as the SGML Open, 1998 as OASIS | 2002 |
| Approximate membership | 400 | 600 | 200 |
| Overall goal (as it relates to SOA) | To further the evolution of the Web, by providing fundamental standards that improve online business and information sharing. | To promote online trade and commerce via specialized Web services standards. | To foster standardized interoperability using Web services standards. |
| Prominent deliverables (related to SOA) | XML, XML Schema, XQuery, XML Encryption, XML Signature, XPath, XSLT, WSDL, SOAP, WS-CDL, WS-Addressing, Web Services Architecture | UDDI, ebXML, SAML, XACML, WS-BPEL, WS-Security | Basic Profile, Basic Security Profile |
Conclusion
SOA is still evolving. We don't find many case studies around SOA but SOA will mature eventually considering the huge long term benefits. SOA doesn't give any quick or short term Return on Investments. As the organization grows, various desperate applications come in use which need to communicate with each other. If initially organization builds tightly coupled interfaces then in the long run, these turn into maintenance nightmares. Hence sooner the organization adopts SOA principles better to reduce IT expenditures on maintenance.
References
Theory In Practice- Enterprise Service Bus - O'reilly Publications -Author: David Chapell
Java Web Services Architecture -Morgan Kaufmann Publishers- Authors: James McGovern,Sameer Tyagi, Michael Stevens and Sunil Matthew
Apps2Fusion Articles 
Comments
RSS feed for comments to this post