Services-Based Enterprise Integration Patterns Made Easy

This serial article presents some of the central concepts and features
of enterprise integration patterns, introducing several basic concepts
and features involved in Service-Oriented Architecture (SOA). Part 1
and Part 2 of this series describe the basic concepts essential for
understanding a services-based integration pattern. These concepts
include loose coupling, code reuse and layering, language and platform
independence, language independent interface, the idea of discovering
a remote object at run time, invoking methods remotely, and asynchronous
messaging for scalability. To improve on RPC functionality, two methods
are used: (1) Distributed objects, also known as the Object Request
Broker (ORB): This approach focuses on code reuse and language
independence. (2) Asynchronous messaging: This approach addresses the
problem of tight coupling between applications. In addition to
introducing the benefits of object orientation, such as inheritance,
polymorphism, and encapsulation, CORBA introduced a number of new
features. Probably the most important was the concept of ORB, which
extracted the code for marshaling input and output arguments and the
code for communication from the client and server applications into a
separate software component. In addition, ORB provides a facility to
get a reference to a remote object so that methods can be invoked on
that remote object. This separation let the same code be reused by
many applications and allowed a certain amount of decoupling between
the applications by moving away from point-to-point integration. This
move away from point-to-point integration may be considered the first
step in the evolution of the concept of ESB. A parallel development
based on asynchronous messaging contains the seeds for the development
of another type of ESB. This type of ESB provides a more scalable
solution than the ESB type based on ORB. In asynchronous messaging,
the client or client object sends a message to the target application,
but doesn't wait for the response to continue its work. This leads
to a certain amount of decoupling between the applications involved.
Thus asynchronous messaging may be employed as the integration basis
if high transaction volumes are expected. In messaging, the
applications don't communicate with each other directly and don't
have a dedicated communication link established between them. Instead,
they communicate indirectly through queues. A central message broker
can receive messages from different applications, determine the
correct destination for each message type, and route the message to
the appropriate destination application. This lets applications
communicate with each other without knowing the location of the
receiving applications.