+1.
Every time I see someone say "SOA implementation", "a SOA" (or "an SOA"), or
"implement our SOA", I get very frustrated. SOA is not a thing. It's a
design discipline; an approach to designing systems based on a set of design
principles. Unfortunately, the rest of the world doesn't see it that way. In
fact, I noticed in the recent "SOA compliant" discussion, folks like Todd
Biske and Eric Newcomer (both of whom know better) referred to SOA as a
thing. And you're absolutely spot on when you say that service-orientation
is just one of many architectural disciplines applied to a given system.
btw -- this a just a nit. (I deal with editors as a normal part of my job,
so I'm more aware of these things than most people.) I'm not sure if it was
you that attempted to correct Brass, Clements, and Kazman's grammar, or
whether you got it from another source, but the proper grammar is in fact
"...comprise software elements, the externally visible properties
of those
elements, and the relationships among them."
See this Usage Note from Dictionary.com [1]:
*"Usage Note*: The traditional rule states that the whole *comprises
* the parts and
the parts *compose* the whole. In strict usage: *The Union
comprises 50 states.
Fifty states compose* (or *constitute* or *make up) the
Union.*Even though careful
writers often maintain this distinction, *comprise* is increasingly
used in place of *
compose,* especially in the passive: *The Union is comprised of 50
states.* Our
surveys show that opposition to this usage is abating. In the
1960s, 53 percent
of the Usage Panel found this usage unacceptable; in 1996, only 35
percent
objected. See Usage Note at
include<http://dictionary.reference.com/browse/%20include>
.
[1] http://dictionary.reference.com/browse/comprise
Anne
On 7/2/07, Rob Eamon <[EMAIL PROTECTED]> wrote:
I wanted to get the various views that folks have on a phrase that
gives me pause: "implement an SOA" or "SOA implementation." IMO, this
phrase is off since an architecture (SOA or otherwise) isn't
something one implements. I wonder about the validity of my POV,
however.
The reasons I think that support my POV:
* While there is no single definition of "architecture" Booch,
Rumbaugh and Jacobson state that architecture "is the set of
significant decisions about the organization of a software system."
Architectural principles are decisions--"when faced with this set of
circumstances/needs, this architecture states that the approach shall
be X."
* Many posts on this forum, as well as various articles and blogs,
state that SOA is something you do, not something you buy or build.
It follows, then, that it cannot be implemented either.
* When used as a term in building construction, architecture seems to
be invariably used to describe the attributes or characteristics of
the structure. The building itself isn't called "the architecture"
nor is it considered an "architectural implementation."
* Service orientation is but one of many sets of principles applied
to a given system. This is probably a poor analogy but: A car has an
engine but I don't refer to the entire car as "the engine" nor as
an "engine implementation." :)
The reasons that I question the position:
* Brass, Clements and Kazman define architecture as "...comprise[d]
[of] software elements, the externally visible properties of those
elements, and the relationships among them." Clearly one can
implement/instantiate the elements of the architecture so "implement
the architecture" doesn't seem completely far fetched.
* Many, many people whose opinions I respect often say "SOA
implementation." I have a long held belief that architectures
aren't "implemented." But perhaps I need to let that view go.
I'm quite interested in hearing other points of view.
-Rob
