Patterns: Implementing Self-Service in an SOA Environment

128 Patterns: Implementing Self-Service in an SOA Environment

6.4 Integration technologies

With the continuous progress of enterprise computing, more and more

enterprises are finding the need to adopt new technologies quickly and integrate

with existing applications. Furthermore, it is often not feasible for enterprises to

completely discard their existing infrastructure, due to limitations in cost and

human resources.

Enterprise application integration (EAI) allows disparate applications to

communicate with each other. Some points you should consider while deciding

on the integration technology between your application and the enterprise tier

applications are as follows:

򐂰 The current infrastructure

Do you already have a messaging system on the enterprise tier? Then it

makes sense to go for JMS. Or if you have an existing system, such as CICS

or IMS, J2EE Connectors might be the better choice.

򐂰 Time to market

Web service enabling an application is relatively fast with the Web services

development tools available.

򐂰 Future expansion plans

If you plan to expand your enterprise systems in the future, keep in mind the

integration with your current infrastructure and your planned infrastructure.

Web services can provide the most cost-effective migration path in such a

case.

򐂰 Reliability

JMS with WebSphere MQ, for example, can be used to provide assured

transfer of data, even when the enterprise application is unavailable.

򐂰 Transaction support

Web services currently do not offer support for transactions. If your

application needs transactional management, it might be worthwhile to

consider either JMS or J2EE Connectors.

6.4.1 Web services

Web services is a recent reinvention of concepts that have been around for

sometime. They introduce many new advantages and capabilities. In a sense,

none of the function provided by Web services is new; CORBA has provided

much of this function for many years. What Web services does do that is new is

to build upon existing open Web technologies such as XML, URL and HTTP.

Web services are defined in several different standards such as SOAP and

Chapter 6. Technology options 129

WSDL which build upon general Web and other Web services standards. These

standards are defined by the World Wide Web Consortium, the Organization for

the Advancement of Structured Information Standards (OASIS) and Web

Services Interoperability Organization (WS-I).

The basic Web services support provides for three simple usage models. These

are:

򐂰 One-way usage scenario

A Web services message is sent from a consumer to a provider and no

response message is expected.

򐂰 Synchronous request/response usage scenario

A Web services message is sent from a consumer to a provider and a

response message is expected.

򐂰 Basic callback usage scenario

A Web service message is sent from a consumer to a provider using the

two-way invocation model, but the response is just treated as an

acknowledgement that the request has been received. The provider then

responds by calling making use of a Web service callback to the consumer.

Other Web service standards are built upon these basic standards and

invocation models to provide higher level functions and qualities of service.

Examples of these standards are WS-Transaction, WS-Security and

WS-ResourceFramework.

One of the main aims of Web services is to provide a loose coupling between

service consumer and service providers. While this is limited to a certain extent

by a requirement for the consumers and providers to agree on a WSDL interface

definition, Web services have been created with significant flexibility with regard

to their location. Figure 6-4 on page 130 shows how the Web services interaction

model has been designed with this form of loose coupling.