Java Reference
In-Depth Information
So while integration happens, SOA attempts to address the pain points of integration efforts.
SOA facilitates reuse through loose coupling
The idea that SOA facilitates reuse through loose coupling is a key modification of the point
that it simply supports enterprise integration efforts. SOA suggests two distinct ideas: it facil-
itates reuse in the first place, and it does so by creating loosely coupled components.
Early enterprise integration or primitive service provider efforts have not focused quite so spe-
cifically on the idea of reuse. But it is now possible, given the new standards and the employ-
ment of a generic format such as XML in message exchanges, to realize enterprise services in
a sufficiently general way that services can be reused.
This reuse can come in the form of general interoperability. If two software components can
interoperate, that in no way means they are loosely coupled. But loosely coupled components
have a greater chance of interoperating.
NOTE
One of the foundational aspects of SOA is that services are created from the ground up with the in-
tention of having them interoperate with unforeseen or unknown components. This makes a sharp
distinction from typical integration efforts, which likely target a single set of known interfaces.
While reuse can be achieved as a side effect of ensuring that your services are loosely coupled,
it is not a necessary aim for every service. It is possible that you have certain services that you
know have little likelihood of being reused in a composition or within an unforeseen business
context. Such services may have been created as pilot projects; or it may have made sense
given the circumstances to create some functionality as a service in order to tap into a larger
architectural infrastructure to make it more visible, for example, through a service inventory;
or to take advantage of centralized schemas; or to quickly gain runtime metrics afforded by
SOA monitoring tools.
Reuse is not strictly necessary within any given service. However, an SOA entirely populated
by non-reusable components is likely not an SOA at all, but rather a fancy, bloated, over-en-
gineered collection of point-to-point EAI dinosaur bones.
Invoking services
Be careful allowing a service to directly invoke another service (that is, to have itself be the
client of that service), as this can strikingly reduce the business contexts available for reusing
the service. Sometimes it seems necessary to make one service the client of another service
within its implementation. But you are introducing a degree of coupling here that you might
