Loose Coupling


As you learned in Chapter 1, an important characteristic of an SOA is loose coupling, which means that one unit of software is largely independent of another. This independence implies that changes to one unit of software cause less turmoil and cost to an organization than when the software is more interdependent. It also means you can substitute one unit of software for an already-deployed unit relatively easily. The value of loose coupling is greatest when technical changes are expected over time.

The following questions identify some of the ways in which a service might be loosely coupled with other software.

How Easily can the Logic Inside a Service be Revised Without Changing How the Service is Invoked?

The logic and programming language of a service implementation should be independent of the service contract. You can change the service internals for greater efficiency without changing the requester in any way.

How Protected is the Requester from Disruption in the Face of Increased Service Capabilities?

An SOA runtime product may support either of two kinds of service interface:

  • Remote procedure call (RPC): In this case, the requester submits a set of arguments to a particular service operation as if invoking a local function. The service uses each argument as a discrete unit in accordance with the meaning and type of the related parameter.

  • Document: In this case, the requester submits a string of arbitrary length, and the service reviews that string to determine what operations to perform.

The RPC and Document categories overlap, as when an RPC invocation submits a single string to a service that in turn dispatches the message to one of several subroutines. The point, however, is that if the contract between requester and service features a long string (rather than a set of typed arguments) and if a later version of the service adds new functionality, the service interface is unaffected.

Requester updates (as needed to use the new service functionality) are likely to be needed only over time rather than in urgent response to a change in the service.

How Easily can a Service be Incorporated into a Larger Process Without Changing the Service Implementation?

A change to a runtime security mechanism, for example, shouldn't require the code for a service to be rewritten or recompiled. The looseness of coupling in this case may depend on the power of an SOA runtime product because that product allows more decisions to occur at configuration time.

To What Extent is a Requester Dependent on Service Availability?

If an SOA runtime product maintains message queues on each side of a remote transmission, the product can guarantee message delivery between requester and service, in which case network failures will tend to have less of an effect. The benefit is greatest if the requester isn't waiting for a response.

Can the Requester Continue Running in the Absence of a Response?

If the requester can invoke a service and continue running, the requester is less dependent on service availability.

Is the Service Dependent on State Information?

A specific requester might invoke the same service repeatedly to fulfill a single task (to update a checking account, for example), and the service might need to retain state information (such as a checking-account number) between each invocation. In general, state information is the set of values that are needed for the service to maintain a conversation with a specific requester.

If a service needs to retain state information, the SOA runtime product won't be able to direct processing to an identical service at a second location, as might be necessary in response to network traffic. If the SOA runtime product can redirect the state information as well, the restriction does not apply.




SOA for the Business Developer. Concepts, BPEL, and SCA
SOA for the Business Developer: Concepts, BPEL, and SCA (Business Developers series)
ISBN: 1583470654
EAN: 2147483647
Year: 2004
Pages: 157
Authors: Ben Margolis

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net