[Bernstein09] 10.5. Service-Oriented Architecture

10.5. Service-Oriented Architecture

TheSOA style of design provides many benefits, including functional reuseacross multiple applications, improved flexibility in developing newapplications, and interoperability across disparate software systems,such as .NET, Java EE, and legacy TP monitors. SOA-based applicationscan include services created from Java EE or .NET Framework objects,legacy TP monitor procedures, asynchronous message queues, ordatabases. SOA products create and manage services for these and otherenvironments. They also combine services into business process flows.Interoperability across disparate software systems enhances thebenefits of SOA for reuse and flexibility, but presents additionalchallenges for transaction management.

Applicationsbased on the Service-Oriented Architecture (SOA) style of design beganto appear in the late 1990s and early 2000s using products such asProgress Software’s CORBA-compliant Orbix and IBM’s WebSphere MQ. Someapplications based on the SOA design use both, such as thewell-documented Credit Suisse Information Bus.

Morerecently, Web Services have become a popular technology for SOA. Asmentioned in the .NET Framework and Java EE sections, both of thosetechnology suites support Web Services. They also support REST/HTTP,another popular technology for SOA. We will discuss both technologiesfor SOA.

Products andservices specifically designed for use with SOA are offered by HP, IBM,Microsoft, Oracle, Progress Software, Red Hat, Software AG, TIBCOSoftware, and others. Most SOA products support a two-phase commitprotocol for services that execute as a transaction. Some products alsoinclude a compensation-based protocol for services that execute as abusiness process. SOA-based applications often include both kinds ofservices, sometimes in the same application. Sometimes these two typesof services are called fine-grained and coarse-grained, ortightly-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.

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

Severalfactors apply to the choice of Web Services or REST/HTTP basedtechnologies for an SOA-based application. In general, requirements forRPC communications and for wrapping existing systems favor the use ofWeb Services, and requirements for hosting applications on the Webfavors the use of REST/HTTP. Other factors include whether theapplication is a purely web-based application, or whether theapplication is a mixture of web components and transactional middlewarecomponents. Web Services are readily available for transactionalmiddleware environments, including legacy TP monitors. However, giventhe success of the Web, developers would do well to prepare for aweb-based architecture whenever possible.

Web Services-Based SOA

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

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

In Figure 10.30,the SOAP message is created using a C# object linked with a proxygenerated from a WCF interface that uses a Web Services binding. TheSOAP processor in the WCF environment obtains the WSDLinterface from the remote service, perhaps using a registry, andmarshals the C# data types into XSD data types using the messagedefinition in the remote service’s WSDL file. The caller uses the WebServices address, or obtains the address of the remote service from theWSDL file as well as the transport to be used, typically HTTP. The WSDLfile may also include a WS-Policy assertion that requires a transactioncontext to invoke the remote service. In that case the WCF SOAPprocessor includes in the SOAP message header a transaction contextconforming to the policy assertion.

Whenthe remote Java service receives the request message, its SOAPprocessor unmarshals the XSD data types into Java data types (perhapsusing the Java Architecture for XML Binding (JAXB)). The SOAP processorchecks whether any SOAP headers need to be interpreted, such as atransactional context, and then uses the service name in the interfaceto dispatch the request to a local Java object for processing. When atransaction context header is received, the SOAP processor calls atransaction manager to enroll the local transaction in a transactioninitiated by the service requester and propagated on the request.Results are returned in the response message, following this path inreverse. If an exception occurs, it is passed back to the callingservice using a SOAP Fault message. The WS-Transactions standarddefines how the transaction context is propagated and how thecommitment protocol is executed.

Thestyle of Web Services illustrated in this example focuses on their usewithin the .NET Framework and Java EE-based application serverenvironment. However, SOA vendors also provide products that do notdepend upon either of these transactional middleware systems. Instead,they use a mediatorto process a SOAP message and submit requests to programs, queues, anddatabases. A mediator is software that sits between the servicerequester and the service provider. It is also typically responsiblefor processing any optional SOAP headers for security, reliability, ortransactions.

Anotherpopular application of Web Services is to encapsulate a series offine-grained services inside a business process, exposed using acoarse-grained service. A coarse-grained service may not need theRPC-oriented mechanisms described in the previous example. Instead, anXML payload may be consumed directly. However, the message can stillcarry optional SOAP headers such as a WS-Security or WS-Transactionscontext.

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

REST/HTTP-Based SOA

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

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

UnlikeWeb Services, transaction propagation for REST/HTTP isn’t defined.However, transactions can be supported by representing each transactionas a unique resource with which HTTP verbs interact. To start atransaction T, the server creates a resource R_Tthat represents the transaction. All of T’s operations on (other)transactional resources R′ (such as rows of database tables) are sentto 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.

Thereason for representing the transaction as a resource is that REST/HTTPdoesn’t support shared session state. Since there is no session onwhich to propagate the transaction context, the resource is used tohold that context. Indeed, it holds the entire transaction state. Theclient maintains its application state and drives the state changes ofthe server resource that represents the transaction.

REST/HTTPis often a good choice for communication between companies, in whichthe cost of processing a self-describing XML message isn’t justifieddue to the relatively small volume of such messages. The REST/HTTPapproach is also simpler than the RPC style of interaction morecommonly used with Web Services, and thus is easier to use. A multistepREST/HTTP-based exchange between two companies can use acompensation-based transaction protocol.

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

REST/HTTParchitectures typically use reliable messaging to capture and processmessages after they are received. Large web businesses also typicallydeploy redundant hardware and software systems to ensure reliablerequest capture and processing. For example, a REST/HTTP requestmessage may be durably stored before sending it to the transactionserver and processing it against the database. Reliable schemes alsoinclude the ability to detect and filter duplicate messages, or todesign messages as idempotent.

AnSOA project initially should define a blueprint or style of designbefore identifying a particular technology or how to apply it. Theexamples in this section illustrate some possible implementations,highlighting the relationship between transaction management and SOAdesigns using popular technologies. However, many more approaches arepossible.