Section 1.2. The Need for Loose Coupling

1.2. The Need for Loose Coupling

Enabling communication with services, possibly dynamically discovered, requires loose coupling between a requester and the service to be used. The notion of loose coupling precludes any knowledge or assumptions about the specific platforms that the requester or the service provider run on, specifics about the implementation that either of the partners uses, or the formats and protocols used to interoperate between them. Making such assumptions significantly limits the usefulness of a service or the choice of services that might be available. The notion of loose coupling is a fundamental underpinning of SOA. The following section sheds more light on it.

1.2.1. Issues with Current Distributed System Technologies

Distributed system technology that has been developed in the past allows building applications, the elements of which can run on different machines in a network. However, dealing with the business scenarios outlined earlier has some other issues.

Fragility of Object Systems

Typically, current distributed system technology is centered on object technology. In this case, a service is offered as a method of a class implemented by an object. A requester who wants to use a service must tie the whole object into his application. In other words, a person who needs a single function has to use the whole class oreven worsethe whole class hierarchy within his program. When the class used or the class above it in the class hierarchy changes, he must also change the application that uses that class. The requester and the service are tightly coupled, which means that the requester's application is fragile because of its association with and dependence on this detail.

Lack of Interoperability

Today, different distributed system technologies such as Common Object Request Broker Architecture (CORBA), Java 2 Platform, Enterprise Edition (J2EE), and Component Object Model (COM) are based on quite different and incompatible object models [Emm 2000]. As a result, interoperability between these platforms is difficult. Communication between a requester on one platform and a service on another is at best cumbersome, if it's possible at all. Not only are the object models different, but higher-level frameworks (middleware) that support them (such as transactions, security, management, and messaging) are also incompatible. This significantly compounds the interoperability problem because you have to deal with quality of service differences. These differences can include running a transaction with participants on different platforms that operate incompatible transaction services, which is not an easy task!

1.2.2. Advantages of Message-Oriented Middleware

A significant consequence of these interoperability problems is that islands of middleware and corresponding applications that are based on this middleware have been created. In parallel, the ability to easily integrate applications, especially from different islands, has become a strong requirement (Enterprise Application Integration EAI). In tandem, products that provide special integration middleware have been created. A key aspect of such integration middleware is message orientation.

Adapters and Channels

Message orientation refers to messages being exchanged between the applications that are to be integrated. For this purpose, adapters wrap existing applications that need to be integrated. One kind of adapter signals the occurrence of an event that needs to be passed to other applications (source adapter), and another kind of adapter receives such events and passes them to the application that they are wrapping (target adapter). Events are represented by messages that are transported via a so-called "channel" from the source adapter to a target adapter. The channel ensures a certain quality of services, such as "exactly once delivery". Also, the channel can have other side effects, such as transforming the message into a format that the recipient understands. Figure 1-2 shows a source adapter A that wraps application A. Adapter A passes a message of format M to the channel, which transforms the message into format M' and delivers it reliably to target adapter B. Adapter B in turn understands how to pass the data from M' to B. See [Hohpe 2004] for additional perspectives in this space.

Figure 1-2. Message-based integration.

Based on this message-based architecture, applications A and B are loosely coupled. For example, the owner of application A can change the format of message M, generally without affecting his ability to integrate application B. The message M that A produces can be appropriately transformed by the channel into the format M' that B expects. A message-based approach like this fosters loose coupling.

Interaction Patterns

Often, interaction and communication styles, other than the synchronous request/response approach that is predominant in distributed object systems, are necessary for loosely coupled interactions. For example, the asynchronous send and receive pattern that was mentioned in the previous section can increase a requester's perspective of the overall availability of the requested service. Operating in a "send-and-forget" mode, the requester doesn't have to synchronously wait for a response from the service. The requester doesn't have to deal with potential connection problems between the requester's side and the service's side because the channel can operate in a store-and-forward manner, finally delivering the message to the target destination.

Other patterns are also desirable. For example, a message might be delivered to multiple recipients, only a subset of which responds to the originator of the message. This pattern is useful in auction-type scenarios in which a request for bids is sent and bids are returned. This also contributes to loose coupling because the requester is unaware of who the recipients are. The underlying integration middleware deals with these aspects. To overcome rigidity in distributed object systems, you must support the ability to define message exchange patterns (MEP), which provide advanced interaction patterns. MEP is discussed in Chapter 6 in more details.

Web service technology is built on the concept of messaging. As a result, requesters and services can run on different platforms with channels connecting them. Wrappers hide the implementation specifics of the wrapped application function. In other words, requesters and services that are built according to different programming models can interact with each other. Protocols that are underlying a channel are hidden from the communication partners, and different formats can be transformed within a channel. The messaging architecture underlying Web servicesSOAPalso foresees exchange of information required by higher-level functionality, such as transaction context or security context. Therefore, a messaging-based approach supports many of the requisite features at the beginning of this section.

1.2.3. Future Proofing

The concept of a wrapper allows switching implementations of application functions without impact to the other communication partner. This in turn facilitates loose coupling between a requester and a service (their corresponding wrappers). That is fine, but a universally agreed or standard approach to specifying the wrappers is required to describe, in a machine-readable way, the interface that a service provides to its potential users. The Web Services Description Language (WSDL) provides precisely this capability.

Technology Abstraction

WSDL provides a standard way of describing the interfaces of the wrappers that hide the specific implementation details of a service. Such an interface describes, in abstract terms, the functions that services provide. A requester can use any service that implements a particular interface to satisfy his requirement. This contributes to loose coupling between a requester and the service and provides some element of future-proofing. It gives the requester the freedom to select a different service implementation of the same interface at any time. In particular, the requester can benefit from any future advancements in implementation technology for services by being based on WSDL interfaces.

Provider Abstraction

Services are described not only by their WSDL interfaces, but also in terms of the quality of service they provide. For example, a service might assert that it can participate in a transaction, thereby ensuring overall integrity of a series of service invocations. It might also assert that it can cope with encrypted messages, ensuring that in the course of an interaction between a requester and the service, no confidential data will be revealed to unauthorized parties. The ability to annotate quality of service descriptions is important, and incorporated into Web service technology by means of the Web service policy specifications discussed later in this book (Chapter 7, "Web Services Policy").

Also, you can associate services with business-relevant data. The directory features of the Universal Description, Discovery, and Integration (UDDI) technology (discussed later) offer and support such a capability and allow information about the company that is providing the service, including contact information, additional documentation, and geographic details. This allows discovery of suitable services based on detailed business criteria. For example, as a requester, a restaurant might want an online service that supplies ordering, settlement, and delivery of vegetables, meat, and so on within a distance of less than 50 miles.

As a consequence, the boundary for describing and discovering services is moved from specialized IT personnel toward business professionals. Again, this contributes to loose coupling by supporting discovery of providers that offer identical services and allowing switching between them dynamically with little or no change to the application.