The Role of Component Architecture in the Realm of Service Oriented Architectures (SOA), Page 2
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.
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.