RE: Protocol independence

> Is that SOA?  Beats me ... I think a case can be made that 
> it's SOA because 
> it's distributed, loosely coupled, standards-based, and can 
> be conceived of 
> as a "service" providing business value.  It's not SOA if you 
> use that term 
> (as we sometimes do in these discussions) as a shorthand for 
> "CORBA-like 
> distributed object systems."

I was using "SOA" in the way Dave Orchard used when he proposed text
to define the SOA style[1].

Unlike tuple space based systems (TBS), or REST, SOA places no
constraints on component interface semantics.  So my question about
whether I was required to treat my TBS as an SOA, is asking whether,
in order to use Web services with my system, I have to relax that
constraint?

Alternately, if I don't have to, then I can presume that all the
existing constraints remain after I use Web services.  That means
that you can't send "getStockQuote" requests over write(); you'd have
to get stock quotes via read().  So you'd still have a disparity of
protocols (tuple spaces, HTTP, SMTP, etc..), but when binding SOAP to
these protocols, the semantics of those protocols - and the interface
constraints of the architecture that those protocols work within -
would be preserved.

What I described in that paragraph is the use of Web services
technologies (well, SOAP anyhow) that I see great value in, as it
meets every requirement of the WSA, yet leverages the desirable
properties of other architectures.  It is "protocol independant" in
that a disparity of protocols are supported, yet it doesn't require
that all application protocols be treated the same way (i.e. as
transport protocols).

 [1] http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0055

MB

Received on Friday, 4 April 2003 10:58:40 UTC