Introduction
Service-oriented Architecture (SOA) is fast becoming one of the most important aspects of enterprise IT infrastructure architecture. It has drawn significant attention and investment from vendors and IT teams in businesses. That said, SOA is still in early stages of adoption even though SOA itself is not exactly a new innovation. The single most important reason for SOA’s failure to take off was the lack of standards and technologies supporting interoperability. With web services facilitating true platform and protocol independent communication between applications, SOA is all set to reach its true potential.
The current challenge with widespread SOA adoption is that though most people understand the ‘what’ of SOA, not many understand the ‘how’ of it. We need to get more prescriptive on how to adopt SOA in enterprise systems. It is important to assign a set of standards and reference applications to guide enterprise architects and developers in building successful SOA implementations. SOA Blueprints [1] was introduced by The Middleware Company (TMC) and BEA Systems primarily as an attempt to service this requirement, and allow developers and architects to get a feel of an SOA implementation.
Before getting into each design pattern, let us take a quick overview of what the SOA Blueprints is about, what it describes and why you should care about it.
SOA Blueprints
The SOA Blueprints is the specification of a reference application for a fictitious company called GeneriCo. It defines common terms and design patterns in a separate document and then illustrates concepts through the main specification. There are three main use cases: an enterprise-wide security service, enterprise-wide data service and employee self-service portal. The first use case shows some interesting concepts like implementing single sign-on by passing around a security token with all calls to services. It also demonstrates the integration of service-oriented security infrastructure with legacy applications using above patterns. For example, propagating updates to security infrastructure using Asynchronous Service pattern. The second use case addresses the most important aspect of enterprise integration – data sharing. In the traditional way of computing, applications are developed in silos and do not really share data. However, a good SOA would design data services to aggregate data from various enterprise resources and present it to all consumers using a unified view and a consistent data model. The final use case illustrates how a single higher level service (Composite Service pattern) implements a business workflow, interacting with new and existing enterprise services.
The idea is to create a reference application for SOA like what PetStore did for J2EE. PetStore was meant to establish portability of J2EE applications while educating the community on common J2EE patterns. Portability of SOA implementation is currently impossible as all SOA infrastructure offerings are primarily a loosely-bound collection of implementations of several evolving standards. However, it does a great job at educating community on common SOA patterns. PetStore misses that by making such a tasteless soup of design patterns in a lone application. SOA Blueprints applies specific patterns to the entire enterprise’s IT systems and not just an application. Each sub-system or application also uses some SOA patterns or can use other non-SOA patterns for its internal implementation.
SOA Design Patterns
It is important to note that web services and SOA are not synonymous. Web services is only one of the many possible enabling technologies for SOA. However, because of its strengths and limitations of other technologies, web services is the most important enabler for SOA. That is why in this article, we have used web services as an example to explain and elaborate some of the patterns. You must bear in mind that the web services are used just as an example and the patterns can be applied to other technologies as well.
Synchronicity – Synchronous and Asynchronous Services
Services can be invoked synchronously or asynchronously. If the service does not take long to run and is required to return a response to the caller, it can be implemented as a synchronous service. Asynchronous services can be used when the service takes longer, and if the client does not require immediate or no response. An asynchronous service can send response through a mechanism like callback or in response to aggressive polling. Asynchronous services are inherently more reliable, provide better performance and scalability, but are more complex. For example, sending response through callback mechanism would require sophisticated clients that support callback infrastructure and a means to correlate messages. The complexity can be reduced by the underlying infrastructure and there are ongoing efforts to standardise support for such services at infrastructure level for web services. Non-web services systems already enjoy a standardised support at platform level for synchronous/asynchronous invocations.
As discussed above, long-running services should not be implemented as synchronous services. The function of the service implementation should be divided into several service functions. First function that kicks off the service invocation must establish a conversation ID. This ID can be used by further invocation to correlation to the same service instance. The conversational service pattern described later typically uses a similar pattern and requires support from the infrastructure provider.
Asynchronous Query Pattern
When there is no platform support, or you do not want it for your simple applications, you can build your own asynchronous conversational service by using the Asynchronous Query Pattern [5]. In this pattern, you need to develop a Provider façade that keeps track of correlation across multiple invocations from the Requestor. The Processor never cares about the correlated nature of the asynchronous invocation. For web services environment on J2EE platform, the patterns look like these:
1. Requestor submits request to the Provider synchronously. The Provider enqueues the request on a queue and returns a correlation ID back to the Requestor.
2. The Processor, a wrapper around actual implementation of the service, dequeues and processes the request using the service. It then enqueues a response back on the Response queue with the same correlation ID. The same queue for response could be used if proper message selection is built in.
3. Requestor calls the Provider to check if the request has been processed and the latter returns an appropriate response.
Fig. 1: Asynchronous Query Pattern for simple conversations
It is a very simple, yet powerful pattern that can be implemented on top of standard platforms and turned into a framework that is utilised across the enterprise. Depending upon the requirements and willingness to make an investment, the framework can be easily extended to support cancellation of request processing, compensating actions, etc.
Data Services
Majority of the traditional application development projects work in silos, keeping data local to them. Most EAI projects are centered around making these data visible across applications or providing a unified view of data distributed all over. In SOA world, applications do not see data directly but through a service that abstracts the actual data organisation and access. The data could come from a variety of sources, including relational databases (accessed through JDBC, Entity EJB, or other persistence frameworks), web services, XML data stores, JMS messages, EIS or a combination of several sources. User of the service does not need to know any of these details. The data service implementation handles access and aggregation issues. The challenge, however, lies not in encapsulating these details but designing a service and a data model that serves needs of all current and future users of this service. The blueprint provides an example where product information is contained in two different databases bearing two different data models. Both databases contain same information about company’s product offering. However, the newer database holds much more information for each product and has a totally different schema. It is the responsibility of the data service to hide these details from consumers of the service and fill in default information wherever it is unavailable.
A data service may use a pattern like the Service Data Objects [4], a joint work from BEA Systems and IBM. Service Data Objects framework provides unified data access to heterogeneous data sources, while decoupling application code from data access code. It also fits very well into the SOA. BEA AquaLogic Data Services Platform enables data services to function as single access points for unified and consistent information across the enterprise. It is natively built around the Data Services Pattern and promotes the SOA mechanism of data access.
Fig. 2: SDO model for data services
Component, Composite and Conversational Services
A component service is a simple atomic action on a simple entity that does not depend on another service to function. For example, database access to a single table can be thought of as a component service.
On the other hand, a composite or business service orchestrates other components or composite services in order to achieve a business level action. For example, submitting a leave application typically involves updating a database, sending an email to the manager for approval, etc.
A conversational or workflow service is a stateful service that lives across invocations and supports long-lived transactions. Conversational services are used to implement long-lived business processes involving orchestration of several services and require support for correlating individual operations. For example, if leave submission including approval by manager, HR, finance etc. is to be implemented as a single business process, it will be applied as a conversational service.
Both component and composite services can be used when a synchronous response is required. Conversational services, due to their inherent long-lived nature, can only return a synchronous acknowledgement, though not response. A callback mechanism with support for correlations between individual invocations and callbacks is required. WS-BPEL [3] is developed by OASIS to support portable, standards-based conversational web services. WS-BPEL provides callback mechanism by defining partner links and supports correlation through correlation sets. It also supports exceptional handling and compensating transactions.
Fig. 3 demonstrates the example of a conversational service.
Fig. 3: Composite (Workflow) Service example
Publish-Subscribe Services
This is another well-known pattern that is commonly seen in traditional application architectures. In SOA, while the concepts are the same, subscriptions and event notifications are services that can be consumed over any transports, and the services invoked can be of any type. The SOA Blueprints specification uses publish-subscribe services to implement adding an employee to the HR application. All sub-systems in the enterprise subscribe to a common service, which notifies all these sub-systems whenever a new employee addition event is fired. There might also be other services (like adapters for legacy security sub-systems) that would be interested in update events.
Fig. 4: Publish-Subscribe Pattern example from SOA Blueprints
Service Brokers
The service broker pattern uses a brokering agent to carry out message- or content-based routing to registered services, potentially carrying out data transformation and applying cross-cutting patterns. The broker may be invoked synchronously or asynchronously, and can call up many services simultaneously or concurrently. Generally, this is a huge set of functionality and is abstracted out at the infrastructure level. The service broker pattern works in conjunction with the publish-subscribe pattern. An SOA implementation using non-web services artifacts can only use a JMS Server and JMS Publisher/Subscribers for these two patterns. When employing web services, one can use an enterprise service bus like BEA AquaLogic Service Bus or Sonic ESB.
Message Bus Pattern
With this pattern, a simple service broker can be built for simple applications that do not want to use a heavy-weight brokering infrastructure. In this pattern, you use topics for message routing. Each destination service should become listener to a particular topic. A web service façade should expose generic operations for sending and receiving messages. The implementation of send message should publish messages to the topic with an appropriate correlation ID. An output topic should listen for responses from the recipient web services and publish those messages to a queue. The web service receive operation can dequeue the right message from this queue using correlation ID as a query selector.
Cross-cutting Patterns
The SOA Blueprints describes interception and extensibility for inserting additional functionality into the systems without modifying the existing system. Functionality that cuts across many aspects of the system can be introduced using the interception model. In interception model, an inceptor accepts the request before going to the backend service and doing arbitrary work on it to add the required functionality like security check, logging, auditing, etc. The service broker pattern can be used to implement cross-cutting patterns (particularly for web services based-services). In Java, these patterns are already recognised as handlers in JAXRPC and filter-chain in Servlet specification.
Exception Handling and Compensating Services
Exception handling is very simple for component services which can either log the fault or pass it back to invoker. However, composite or conversational services involve complex business transactions that span across system, often crossing organisational boundaries. In such cases, there is no centralised transaction manager handling the long-running, complex distributed transaction, and the only way out is to use compensating services. Compensating services allow user to define steps necessary to ‘rollback’ an incomplete action. There are several concerns related to compensating services:
• The failed service must be able to keep track and notify exactly where it failed.
• The compensating service must be able to get this data, and undo the actions intelligently.
• It should be possible to get administrative data on exceptions and compensations, as well as the state of all running/compensating services.
All this, again, is a huge burden for each developer to implement and should be pushed down to the infrastructure level wherever possible. WS-BPEL has native support for these patterns.
SOA Design Considerations
In this section, we will talk about some design considerations that are not ‘patterns’ but are essential for a successful SOA design.
Service Granularity
A key aspect of SOA is to demarcate computational boundaries by exposing services with right granularity. Business functions exposed to be external parties should be kept coarse-grained, whereas internal services can be fine-grained. In this context, external services are exposed to business partners and other modules within the enterprise.
Technology Choice
Most people think SOA in terms of web services alone. However, while web services are essential enabler for SOA, they are not SOA. SOA can be implemented using a variety of technologies, and should be implemented using a right combination of those technologies. One needs not use web services to tie together all services – for example, services that are local to a module should not use web services for interaction. It might sound like a great idea to expose even local services through a web services interface and require all consumers to query through that interface. However, the only effects will be a significant reduction in performance and a system that is way too complex to manage and maintain.
WS-BPEL [3] requires a BPEL process to perform all operations via web service invocations. However, considering that a web service invocation for each minor calculation would be too much of overkill, the specification allows for extension mechanisms that can plug-in local computational capabilities. BPELJ [6] is one such extension to the BPEL specification, currently being worked upon by BEA and IBM. BPELJ specifies a BPEL extension that allows Java code to be buried inside a BPEL process and executed a local code in supporting BPEL engines. In a non-BPEL environment, one should try to avoid using web services altogether when it does not bring any value.
Use of XML
Though developers and architects are warned against overusing XML and web services, many still go overboard when using these technologies. XML, for one, is not the most suitable technology for transmitting large amounts of data, or when there are hard timing requirements for data processing. XML can also be avoided if you are not crossing module or service boundaries. Fine-granular internal services generally should not require web services and can minimise use of XML in many cases.
Loose Versus Tight Coupling
External Services in SOA are by definition loosely coupled services. Loose coupling of services allows for easier maintenance, parallel development and great ease of integration. However, it also introduces some complexities into the system and comes at a performance cost. Closely related services should be tightly coupled to avoid paying a price that does not bring real value to the system.
Industry Initiatives for SOA Blueprints
The first SOA Blueprints was jointly published by BEA Systems and The Middleware Company in 2004, with inputs and review comments from several industry experts. BEA also released an implementation of the blueprints on top of BEA technology [2]. Several other prominent vendors like Microsoft, Oracle, Sun and HP, etc. have committed to providing implementation of the SOA Blueprints.
Once the first blueprints established a dire need and significant interest from the industry, more efforts were started to standardise common SOA terminologies and concepts, SOA design patterns and reference blueprints. One such effort is the OASIS working group for SOA-RM (Service-oriented Architecture – Reference Model) [7]. This committee was formed very recently as a spin-off and partial successor to the Electronic Business Service Oriented Architecture (ebSOA) committee chartered in February 2004. Charter of this committee is to define common SOA terms and concepts, define a reference model for developing SOA-based applications and promote use of proposed best practices and patterns.
Anil is an expert on J2EE technologies and has been working on developing middleware infrastructure software while working at BEA, Oracle and Pramati.
Links and Literature
[1] The SOA Blueprints at http://www.middlewareresearch.com/soa-blueprints/
[2] SOA Blueprints Implementation from BEA at http://dev.bea.com/technologies/soa/blueprint.jsp
[3] OASIS Working Group for WS-BPEL at http://www.oasis-open.org/committees/workgroup.php?wg_abbrev=wsbpel.
[4] Service Data Objects at http://dev2dev.bea.com/wlplatform/commonj/sdo.html.
[5] Asynchronous Query Pattern at http://www.ibm.com/developerworks/webservices/library/ws-tip-altdesign1/
[6] BPELJ Whitepaper by BEA and IBM at http://ftpna2.bea.com/pub/downloads/ws-bpelj.pdf
[7] OASIS Working Group for SOA-RM at http://www.oasis-open.org/committees/workgroup.php?wg_abbrev=soa-rm
|
