You've decided to use the Functional Integration pattern to integrate information systems that were not designed to work together. You need interoperability among systems built with different technical architectures. In addition, the systems that you want to integrate may not be reliably connected.
How do you integrate applications at the business logic layer?
Integrating systems at the business logic layer involves balancing the following forces:
To integrate applications at the business logic layer, enable systems to consume and provide XML-based Web services. Use Web Services Description Language (WSDL) contracts to describe the interfaces to these systems. Ensure interoperability by making your implementation compliant with the Web Services Interoperability (WS-I) guidelines. Whenever possible, use the document message style and literal serialization (see "SOAP Styles and Encoding").
To expose existing functionality as a Web service, use the Service Interface pattern [Trowbridge03]. To encapsulate the logic necessary to consume services, use the Service Gateway pattern [Trowbridge03]. Figure 1 shows the design elements involved in this interaction.
Figure 1. Using Service Gateway and Service Interface to connect a Web service consumer and provider
For more information about the WS-I guidelines, see the Web Services Interoperability Organization Web site (http://www.ws-i.org). For guidance about how to build Web services that are compliant with the WS-I basic profile, see Building Interoperable Web services: WS-I Basic Profile 1.0 on MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsvcinter/html/wsi-bp_msdn_landingpage.asp).
What exactly is a Web service? According to the World Wide Web Consortium (W3C),
"a Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards." [W3C04]
In terms of interaction, two systems use Web services to communicate when a requesting application creates an XML document in the form of a message and sends it over the network to a provider of Web services. Optionally, the provider sends a reply to the requester in the form of an XML document. Web services standards specify the interface that the message is sent to, the format of the message, the mapping of the message contents to service implementations, the optional headers, and the means by which services can publish and discover other Web services.
Resolving the Forces
How does using Web services to integrate systems resolve the forces mentioned earlier? First, basing your messages on XML and XML Schema definition language (XSD) results in a highly portable type system as explained earlier. A portable type system dramatically reduces type-system coupling. Type-system coupling is a major impediment to cross-platform integration. However, to take full advantage of this portable type system, you must understand SOAP styles and encoding.
SOAP Styles and Encoding
The WSDL 1.1 specification identifies two message styles (document and Remote Procedure Call [RPC]) and two means of serializing the message onto the transport mechanism (SOAP encoding and XML Schema). Choosing the right combination of style and serialization have a large impact on the interoperability of your Web service.
The document message style indicates that the message body contains an XML document. It is up to the service consumer and the service provider to agree on the document exchanged. The RPC style indicates that the message body will contain an XML representation of an RPC.
To serialize the message data, the XML Schema–based serialization simply uses the definitions contained in the XML Schema specification. Because using XML Schema results in a highly portable type system, the messages are highly interoperable. However, the SOAP-encoded serialization uses encoding rules that require RPC-style communication. Since the details of RPC communication can vary significantly between implementations, the resulting messages are not as easily interoperable.
As a result of these interoperability concerns, use document-style messages with literal encoding (doc/literal) whenever possible. For more information about this topic, see "Understanding Soap" on MSDN (http://msdn.microsoft.com/webservices/understanding/webservicebasics/default.aspx?pull=/library/en-us//dnsoap/html/understandsoap.asp).
To eliminate temporal coupling, it is possible to invoke Web services both synchronously and asynchronously. To understand how to do this in the context of Web services, you must understand parts of the WSDL, SOAP, and Web Service Architecture specifications.
To further abstract communication away from implementation notions such as synchronous and asynchronous calls, WSDL uses the concept of message exchange patterns (MEP) to describe generic patterns of message exchange between endpoints. There are four kinds of MEP described in WSDL 1.1, as shown in Table 1.
Table 1: Four Kinds of Message Exchange Patterns (MEP)
* This MEP emulates synchronous behavior with HTTP POST/GET SOAP binding.
SOAP provides an extensible one-way messaging framework between sender and receiver. To implement SOAP, however, you must bind it to a specific protocol. HTTP POST/GET is the most common protocol. Because HTTP is a synchronous protocol, if you use the SOAP/HTTP binding, you get the synchronous/asynchronous behavior shown in Figure 2.
In cases where there are long-running transactions across enterprises, a Web service exchanges messages synchronously while the larger business process that it runs within executes asynchronously. For example, consider the Global Bank scenario.
Asynchronous Business Process
In the Execute Scheduled Payment use case (see Chapter 2 for more details), Global Bank sends international payments through a Society for Worldwide Interbank Financial Telecommunication (SWIFT) payment gateway by using Web services over the Internet. The message sent is an XML document containing the information necessary for the payment gateway to electronically pay the payee identified in the document. This message is sent synchronously through HTTP, and the response only acknowledges a successful transmission. When the successful transmission occurs, the payment gateway processes the message, and the calling system does not wait for a response. After the payment gateway has finished processing the payment, it sends another message to Global Bank confirming the payment status. This message is a synchronous HTTP request/response, and the response information only acknowledges a successful message transmission.
Figure 2. SWIFT payment gateway combining synchronous exchanges to simulate asynchronous behavior
In the Execute Scheduled Payment use case, two synchronous message exchanges participate in an asynchronous business collaboration. This effectively decouples the systems.
Because Web services pass documents instead of RPC calls, there is no attempt to consider that the location of the service is transparent. Indeed, the boundary between the two services is explicitly recognized. With explicit boundaries, the connection is not treated as reliable and available, as it would be treated with Distributed Object Integration. You can use other patterns such as Server Clustering, Load-Balanced Cluster, and Failover Cluster [Trowbride03] to meet operational requirements when traversing these boundaries.
When using services to integrate systems, you should consider two key elements: service interfaces and service implementations. Service interfaces describe the functionality, messages, and results that the consumers of the service can expect. Contracts provide these interfaces in the form of WSDL files. Service implementations contain the software that implements the service and all its execution dependencies, with the possible exception of other services.
Collaborations through service interfaces facilitate a high degree of interoperability in your enterprise. The services should be capable of being independently versioned, managed, and deployed. As these services are deployed, all the appropriate execution dependencies (except other services) should be deployed with the service and contained within the service boundary.
For detailed examples, see Implementing Service-Oriented Integration with ASP.NET and Implementing Service-Oriented Integration with BizTalk Server 2004.
As a result of implementing the Service-Oriented Integration pattern, the following tenets apply [Box04]:
The key benefit of using Service-Oriented Integration is interoperability between disparate technical architectures. Interoperability at the level of technical architecture helps to decouple an enterprise's business architecture from its information technology. This decoupling gives an enterprise a great deal of flexibility in terms of how it implements specific business capabilities.
Although an enterprise contains processes, resources, goals, business rules, and relationships [Eriksson00], it is the business processes that define how work actually is done. Technical architectures enable work to be done efficiently by incorporating business processes.
Without interoperable systems, the cost of process change is relatively high because it may involve crossing technology boundaries. When using interoperable systems, however, the cost of process change is dramatically lowered. This is especially true when services are designed at a level of granularity that is meaningful to the business, such as steps within a process. Businesses that have interoperable systems and that use services that are relevant to business process are in a better position to sense and respond to market changes and opportunities. These businesses become more agile as a result of creating interoperable systems and using services that are relevant to business practices.
The key liability of using Service-Oriented Integration is the performance cost of serializing, deserializing, and parsing XML documents. In addition, XML documents are much larger than their binary equivalents because they contain metadata. This increases the size of the payload that must be processed during message exchange.
Security is critical to services. Given its complex and technology-specific nature, you must consider security individually for each implementation.
For more information, see the following related patterns:
[Box04] Box, Don. "Code Name Indigo: A Guide to Developing and Running Connected Systems with Indigo." MSDN Magazine. January 2004. Available from the MSDN Windows Code-Named "Longhorn" Developer's Center at: http://msdn.microsoft.com/longhorn/understanding/pillars/indigo/default.aspx?pull=/msdnmag/issues/04/01/Indigo/default.aspx.
[Buschmann96] Buschmann, Frank; Regine Meunier, Hans Rohnert, Peter Sommerland, and Michael Stal. Pattern-Oriented Software Architecture. John Wiley & Sons Ltd, 1996.
[Erikkson00] Business Modeling with UML: Business Patterns at Work. Eriksson, Hans-Erik, Penker, Magnus. John Wiley & Sons, Inc., 2000.
[Newcomer02]. Newcomer, Eric. Understanding Web Services: XML, WSDL, SOAP, and UDDI. Addison-Wesley, 2002.
[Skonnard03] Skonnard, Aaron. "Understanding SOAP". MSDN Web Services Developer Center, March 2003. Available at: http://msdn.microsoft.com/webservices/understanding/webservicebasics/default.aspx?pull=/library/en-us//dnsoap/html/understandsoap.asp.
[Trowbridge03] Trowbridge, David, et al. Enterprise Solution Patterns Using Microsoft .NET. Microsoft Press, 2003.
[W3C04] "Web Services Architecture W3C Working Draft 11 February 2004." Available on the W3C Web site at: http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/
[Wanagel03] Wanagel, Jonathan, et al. "Building Interoperable Web Services: WS-I Basic Profile 1.0." MSDN Library, August 2003. Available at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsvcinter/html/wsi-bp_msdn_landingpage.asp.