<<It seems that I am not as flexible as I believed I could be on my
thinking regarding SOA. I attempted to categorize various SOA
engagements in my SYS-CON article entitled "A Classification Scheme for
Defining SOA" (http://soa.sys-con.com/node/820406). I believed that I
could hide my dissatisfaction with the lack of clarity surrounding SOA
by lumping SODA/application development into its own subcategory. I was
wrong! When it comes down to it, there's still just too much ambiguity
surrounding the term service.
So, you might ask, "What is the big deal if we call everything running
on a computer a service?" The answer is that not all services are
created equally and there's no way to determine the type or extent of
services when a single term is used as a catch-all.
For me, SOA is defined precisely as follows:
/Service-Oriented Architecture (SOA) is an archetype---an architectural
pattern ---that focuses on design of systems from the perspective of
providers and consumers as defined by a contract. SOA-based designs
introduce agility by enabling interchangeability of service providers
without requiring process changes in the consumers. Hence, the SOA is
applied at the system level, not just at a single component within a system.
/
Because I define SOA as an archetype, you can not have a direct instance
of SOA, you can use SOA to define a new architecture, which can then be
used to create instances of systems. For example, Service-Oriented
Integration (SOI), Web 2.0 and Cloud Computing are all architectural
types based on the SOA archetype. However, to put things in context,
FedEx and UPS, as businesses, are also SOA architectures. Needless to
say, if you follow the laws of object-orientation, it's not invalid to
identify an object by it's topmost ancestor, but in doing so you lose
the object's essence. This is a great technique for lumping things
together in a collection, but horrible if you want the richness and
value of the object to come through.
Of the three technology-related architectures based on SOA listed above,
SOI and Web 2.0 clearly have a strong software connection. Some identify
the the software component that has a SOAP or HTTP interface as a
service. Well, just as SOA is an archetype, service is an archetype as
well, and, indirectly, these software components are services given that
they derive from the service archetype.
To better understand my point we need to explore the technical
ramifications of this for a moment. With the growth of TCP/IP as a
ubiquitous networking protocol, so grew the concept of client/server
computing. In client/server computing, a user interface application
consumes networked software services to provide data on demand versus
having the application exist as a monolithic entity on a single
computer. Client/Server computing enabled networked shareable resources.
If I didn't use the term Client/Server in the above paragraph, 9 out of
10 technical people today would say I was talking about SOA. So, is
everyone who is developing systems using Web services today really just
doing Client/Server? I believe so, but that wouldn't be popular, after
all, there aren't hundreds of job openings for client/server architects
right now.
[Sidebar Note: What are these people asking for SOA architects really
looking for if it's not client/server experience? From what I've seen,
it's typically experience with a particular vendor's software for
building distributed applications. But, to those people I warn you "big
mistake". The underlying standards will not make it significantly less
expensive to switch from that tool to another one.]
To summarize, no one who claims to be doing SOA would openly admit
they're just really doing client/server. There is a subset of people
doing SOA that are actually focusing on modeling the business as a set
of functional service areas (these people are really doing SOA). Then,
there's a bunch of people developing software components using a
client/server design pattern claiming they're doing SOA.
So, I ask you, do you still think that a common definition of SOA is not
needed in the industry?>>
*You can read JP's blog at:
http://www.jpmorgenthal.com/morgenthal/index.php?entry=entry090502-120251
Gervas*
