Loose coupling

Interoperability

Reusability

Discoverability

Governance

2.1 Loose Coupling

Loose coupling is a principle by which the consumer and service are insulated from changes in underlying technology and behavior. In some manner, the loose coupling principle describes a logical separation of concerns. That is, the consumers in our SOA are intentionally separated from direct or physical connection to services. The intent is to protect the individual integrity of each SOA consumer and SOA service and to avoid physical dependencies between them (see Figure 2.1).

Figure 2.1 Tight Coupling and Loose Coupling

When this principle is applied to the design of our services and the service interface, we can mitigate the impact of change. The most common example is an SOA service that has been previously implemented and deployed into the ESB. In this example, a number of consuming applications are successfully using the service. As new consumers find the service, they may also require additional functionality and data not defined to this service. If the service were tightly coupled with each of the previous consumers, the ability to add new functionality to the service would be significantly limited. When tightly coupled, those previously existing consumers would likely be affected by changes to the service. Alternatively, when consumers and services are loosely coupled, there are techniques that can be applied to help mitigate the impact of change to existing consumers of a service. Previous consumers are then unaware and generally unaffected by new additions to the service functionality.

To comply with the loose coupling principle, consumers and services do not communicate directly. As we learned in Chapter 1, consumers and services communicate via messaging. Using a message to exchange requests and replies avoids any direct technical connections between consumers and services. In addition to messaging, there are other service interface design techniques that can be applied to further limit the degree of coupling between consumers and the service.

Messages exchanged between consumers and services are realizations of the service interface. In the case of a Web service, the service interface is defined by the combination of a Web Service Definition Language artifact (WSDL) and an XML Schema definition (XSD) as its referenced metadata. These two types of interface artifacts (WSDL and XML Schemas) are the foundation of any Web service. The design and development of these two interface artifacts are a focus of the loose coupling principle. Other types of services can use other interface definitions and artifacts, but the same principle of loose coupling can still be applied.

The WSDL is the primary interface artifact for an SOA Web service (see Figure 2.2). It can be thought of as the overall and technical interface definition. Among other things, the WSDL exposes the functionality of the service as operations. Alternatively, an XML Schema defines the structure, the containers, and the types that are represented in the messages used for interacting with that service. This relationship between these two SOA Web service interface artifacts is very important.

Figure 2.2 Example WSDL using XML Spy from Altova(Copyright 2003-2008 Altova GmbH, reprinted with permission of Altova)

The WSDL conforms to a widely recognized language from the World Wide Web Consortium.1 Among other things, the WSDL exposes the functionality of the service as operations and the data that are required for each operation.

While the WSDL represents the overall technical interface of a service, it lacks a defined message format for exchanging information between consumers and the service. This missing context is provided by an XML Schema definition. Syntactically, the WSDL can reference one or more XML Schema definitions, or it can also include embedded XML Schemas. The association of an XML Schema to a WSDL is specified within the WSDL “< types/ >” child element (see Figure 2.3).

Figure 2.3 Example WSDL < types/ > Import Reference to an XML Schema using XML Spy from Altova(Copyright 2003-2008 Altova GmbH, reprinted with permission of Altova)

XML Schema is also defined by a well-known language.2 The declarative syntax of an XML Schema is similar to a set of structure and type definitions, and it can also include supporting rules. From a purist perspective, an XML Schema is a form of metadata that describes and constrains XML formatted data, such as a request or a response message (see Figure 2.4).

Figure 2.4 Example XML Schema using XML Spy from Altova(Copyright 2003-2008 Altova GmbH, reprinted with permission of Altova)

An operation defined to a WSDL is a functional capability of a service. The operation instructs the service to perform a needed function, such as “add” a new Inventory Item, or retrieve (“get”) Inventory Details for an item. Each operation can also be defined with one or more parameters. The parameters of an operation describe a set of contextual information that is expected by the service and allows it to process the request. Design techniques can be applied to the definition of an operation and also to the structure of the message that will to a large degree determine how loosely or tightly coupled a consumer and a service are.

A common service interface design style known as RPC encoded (Remote Procedure Call) prescribes that each operation of a service is a discrete function of the service and has one or more parameters. When a consumer sends a message to a service using an RPC-encoded style of message, operations are usually named in the message, and parameters are filled with data values, including a prescriptive specification of the data type for each. Upon receiving the request message from the consumer, the service then extracts and processes the data values from each of the parameters. If the service determines that the parameter data values are correct and as expected, it can then process the request. Note that I have used the term “operation” in this description. Although there are differences from an object-oriented perspective, for the RPC example, you can think of an operation as being roughly analogous to a method.

A specific request to a service operation, and including its parameters, is often referred to as a method signature. A common analogy for parameters might be an explicitly defined list with item numbers, item names, colors, prices, sizes, and similar information. Each entry on the list occurs in a particular order and is defined with explicit data types (see Figure 2.5). The RPC-encoded design style works quite well when the type of interaction between consumers and the service is simple and rarely subject to change. However, when the service goes through eventual enhancement, such as adding new parameters, changing a parameter, or adding new content to a response message, those existing consumers of the service that have developed their messages to explicitly comply with the original operations and parameters will then have to also make corresponding changes. This is an example of tight coupling where a change to the service interface can impact and force residual change upon existing consumers.

Figure 2.5 RPC Style Operations and Parameters

Alternative to the RPC-encoded interface style, there are other design techniques and styles that can help to decouple consumers and services. With these other techniques, the consumers and services exchange more of a document context. We can think of this document style message exchange as being similar to a set of paragraphs that you would find on a printed letter or a page from a book. This technique is often referred to as document literal. Consumers are still required to include request message content that meets the expectations of the service, but they are not coupled to discrete technical characteristics of the service operation. As the service undergoes the addition of new data elements and similar enhancements, previously existing consumers of the service can be insulated from many of those changes. When combined with messaging as the method of interaction, the document-literal style interface is an example of implementing to the loose coupling principle (see Figure 2.6).

Figure 2.6 Document-Literal Style Operations

To further explain differences between the RPC-encoded and document-literal design styles, consider a simple inventory management service. As defined by its operations, the example inventory management service provides functionality for...