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

these components are only the external facade of existing ESs that do the real
processing activities.
It is useful to clarify their meaning and intended purpose of wrappers.
A (component) wrapper is nothing but an abstract component that provides
a service implemented by legacy software that can be used to hide existing
system dependencies. In a nutshell, a wrapper performs specific business
functions, has a clearly defined API, and can appear as standard components
for clients and be accessed by using modern industry protocols. Wrappers
are normally deployed in modern, distributed environments, such as J2EE or
.NET. A wrapper can provide a standard interface on one side, while on the
other, it interfaces with existing application code in a way that is particular to
the existing application code. The wrapper combines the existing application
functionality that it wraps with other necessary service functionalities and
represents it in the form of a virtual component that is accessed via a stan-
dard service interface by any other service in an ESB. When a legacy busi-
ness process is wrapped, its realization comprises code to access an adapter
that invokes the legacy system. An adapter, unlike a wrapper, does not con-
tain presentation or business logic functions. It is rather a software mod-
ule interposed between two software systems in order to convert between
their different technical and programmatic representations and perceptions
of their interfaces. Resource adapters translate the applications' messages to
and from a common set of standards—standard data formats and standard
communication protocols.
Application servers are principally J2EE based and include support for
JMS, the Java 2 Connector Architecture, and Web Services; these technolo-
gies help implement application servers in the context of the ESB. Recall
from Chapter 5, Section 5.5.2 “Java Messaging Service” that JMS is a
transport-level vendor-agnostic API for enterprise messaging that can be
used with many different MOM vendors. JMS frameworks not only func-
tion in asynchronous mode but also offer the capability of simulating a
synchronous request/response mode. For application server implementa-
tions, JMS provides access to business logic distributed among heteroge-
neous systems. Having a message-based interface enables point-to-point
and publish/subscribe mechanisms, guaranteed information delivery, and
interoperability between heterogeneous platforms.
JCA is a technology that can be used to address the hardships of integrat-
ing applications in an ESB environment. It provides a standardized method
for integrating disparate applications in J2EE application architectures. JCA
defines a set of functionality that application server vendors can use to con-
nect to back-end EISs, such as ERP, CRM, and legacy systems and applica-
tions. It provides support for resource adaptation, which maps the J2EE
security, transaction, and communication pooling to the corresponding ES
technology. When JCA is used in an ESB implementation, the ESB could
provide a JCA container that allows packaged or legacy applications to be
plugged into the ESB through JCA resource adapters. For instance, a process