Patterns: Implementing Self-Service in an SOA Environment

Chapter 3. SOA and the Enterprise Service Bus 33

򐂰 There is no single data, business, or process model across, or beyond, the

enterprise.

Although they are not a magic solution to this issue, the SOA principles define

an approach that enables organizations to progressively expose functions

across their business as services and to combine those services into

processes. SOA encourages processes to be centrally managed and

explicitly defined and modelled. Over time, businesses that take this

approach will improve the consistency of their business and process models

and will leverage the use of business process modeling and automation

technology to more explicitly control and monitor their execution of processes.

򐂰 Not all integration technologies work as well across a wide area network or

the Internet as they do across a local area network.

The Web services technologies support multiple protocols, so they can use

the simplest protocols available, such as HTTP when that offers an

advantage, or leverage other infrastructures such as WebSphere MQ when

that is more appropriate.

For these reasons, SOA and Web services are often seen together as the future

direction for system integration. However, note that in Web services that WSDL

does not specify all that is implied by what SOA means by an interface. It does

not specify service levels, and it does not specify pre- and post- conditions.

BPEL4WS can do something equivalent but only for a subset of requirements,

for example in process models. All SOA projects have to make up this shortfall in

standard project documentation, custom service descriptions, or some other

means.

3.1.3 Messaging and SOA

SOAs that are based on reliable messaging and Enterprise Application

Integration middleware (for example WebSphere MQ and WebSphere Business

Integration Message Broker) support the principles of an SOA implementation

by:

򐂰 Decoupling the consumer’s view of a service from the actual implementation

of the service

򐂰 Decoupling technical aspects of service interactions

򐂰 Integrating and managing services in the enterprise

Decoupling the consumer’s view of a service from the actual implementation

greatly increases the flexibility of the architecture. It allows the substitution of one

service provider for another (for example because another provider offers the

same services for lower cost or with higher standards) without the consumer

being aware of the change, or needing to be altered to support it.

34 Patterns: Implementing Self-Service in an SOA Environment

This decoupling is better achieved by having the consumers and providers

interact via an intermediary. Intermediaries publish services to consumers

. The

consumer binds to the intermediary to access the service, with no direct coupling

to the actual provider of the service. The intermediary maps the request to the

location of the real service implementation.

Figure 3-3 shows requestor and provider connected using a messaging

infrastructure as intermediary.

Figure 3-3 Decoupling requestor and provider using messaging as intermediary

The SOA principles of granularity and modularity are primarily solved through the

proper structuring of the application. In contrast, the aspect of loose coupling is

greatly addressed by using messaging middleware.

Table 3-1 on page 34 shows an overview about the coupling aspects related to

the use of messaging middleware.

Table 3-1 Coupling aspects of messaging middleware

Coupling aspect Justification

Language independence The payload of a message can be passed

in a language independent manner. An

appropriate interface to the messaging

middleware needs to exist for requestor

and provider.

Transport protocol transparency The transport protocol used is

encapsulated by the interface of the

messaging infrastructure. A requestor

does not need to know if a provider is

connected using the same transport

protocol.

Location transparency For a service requestor or provider the

messaging infrastructure is just a

communication medium. A requestor does

not need to know the route a message

takes as long as it gets the result it

expects.