Migration and integration - Enterprise OSGi in Action - page 274

By default, a method called onMessage is called on the bound component, but if the
component only has one method, then that will be called instead. Properties specify-
ing the method to call can also be added to incoming messages.
Although it's another binding, in practice the JMS binding has some different char-
acteristics from the web services and EJB bindings, and you may end up thinking
about the asynchronous nature of the JMS binding when you're designing your com-
ponent. For example, you may want to specify callbacks in your component definition
to allow two-way communication. If you're connecting to an external queue, you may
need to adjust the message format used by SCA to align with what's already in place.
You can specify the wire format, extra headers, and operation properties. You can also
use message selectors to filter incoming messages.
SCA is an extremely powerful and versatile technology for enterprise OSG i integra-
tion. After reading this section and section 10.6, you may be reeling slightly at how
versatile SCA is and how many possibilities there are. It's a big topic, so we can only
skim the surface of it here. If you're interested in learning more, we recommend Tus-
cany SCA in Action by Simon Laws, Mark Combellack, Raymond Feng, Haleh Mahbod,
and Simon Nash (Manning, 2011).
But wait—there are even more possibilities to consider. Not only is there more
than one way of integrating your application using SCA , there's a range of technolo-
gies beyond SCA that can be used for integration. Apache CXF , which worked so well
as a remote services implementation in section 10.4, is intended to be a more general
integration platform. Like SCA , it supports a range of component implementations
and standardized communications protocols, such as web services, and JMS . CXF itself
is a product supporting a range of standards, rather than a standard supported by a
number of products, as SCA is. The primary orientation of CXF is web services, so it
supports fewer languages and communication protocols than SCA .

11.1.2 Integrating using an ESB

A range of other integration technologies is available that falls into the general cate-
gory of Enterprise Service Buses, or ESB s. As the name suggests, ESB s are intended to
provide an adaptable asynchronous communications channel between loosely cou-
pled enterprise components. Mediations allow conversions between a range of mes-
sage formats and wire protocols (see figure 11.4).

ESBs and SCA
ESBs and SCA are designed to address similar problems—how can a technologically
diverse set of applications be knit together into a functioning system without lots of
hand-cranking and manual gluing? Importantly, though, an ESB is an architectural pat-
tern, rather than a specific standard like SCA. As a technology, ESBs predate SCA,
and many established ESBs started making use of SCA in some form or another after
its introduction. Some ESBs are based on SCA, whereas others support SCA compo-
nents as another type of deployable artifact.