Here is a question has been on my
mind for quite some time - I have some strong viewpoints on it, but would like
to hear other viewpoints.
The general question is: When is something really a service-oriented
By this I do not mean "what is an SOA", "what characteristics does an SOA
have", etc. Rather, there seems to be a range of points on a continuum (call
it the "service continuum", perhaps) at which someone may declare that they
have implemented a service-oriented architecture.
In the past, I have pondered the
following more specific question (please note that this is all scoped to Web
Services-based SOA for ease of explanation):
If I have 2 Web Services that
communicate, do I have an SOA?
We can say "certainly not!". One
can do point-to-point integration with Web Services just as easily (to a
certain degree) as without, with redundant Web Services rather than shared Web
Services (a violation of one of the foundational tenets of SOA, which is
Now let's add some more
- The 2 Web Services share another Web Service in
common for their processing (i.e. we now have a "shared services"
- The service provider one or more policies for a service consumer that
interacts with it (these policies may address security, QoS, etc.)
- There is an electronic contract for interaction with the service
provider (e.g. WSDL)
Add to this the fact that many (correctly, IMO)
consider SOA to be a form of Enterprise Architecture, which (at least in my
mind) implies enterprise-level benefits.
So the more specific question is:
Given the second scenario above (with the various
added characteristics) and the fact that many consider SOA to be a form of EA
Is this second scenario large-scale enough that
it *really* may be considered SOA? IOW, how large-scale does such an
implementation need to be to *truly* be considered service-oriented
architecture? When does one arrive at that point?