Java Reference
In-Depth Information
Defining SOA
Problem
The term “SOA” is surrounded by hype, hyperbole, and generality. You want a definition that
you can work with.
Solution
You must define SOA with some modicum of care before proceeding in order to set expecta-
tions appropriately. This is made somewhat difficult given the avalanche of hype surrounding
SOA in recent years. But it can be done. There are many possible definitions of SOA. Here is
my offering:
SOAisakindofarchitecturethatusesservicesasbuildingblockstofacilitateenterpriseintegration
and component reuse through loose coupling.
Let's unpack that a little bit, shall we?
SOA is a kind of architecture
While this is perhaps overstating the obvious, there is a small lesson here. Simply creating
a set of services does not automatically render an architecture. Architecture, while it should
guide the creation of services, is a diverse matter separate from the implementation of the ser-
vices themselves.
In the term “SOA,” “service-oriented” modifies “architecture” as an adjective. That is, an
SOA describes a sort of architecture one can undertake. It is not a development mode. You
cannot simply annotate an EJB to indicate that it's a web service and decide that because you
now have a web service, you must have the felicitous beginnings of an SOA. If you are not
very careful with your approach, you could indeed have the beginnings of a very elaborate,
very expensive mess.
One point that must be made is that you cannot simply buy an SOA. You cannot expect a
single vendor to hand over an SOA once your CIO writes a check. Building an SOA involves
considerable analysis and integration.
SOA is built with services
This is the “service” part of “service-oriented architecture” and I rely here on my definition in
Defining a Service
.
It's not an SOA if it's not an architecture, or if that architecture doesn't use
