Migration and integration - Enterprise OSGi in Action - page 271

11.1 Managing heterogeneous applications

We introduced you to SCA as a remoting technology for OSG i in section 10.6, but SCA
is capable of much more than connecting two OSG i frameworks. Connecting one
OSG i service to another is only a fraction of what SCA can do.
In an ideal world, your entire enterprise architecture would be based on a single
technology, and that technology would—naturally—be OSG i-based. You would use
remote services to hook together the disconnected parts of your system. In practice,
we've never seen such an architecture, or at least not in an organization that had
more than a few developers, or one or two years of history. Although technologies
continue to evolve, old applications and systems based on old technologies can be
stubborn in refusing to go away. One truly impressive example we've seen of this had a
COBOL program providing information to a Python script, spanning nearly 50 years of
application development! Even applications developed at the same time by different
teams may be based on wildly varying technologies because of different development
styles or skill sets within the teams.
It's worse than that, though—even applications developed at the same time within
the same team may need to pick and choose capabilities from various technologies.
Although it pains us to admit it in a topic on enterprise OSG i, no single programming
model can handle all requirements. Being able to stitch together applications that
exploit the best capabilities of multiple technologies is clearly desirable.
How can these heterogeneous applications be managed and integrated? Are they
doomed to remain in technology-specific silos, or is there a way of breaching the tech-
nology boundaries and moving operations and data between systems and across pro-
gramming models? Over the years, there have been a number of attempts at
integration technologies, but in recent years efforts have focused on service-oriented
architecture ( SOA ) and the Service Component Architecture ( SCA ) technology. A dif-
ferent but related approach uses an Enterprise Service Bus ( ESB ) as an integration
container to manage communication between disparate system components.

11.1.1 Using SCA to integrate heterogeneous systems

In section 10.6, we showed how to use web services bindings to connect two OSG i com-
ponents together. SCA offers a range of bindings, so why web services? Part of the rea-
son is that web services is a popular way to integrate distributed or heterogeneous
applications. More pragmatically, web services is one of the few SCA bindings that are
easy to get up and running on your little stack; Apache Aries isn't intended to be an
application server, and the little sample assemblies don't include Java EE functionality
like EJB s, CORBA , or JMS runtimes.
Assuming you're running with more application server support, what other bind-
ings are available, and what else can SCA do for you in a heterogeneous environment?
At a high level, an SCA system consists of components and bindings. Components
are functional elements; bindings allow components to communicate with one
another. In general, components and bindings are mix-and-match, allowing business
logic to be neatly separated from communication protocols (see figure 11.1).