[Bernstein09] 10.5. Service-Oriented Architecture

10.5. Service-Oriented Architecture

The SOA style of design provides many benefits, including functional reuse across multiple applications, improved flexibility in developing new applications, and interoperability across disparate software systems, such as .NET, Java EE, and legacy TP monitors. SOA-based applications can include services created from Java EE or .NET Framework objects, legacy TP monitor procedures, asynchronous message queues, or databases. SOA products create and manage services for these and other environments. They also combine services into business process flows. Interoperability across disparate software systems enhances the benefits of SOA for reuse and flexibility, but presents additional challenges for transaction management.

Applications based on the Service-Oriented Architecture (SOA) style of design began to appear in the late 1990s and early 2000s using products such as Progress Software’s CORBA-compliant Orbix and IBM’s WebSphere MQ. Some applications based on the SOA design use both, such as the well-documented Credit Suisse Information Bus.

More recently, Web Services have become a popular technology for SOA. As mentioned in the .NET Framework and Java EE sections, both of those technology suites support Web Services. They also support REST/HTTP, another popular technology for SOA. We will discuss both technologies for SOA.

Products and services specifically designed for use with SOA are offered by HP, IBM, Microsoft, Oracle, Progress Software, Red Hat, Software AG, TIBCO Software, and others. Most SOA products support a two-phase commit protocol for services that execute as a transaction. Some products also include a compensation-based protocol for services that execute as a business process. SOA-based applications often include both kinds of services, sometimes in the same application. Sometimes these two types of services are called fine-grained and coarse-grained, or tightly-coupled and loosely-coupled, respectively.

The exact characteristics and details of the SOA products vary, but they tend to fall into these general categories:

• Service enablement: Create Web Service interfaces and REST/HTTP access to existing and new programs, objects, databases, and message queues.

• Business process management: Compose and execute flows of sequences of services.

• Governance: Store and retrieve service metadata, including development lifecycle support.

• Management: Monitor runtime service execution and enforce policy contracts such as security and availability.

In a typical SOA-based application, a request type can invoke a transaction that uses cooperating services within a single application environment, or a business process that invokes multiple services in sequence. In the first case, any transaction protocol can be used, such as a native two-phase commit or the WS-AT protocol from WS-Transactions. For a business process, however, a compensation-based protocol is more likely to be required, such as the WS-BusinessActivity protocol from WS-Transactions.

Several factors apply to the choice of Web Services or REST/HTTP based technologies for an SOA-based application. In general, requirements for RPC communications and for wrapping existing systems favor the use of Web Services, and requirements for hosting applications on the Web favors the use of REST/HTTP. Other factors include whether the application is a purely web-based application, or whether the application is a mixture of web components and transactional middleware components. Web Services are readily available for transactional middleware environments, including legacy TP monitors. However, given the success of the Web, developers would do well to prepare for a web-based architecture whenever possible.

Web Services-Based SOA

Web Services use SOAP as the message format, with parameters expressed in XML and interfaces expressed in Web Services Definition Language (WSDL). Some implementations allow a SOAP message to contain a single XML document instead of RPC-style arguments. Optional headers are added to SOAP messages to express requirements for system functions such as security, reliability, and transaction propagation.

One popular application of Web Services is interoperability between native RPC protocols, such as Java EE’s RMI and the Microsoft RPC. This is done by programs that understand both formats, translating native RPC messages into and out of the SOAP format.

In Figure 10.30, the SOAP message is created using a C# object linked with a proxy generated from a WCF interface that uses a Web Services binding. The SOAP processor in the WCF environment obtains the WSDL interface from the remote service, perhaps using a registry, and marshals the C# data types into XSD data types using the message definition in the remote service’s WSDL file. The caller uses the Web Services address, or obtains the address of the remote service from the WSDL file as well as the transport to be used, typically HTTP. The WSDL file may also include a WS-Policy assertion that requires a transaction context to invoke the remote service. In that case the WCF SOAP processor includes in the SOAP message header a transaction context conforming to the policy assertion.

Figure 10.30. Web Services Interoperability. Two different execution environments can interoperate using SOAP, potentially including a transaction context.

When the remote Java service receives the request message, its SOAP processor unmarshals the XSD data types into Java data types (perhaps using the Java Architecture for XML Binding (JAXB)). The SOAP processor checks whether any SOAP headers need to be interpreted, such as a transactional context, and then uses the service name in the interface to dispatch the request to a local Java object for processing. When a transaction context header is received, the SOAP processor calls a transaction manager to enroll the local transaction in a transaction initiated by the service requester and propagated on the request. Results are returned in the response message, following this path in reverse. If an exception occurs, it is passed back to the calling service using a SOAP Fault message. The WS-Transactions standard defines how the transaction context is propagated and how the commitment protocol is executed.

The style of Web Services illustrated in this example focuses on their use within the .NET Framework and Java EE-based application server environment. However, SOA vendors also provide products that do not depend upon either of these transactional middleware systems. Instead, they use a mediator to process a SOAP message and submit requests to programs, queues, and databases. A mediator is software that sits between the service requester and the service provider. It is also typically responsible for processing any optional SOAP headers for security, reliability, or transactions.

Another popular application of Web Services is to encapsulate a series of fine-grained services inside a business process, exposed using a coarse-grained service. A coarse-grained service may not need the RPC-oriented mechanisms described in the previous example. Instead, an XML payload may be consumed directly. However, the message can still carry optional SOAP headers such as a WS-Security or WS-Transactions context.

The transaction context for the fine-grained services shown in Figure 10.31 executes within a business process and uses a compensation-based protocol such as WS-Transactions’ WS-BA to undo the results of transactions executed within the steps of the business process. A compensation-based protocol can also be used for recovery from failures in interactions among coarse-grained services, especially those using asynchronous communication protocols.

Figure 10.31. Encapsulating Fine-Grained Services in a Business Process. In an SOA environment, the service requester may invoke a coarse-grained service that encapsulates and invokes a series of fine-grained services within a compensation-based transaction context.

REST/HTTP-Based SOA

In the REST/HTTP approach to SOA, interfaces such as WSDL are not used. Nor are message headers such as those defined for SOAP. Instead, HTTP headers are used and resource representations are exchanged and processed. Resource representations typically use XML or JavaScript Object Notation (JSON) formats. Information contained within the resources tells the client what it’s allowed to do. The server accepts HTTP verb requests (GET, PUT, DELETE) or interprets information it receives from the client on a POST request. Therefore, typical RPC artifacts aren’t necessary, such as an interface compiler, proxies and stubs, and marshaled parameters in the form of method arguments.

Instead, REST/HTTP assigns a URI to a resource and exchanges representations of the resource using HTTP verbs. For example, the resource could be a database and the exchanged representation could be an XML representation of rows retrieved from or to be stored in a database table.

Unlike Web Services, transaction propagation for REST/HTTP isn’t defined. However, transactions can be supported by representing each transaction as a unique resource with which HTTP verbs interact. To start a transaction T, the server creates a resource R_T that represents the transaction. All of T’s operations on (other) transactional resources R′ (such as rows of database tables) are sent to R_T, so that it can keep track of before- and after-images of R′. T finishes by sending a commit or abort operation to R_T, which does the corresponding action and then deletes R_T.

The reason for representing the transaction as a resource is that REST/HTTP doesn’t support shared session state. Since there is no session on which to propagate the transaction context, the resource is used to hold that context. Indeed, it holds the entire transaction state. The client maintains its application state and drives the state changes of the server resource that represents the transaction.

REST/HTTP is often a good choice for communication between companies, in which the cost of processing a self-describing XML message isn’t justified due to the relatively small volume of such messages. The REST/HTTP approach is also simpler than the RPC style of interaction more commonly used with Web Services, and thus is easier to use. A multistep REST/HTTP-based exchange between two companies can use a compensation-based transaction protocol.

Figure 10.32 illustrates clients that understand REST/HTTP, such as Silverlight, WCF, Java EE (through the JAX-RS API), and Java Script. These interact with the web server via HTTP verbs. The web server typically dispatches the document received via REST/HTTP to a program on the server side, such as a .NET Framework or Java EE object to interact with the resource, such as a database.

Figure 10.32. REST/HTTP Architecture for SOA. A program capable of using HTTP verbs constructs a document to exchange as a representation of a server-side resource. The service requester receives a hypermedia document representing a resource, which can direct the requester with URIs and forms to POST information back to the resource to effect changes.

REST/HTTP architectures typically use reliable messaging to capture and process messages after they are received. Large web businesses also typically deploy redundant hardware and software systems to ensure reliable request capture and processing. For example, a REST/HTTP request message may be durably stored before sending it to the transaction server and processing it against the database. Reliable schemes also include the ability to detect and filter duplicate messages, or to design messages as idempotent.

An SOA project initially should define a blueprint or style of design before identifying a particular technology or how to apply it. The examples in this section illustrate some possible implementations, highlighting the relationship between transaction management and SOA designs using popular technologies. However, many more approaches are possible.