For developers who have to live with an enterprise that has legacy and component architecture-based applications, here is a way to introduce SOA in a manner that is not too disruptive. SOA can be leveraged to preserve business logic investments made within component architecture-based systems while incorporating a better and more standards-based infrastructure.
This article will show you how the two concepts of Component Architecture and Service Oriented Architectures (SOA) might fit together within an environment without having to decommission all the work done using the principles of component architecture. The premise of SOA is to not have developers adopt a rip and replace philosophy to upgrade mission critical systems but to make those systems more accessible to business users and make them easier to maintain.
The Tenets of Component Architecture
First, here is a brief recap of the tenets of component architecture that are still applicable to the SOA paradigm. These include constructs such as the separation of the top-level interface from the implementation, use of standardized protocols to transmit messages from the component, having access to robust plumbing and integration utilities available in standardized application server containers, and so forth. All of these made the component architecture programming model more efficient and less error-prone.
However, a major limitation of the component-based distributed architecture implementation was that components were syntactically bound to specific implementation languages. This language dependence forced the providers and consumers to come to a design-time agreement on the message formats/parameters being shared and the component interface code fragment being called to make the "remote call," thus forcing component-based interactions to become tightly coupled.
SOA Enters the Picture
SOA now builds upon these concepts by standardizing not just the protocols and integration plumbing but also leveraging platform and language-independent representations of the message formats (XML) that enable the provider and consumer to be implemented in a language-agnostic manner. Further, standardizations of the wire-format and transmission technologies allow the tool vendors to offer service authoring and service deployment utilities. Table 1 summarizes some of the obvious distinctions between the two models of distributed architecture.
Table 1: Distinctions between the two models of distributed architecture
|Typically used to create a service façade that expresses a business interface to a common enterprise-worthy business function, business activity, or a business process
||Typically a good choice for a service implementation layer wherein the business behavior advertised on the service façade has to be aligned with the internal representation of the business information available to the enterprise|
|Synchronous and asynchronous interaction model support allows cross-platform and language-agnostic interactions
||Message Oriented Middleware usage that transmits a standardized message is the only way to achieve platform and language neutral interactions|
|Leverages a platform, vendor, and technology agnostic transmission protocols such as SOAP
||Leverages technology-specific RPC transmission protocols|
|Allows loose coupling by trading XML representation of business objects and not just language-dependant objects
||Tightly coupled to trading business objects and/or value objects|
|Use of XML Schema based documents allow one to deal with service versioning
||Object parameters being traded may or may not be able to deal with versioning changes without breaking the entire communication/execution path|
|Infrastructure components such as ESB are standards based to support service call routing and mediation.
||Message Broker is the key infrastructure component used to route calls when business messages are published from a component|
|Leverages standardized SOAP-based encoding to instruct infrastructure components on how to handle message delivery, message reliability, transaction support, and other run-time behaviors
||Does not offer standardized SOAP-based encoding to instruct infrastructure components on how to handle message delivery, message reliability, transaction support, and other run-time behaviors. Application server technology and vendor-specific deployment descriptors are the closest representations to achieve configuration-based Quality of Service encoding|
|Supports Service Repository and Service Registry concepts for defining and publishing service usage semantics
||Supports concept of Service Discovery and Late binding|
|Adapters to various technologies and platforms are available to express legacy assets as reusable web services
||JCA adapters have to be provided for business application translations but not for technologies|
|Enables service composition to allow new business offerings
||Cross-technology service chaining is not possible|
SOA-style services primarily have a published interface and a more protected service implementation. The reason for this is to separate the public view of the service—the "service interface"—from the more volatile view of the service-based business logic that is embedded in the "service implementation." This way, the consumers of the service are insulated from any changes to the service implementation as long as the service interface has remained intact.
The service interface consists of one or more service operations. Each of these is a business-oriented method signature that consists of the following:
- Method name or service operation name
- Parameter or message
- Return type or message
- Exception or fault raised during the execution of the business behavior
This is what comprises a business-friendly service façade and has other quality of service aspects encoded into it to make up the service contract that is expressed as WSDL operations. The service interface encapsulates XML message formats and the business syntax, all of which can be validated by XML Schemas. The advantage is that a well-defined SOA style service offers the ability to advertise this business behavior that provides the capability for dynamic discovery.
On the other hand, the service implementation consists of the core business rules, the business data manipulation logic, and the call processing logic that may be encapsulated in some form of an RPC-based technology. As noted earlier, this separation of interface and implementation allows loose coupling of the service consumers and the service providers and, most importantly, allows one to continue using prior IT investments. It also allows developers to reuse well-tested and performance-tuned business logic embedded in these components, thus reducing the risk of introducing a new technology to an enterprise without being too disruptive.
Click here for a larger image.
Figure 1: Components in action in the realm of SOA
Having briefly learned about both these models of distributed architectures, you can explore how both of these fit. SOA can be considered a mechanism to create a "façade" over legacy and/or component business logic that allows aspects of business-relevant behavior to be exposed. This facility enables the reuse of "proprietary business logic" that offers an enterprise a competitive advantage while still exposing them in a business-friendly and easy-to-understand fashion. SOA-style services also may use components to augment/extend business logic upon raw business data that may be trapped in legacy systems, again externalizing existing behavior and information in business syntax.
In addition, SOA-style services hold the promise to enable reuse of business rules and business information that are applicable in multiple contexts. The information in the service could be specialized by an application or made more consumer-context specific. Contextual rules and behaviors are added on via composite applications or portals or within business processes that augment the core business service.
A Working Example
For example, consider a Customer and Customer Account service. Here, the service could expose behaviors that are encapsulated in components that return Customer Information, Customer Account Information, Customer Profitability, and Customer Purchase History components, thereby leveraging business logic investments already made by the enterprise. Also, the enterprise could reuse information sources that may have been part of pre-existing service arrangements such as subscriptions to Credit Bureau processes that evaluate customer credit scores that assess customer profitability and/or project customer risk factors.
The Customer and Customer Account service could encapsulate customer information regardless of whether the customer is a banking, loan, or credit card customer—allowing the service to be used in any one of these many contexts to offer other functionality such as credit limit extensions or for offering additional financial instruments or for consolidation of financial accounts. These contexts could be applied via composite applications that are used by customer service agents or help desk portals or through business processes such as the home equity loan processes.
Finally, a note on how SOA benefits from the existence of core infrastructure utilities such as the UDDI Registry, Service Repository, and the Enterprise Service Bus (ESB), all of which have enabled SOA to evolve into a more powerful distributed architecture model when compared to the component architecture. SOA-based service publication and discovery components, such as UDDI Registries and Service Repositories, allow dynamic registration of and interaction with these services, setting it apart from component architecture where interactions are mostly defined at design time.
If these registries and repositories are tools for service advertising, the Service Bus is considered to be a tool for service mediation and service authoring features that result in end-point location transparency and technology transparency. ESB vendor products feature web-service code authoring capabilities that allow wrapper services to be created for legacy implementations, thus facilitating their participation in the enterprise in the guise of first-class SOA service citizens. It is these development utilities and tools that have helped sell SOA as a speed to market capability. They enable the creation of a "service layer" that encapsulates calls to existing enterprise IT assets and intellectual property in the form of core business knowledge.
All of this run-time interaction is possible only due to the existence of platform and technology neutral standards such as web services, XML, UML, and so on, and most importantly due to the fact that a business interface definition is created by business users who are looking to represent standardized business interactions in business syntax and not as cryptic code. It must be understood that the business users are able to model the business using business semantics that the SOA tools are able to codify into a business interface using WSDL and XML. This standardization in the expression of the business interface facilitates the automation process for registering the "service definition" in a platform, vendor and a language-agnostic manner that promotes on-demand service discovery and usage by business users!!
In conclusion, I would like to emphasize that SOA has the potential to elevate the business users' experience with business applications from one where the usage is driven by the developer to one that where the usage is driven by the business user. For this benefit to be realized, however, the right investments have to be made in the analysis of the existing business components to help tie these back to commonly used business information needs that then are expressed using business-oriented service interfaces. This effort then could yield the true benefits of SOA, which is to promote consistent usage of business information across multiple business contexts or business units across the enterprise.
About the Author
Surekha Durvasula is an Enterprise Architect who has had 12 years' experience in designing and architecting a variety of enterprise applications in the financial services sector and the retail industry vertical. Most of her work has been in the area of distributed N-tiered architecture, including J2EE component architecture. Her more recent focus has been on Service Oriented Architecture, Information Architecture, and Business Process Management. Her efforts as an Enterprise Architect involve not only architecting new applications and business services but also in leveraging the principles of SOA to extend the life of existing Enterprise Information Systems.