> A protocol influencing an architecture is a specific example of
> tight-coupling. That means that any change to protocol requires
> change to architecture. Hoo-boy, that's badness.
That's arguable. A protocol like HTTP has been around the globe a
while. One can assume fairly safely it will not change in a backward
incompatible way. An architecture that takes advantage of the HTTP
definition then might be a fairly stable one.
On the other hand I am searching for architecture guidance for
SOA. SOA per se is a general description of a wide range of
architectures. Within that range I would suggest HTTP could be used as
a more specific (i.e. formally defined) architecture.
Alternatively something like the Irish Public Services Broker has an
architecture based on a few simple message patterns and some other
interoperability guidelines for layering, message formats, etc. This
is again a more specific, formally defined, architecture in the SOA
family that is barely defined at all in terms of protocols. In this
case they specifically put a fairly open-ended set of protocols at the
edges of their architecture, on the lowest level of their
architecture.
So here are two example architectures, one based on a protocol that is
fairly stable the other also stable yet not based on any one protocol.
Both are loosely coupled in time, space, format, etc. Both are more
complete and useful than "SOA" generally or even SOAP/WSDL
specifically. I would much rather build a system based on an
architecture like HTTP, PSB, or even the JMS API than the
too-general-to-be useful descriptions that typically fall under the
SOA and SOAP umbrellas. Now most of what I have seen in that category
is badness, or at barely unusable.
-Patrick
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
