Web Services Platform Architecture [Electronic resources] : SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More نسخه متنی

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, 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 Hohpe 2004] for additional perspectives in this space.

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