Enterprise Service Bus (ESB) - Guide to Cloud Computing for Business and Technology Managers - page 198

and externally integrated environments routinely require additions and
changes to business processes.
Specialized capabilities such as BPM software solutions provide
workflow-related business processes, process analysis, and visualization
techniques in an ESB setting. In particular, BPM allows the separation of
business processes from the underlying integration code. When sophisti-
cated process definitions are called for in an ESB, a process orchestration
engine—which supports BPEL or some other process definition language
such as ebXML Business Process Specification Schema (BPSS)—may be lay-
ered onto the ESB. The process orchestration may support long-running
stateful processes. It may also support parallel execution paths, with
branching and merging of message flow execution paths based on join con-
ditions or transition conditions being met. Sophisticated process orchestra-
tion can be combined with stateless itinerary-based routing to create an
SOA that solves complex integration problems. An ESB uses the concept of
itinerary-based routing to provide a message with a list of routing instruc-
tions. In an ESB, routing instructions, which represent a business process
definition, are carried with the message as it travels through the bus across
service invocations. The remote ESB service containers determine where to
send the message next.
9.2.4 ESB Transport-Level Choices
Finally, before we close this section, it is important to understand the
transport-level protocol choices that can be used in conjunction with an ESB.
Web Services in the ESB can communicate using SOAP messages over a vari-
ety of protocols. Each protocol effectively provides a service bus connecting
multiple endpoints. Currently, the most common service bus transport layer
implementations include SOAP/HTTP(S) and SOAP/JMS.
The SOAP over HTTP service bus is the most familiar way to send
requests and responses between service requestors and providers. As
already explained in Chapter 2, Section 2.1.2 “TCP/IP Protocol”, HTTP is
a client-server model in which an HTTP client opens a connection and sends
a request message to an HTTP server. The client request message is to invoke
a Web Service. The HTTP server dispatches a response message containing
the invocation and closes the connection. The use of an ESB enables the ser-
vice requestor 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.
JMS, part of the J2EE standard, provides a conventional way to create,
send, and receive enterprise messages. While it does not quite provide the
level of interoperability based on the wide adoption that the HTTP ESB can
boast, the SOAP/JMS ESB brings advantages in terms of QoS. A SOAP/JMS