Web services

Web services are a common implementation of an SOA. They offer a standard interface for many different types of endpoints (such as J2EE, messaging, and enterprise systems) and therefore are well suited to an ESB architecture. Web services can communicate using SOAP messages over a variety of protocols. Each protocol effectively provides a service bus between multiple endpoints. The most common service bus implementations include:

򐂰 HTTP service bus

򐂰 JMS service bus

6.1.1 HTTP service bus

The HTTP service bus is the most familiar way to send requests and responses between service requesters and providers, due to wide adoption of the HTTP protocol through the creation of the Internet. Even non-transactional companies are connected to the Internet and are therefore able to use the HTTP service bus inter-enterprise.

Organizations are already well-equipped to handle HTTP security requirements and have put in measures to ensure that only valid HTTP requests are received through firewalls, proxy servers, demilitarized zones, HTTP servers,

authorization, authentication procedures, and so forth. As a result, HTTP is usually one of the first transport layers an organization would use when thinking about inter-enterprise solutions.

Figure 6-1 on page 155 shows the implementation of services on an HTTP service bus. This is an implementation of the Application Integration::Direct Connection runtime pattern.

Chapter 6. Endpoint enablement roadmap 155 Figure 6-1 Runtime pattern and Product mapping for an HTTP bus

Use of an ESB extends the HTTP service bus concept. It enables the service requester to communicate using HTTP and permits the service provider to receive the request using a different transport mechanism.

Many ESB implementation providers have an HTTP service bus in addition to at least one other protocol. Any of these protocols can be used for ESB interactions and often are chosen based on service-level requirements.

Advantages of HTTP

There are several advantages to using HTTP as a transport for Web services interactions, including:

򐂰 HTTP is a widely adopted protocol. Any organization with a Web server has implemented HTTP, and any client that uses a Web browser uses HTTP. Therefore, the HTTP infrastructure is widely available.

򐂰 The HTTP protocol is open and deployed on many different system types, including non-traditional computing devices such as PDAs.

򐂰 Most enterprises allow HTTP to travel freely through protocol firewalls. Therefore, there are fewer barriers to extended enterprise use of HTTP as a transport for Web services.

WebSphere Application Server V5.1 Windows 2000 + SP4 SO AP Pr ov id er Internal network App Server/ Services App Server/ Services App Server/ Services <Service Provider>

<Service Consumer> <Service Provider>

Adapter Connector Adapter

Connector ConnectorAdapter

SO AP Pr ov id er WebSphere Application Server V5.1 Red Hat Linux AS 2.1

SOAP 1.1 / HTTP 1.1 JA X -R P C JA X -RP C <Service Bus>

Disadvantages of HTTP

HTTP is a lightweight and stateless protocol that was not originally designed to carry application data. Disadvantages of using it for Web services include:

򐂰 The protocol is stateless. If any state data is required to maintain an

application session, the applications must create and manage the state data.

򐂰 HTTP is not a reliable protocol. If reliable delivery of application data is required, the application must either:

– Develop a reliability framework, such as exchanging receipt messages. – Use a more reliable protocol.

Further information

For more information about the design, development, and runtime of an HTTP service bus, consult Chapter 5, “HTTP service bus” in the redbook Patterns: Service-Oriented Architecture and Web Services, SG24-6303.

6.1.2 JMS service bus

While it does not quite provide the level of interoperability based on the wide adoption that the HTTP service bus can boast, the JMS service bus brings advantages in terms of quality of service.

JMS, part of the J2EE standard, provides a conventional way to create, send, and receive enterprise messages. A JMS service bus can provide asynchronous and reliable messaging to a Web service invocation. This means that the requestor can receive acknowledgement of assured delivery and communicate with enterprises that may not be available.

Figure 6-2 on page 157 shows the implementation of services on an MQ bus, using JMS. This is an implementation of the Application Integration::Direct Connection runtime pattern.

Chapter 6. Endpoint enablement roadmap 157 Figure 6-2 Runtime pattern and product mapping for an MQ bus using JMS

As with the HTTP service bus, use of an ESB extends the JMS service bus, enabling service requesters and providers to communicate using different protocols.

IBM JMS implementations

IBM provides two implementations of JMS:

1. A JMS provider included with WebSphere Application Server V5.1

(Embedded Messaging), which can be used for asynchronous communication between applications running on WebSphere Application Server V5.1 servers.

2. IBM WebSphere MQ V5.3 includes built-in JMS Provider support with enhanced performance features for integrating JMS applications with other applications. IBM WebSphere MQ takes care of network interfaces, assures once and once-only delivery of messages, deals with communications protocols, dynamically distributes workload across available resources, and handles recovery after system problems. IBM WebSphere MQ is available for most popular operating system platforms.

W e bSphe re A p pl ic at ion S e rver V5.1 Internal network App Server/ Services App Server/ Services App Server/ Services <Service Provider>

<Service Consumer> <Service Provider>

Adapter Connector Adapter

Connector ConnectorAdapter

W ebSph er e MQ V5. 3 W e bSphe re A p pl ic at ion S e rver V5. 1 W ebSph er e MQ V5. 3

Windows 2000 + SP4 Red Hat Linux AS 2.1

WebSphere MQ

Advantages of JMS

There are several advantages to using JMS as a transport for Web services interactions, including:

򐂰 JMS provides a more reliable transport than alternatives such as HTTP.

򐂰 Asynchronous requests can be deployed readily.

򐂰 It leverages existing, enterprise-proven messaging systems.

Disadvantages of JMS

Although JMS is an open standard for Java-based systems, the actual transport system must be provided by a software product. Therefore, there are several considerations, including:

򐂰 The communicating Web services must have access to JMS providers that can communicate with each other. Generally, this implies that the same product must be installed. For example, both systems must have IBM WebSphere MQ installed.

򐂰 JMS is a Java-based standard and is not as readily accessible to systems that are not based on Java.

These disadvantages only occur for use with the Direct Connection pattern. That is, the service requestor and service provider have adopted use of the same product (IBM WebSphere MQ, for example). When using an Enterprise Service Bus, this is not necessarily a requirement.

Keep in mind that the capabilities of an ESB, which are listed in 4.3, “A capability model for the Enterprise Service Bus” on page 82, identify protocol

transformation as ESB functionality. This means that by using an Enterprise Service Bus as a key component of the SOA, two organizations can send and receive messages regardless of the original message structure.

Using the ESB capabilities enables:

򐂰 A service provider to receive a JMS message that is sent from a service requester that originated from different JMS providers.

򐂰 A service provider to receive a JMS message that is sent from a service requester that originated the call using HTTP.

Further Information

For more information about the design, development, and runtime of a JMS service bus, consult Chapter 6, “JMS service bus” in the redbook Patterns: Service-Oriented Architecture and Web Services, SG24-6303.

Chapter 6. Endpoint enablement roadmap 159