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
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.
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
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
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.
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.
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.
If the requester can invoke a service and continue running, the requester is less dependent on service availability.
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.