Service-Oriented Integration

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Integration Patterns

Contents

Context

Problem

Forces

Solution

Example

Resulting Context

Security Considerations

Related Patterns

Acknowledgments

Context

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.

Problem

How do you integrate applications at the business logic layer?

Forces

Integrating systems at the business logic layer involves balancing the following forces:

• Machine boundaries are important. The idea that you can take a local object interface and extend it across machine boundaries to create location transparency is flawed. Although it is true that both the remote objects and the local objects have the same interface from the perspective of the calling process, the behavior of the called interface is quite different depending on location. From the client perspective, a remote implementation of the interface is subject to network latency, network failure, and distributed system failures that do not exist with local implementations. A significant amount of error detection and correction logic must be written to anticipate the impacts of using remote object interfaces.

• Coupling affects interoperability. Integrating at the logical business layer involves sharing functionality. Sharing functionality implies some level of coupling between the consumer and the provider of the functionality. There are many forms of coupling. These forms of coupling include the following:

  • Temporal coupling. Temporal coupling occurs during the request for functionality. If the request is synchronous, the calling system must wait for the provider to finish processing the request before it can continue. If the request is asynchronous, the calling system can continue processing after it makes the request while the providing system independently continues to process the request. In terms of time, the asynchronous call is more loosely coupled than the synchronous call.
  • Type-system coupling. Type-system coupling occurs when a process must associate the name of a type with its binary representation on the host computer. This association may be as simple as an integer, meaning a big-endian 4-byte primitive on one computer and a 2-byte little-endian primitive on another. Of course, user-defined types such as a customer object become much more complex. When two systems interoperate, they must share a common type representation; in this sense they are coupled together. Most implementation platforms do not share the same type representation.
  • Dependency coupling. Dependency coupling occurs when one executable depends on other executables to run. If the executable cannot resolve its dependencies at run time, the executable fails. In this sense, the executable and its dependencies are coupled together.

  To integrate disparate systems, you must resolve potential differences in type systems and execution dependencies. You must also decide whether you want the calling thread of execution to block when making a request to the provider.

• Coupling and Interface Definition Language. Even when the type system is described using an Interface Definition Language (IDL), platform infrastructure code must be installed on the host computer that interprets the IDL. For example, if you are using Common Object Request Broker Architecture (CORBA), infrastructure such as an Object Request Broker (ORB) must be installed on the host computer for a system to resolve the CORBA IDL types. Two CORBA-based systems that are installed on different hardware platforms and operating systems can interoperate, but they both remain coupled to the CORBA type specification and binary mappings.

• Coupling and message-oriented middleware. Type-system coupling also occurs when using proprietary message-oriented middleware. To resolve message formats, each endpoint must contain an installation of the appropriate message-oriented middleware. Although a particular message-oriented-middleware product may be ported to multiple platforms, any endpoint you want to communicate with must also have the same message-oriented middleware product installed.

• Portable type system. Most enterprise systems can process XML. From the perspective of type-system coupling, the only primitive that must be agreed upon is a string. After the incoming byte stream is interpreted as a string buffer, the string can be parsed according to XML specifications, including XML schema. In turn, the schema provides a type system that is highly portable between disparate hardware and operating systems.

• Contracts. Contracts have proven to be an excellent means of specifying behavior between a consumer and a provider of services.

Solution

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 family of specifications (for example, the Web Services Security [WS-Security] specification). For more information about the Web Services specifications, see "Specifications" in the Web Services Developer Center on MSDN (https://msdn.microsoft.com/en-us/library/ms951274.aspx). Whenever possible, use the document message style and literal serialization (see "Use Document/Literal SOAP Styles and Encoding" later in this pattern).

Note: The term service is used in many different ways in the context of software engineering. It is also used in at least seven levels of scope: operating system, process, object, distributed object, proprietary message-oriented middleware, logical, and XML Web services. This guide uses the term service to mean XML Web services unless indicated otherwise.

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

In addition to following the Web Services specifications, you should also refer to the Web Services Interoperability (WS-I) profiles when you design and build Web services. For more information about WS-I, 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 (https://msdn.microsoft.com/en-us/library/ms951214.aspx).

Web Services

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.

Use Document/Literal 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 major 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 (https://msdn.microsoft.com/en-us/library/ms995800.aspx).

Combine Synchronous and Asynchronous Behavior to Address Temporal Coupling

To address 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 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)

MEP name	Description	Type
Request-response	The endpoint receives a message and then sends a correlated message.	Synchronous*
One-way	The endpoint receives a message.	Asynchronous
Solicit-response	The endpoint sends a message and then receives a correlated message.	Synchronous*
Notification	The endpoint sends a message.	Asynchronous

* 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.

Global Bank's 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.

Recognize Explicit Boundaries

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 [Trowbridge03] to meet operational requirements when traversing these boundaries.

Treat Services as Autonomous

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.

Example

For detailed examples, see Implementing Service-Oriented Integration with ASP.NET and Implementing Service-Oriented Integration with BizTalk Server 2004.

Resulting Context

As a result of implementing the Service-Oriented Integration pattern, the following tenets apply [Box04]:

• Boundaries are explicit. Crossing service boundaries can be costly. For example, you may need to span geography, trust boundaries, or execution environments.. You should therefore explicitly opt into service orientation by formally passing defined messages between services. The explicit boundaries allow you to formally express implementation-independent interaction so that your interactions do not depend on the different platform, middleware, or coding language choices used to implement other services.
• Services are autonomous. There is no presiding authority in a service-oriented environment. Services are independently deployed, versioned, and managed. The topology in which a service executes evolves over time. The service should expect that peer services will fail and that it will receive malformed or malicious messages. The services should be built by using techniques such as redundancy and failover so that the services do not fail.
• Services share schema and contract, not class. Services interact solely on their expression of structures through schemas and behaviors through contracts. The service's contract describes the structure of messages and ordering constraints over messages. The formality of the expression allows machine verification of incoming messages. Machine verification of incoming messages allows you to protect the service's integrity. Contracts and schemas must remain stable over time, so building them flexibly is important.
• Service compatibility is based on policy. Services express their capabilities and requirements in terms of a machine readable policy expression. Policy assertions are identified by a stable, globally unique name. Individual policy assertions are opaque to the system as a whole; services must simply be able to satisfy each other's policy requirements.

Benefits

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.

Liabilities

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 Considerations

Security is critical to services. Given its complex and technology-specific nature, you must consider security individually for each implementation.

Related Patterns

For more information, see the following related patterns:

• Implementing Service-Oriented Integration with ASP.NET
• Implementing Service-Oriented Integration with BizTalk Server 2004
• Broker [Buschmann96]. To discover and publish services, Web services use an implementation of the Universal Description, Discovery, and Integration of Web Services (UDDI) specification. UDDI is an implementation of the Indirect Broker pattern. The Indirect Broker is a specialized kind of Broker [Buschmann96]. Indirect Broker enables one endpoint to locate another. After the other endpoint is located, the two endpoints communicate directly with each other. In comparison, Direct Broker also helps make the initial connection, but it maintains central control over the communication. For an example of a Direct Broker, see Message Broker.
• Service Gateway [Trowbridge03]. This pattern contains the code that implements the consumer portion of the contract into its own Service Gateway component.
• Service Interface [Trowbridge03]. This pattern designs an application as a collection of software services. Each software service has a service interface that consumers of the application can interact through.

Acknowledgments

[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: https://msdn.microsoft.com/en-us/magazine/cc164026.aspx.

[Buschmann96] Buschmann, Frank; Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. John Wiley & Sons Ltd, 1996.

[Erikkson00] Eriksson, Hans-Erik, and Magnus Penker. Business Modeling with UML: Business Patterns at Work. John Wiley & Sons, Inc., 2000.

[Newcomer02]. Newcomer, Eric. Understanding Web Services: XML, WSDL, SOAP, and UDDI. Addison-Wesley, 2002.

[Skonnard03-2] Skonnard, Aaron. "Understanding SOAP." MSDN Web Services Developer Center, March 2003. Available at: https://msdn.microsoft.com/en-us/library/ms995800.aspx.

[Trowbridge03] Trowbridge, David; Dave Mancini, Dave Quick, Gregor Hohpe, James Newkirk, and David Lavigne. Enterprise Solution Patterns Using Microsoft .NET. Microsoft Press, 2003. Also available on the MSDN Architecture Center at: https://msdn.microsoft.com/en-us/library/ms998469.aspx

[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: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsvcinter/html/wsi-bp\_msdn\_landingpage.asp.

Start | Previous | Next

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.