W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2003

Re: Visibility (was Re: Introducing the Service Oriented Architec tural style, and it's constraints and properties.

From: Mark Baker <distobj@acm.org>
Date: Sat, 1 Mar 2003 18:42:44 -0500
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
Cc: www-ws-arch@w3.org
Message-ID: <20030301184244.G28917@www.markbaker.ca>

On Fri, Feb 28, 2003 at 06:17:26AM -0700, Champion, Mike wrote:
> I think he's answered it -- there's less visibility in an SOA style in an
> HTTP environment,

He didn't explicitly say that, which is why I was asking.

> or at least it's more expensive to achieve visibility, but
> more visibility in XML/SOAP-based SOAs in a multi-protocol environment.

Right, I got that part.

But an interaction is invisible if its semantics are other than those
expected by the component when examing the message for the action (in
HTTP, the method in the request line).  A SOAP message that says
"getStockQuote" has "getStockQuote" semantics, and is therefore
invisible to SMTP, HTTP, FTP, etc.. intermediaries that have no prior
knowledge of stock quotes.  Single vs. multi protocol support is a red
herring; visibility is reduced in both cases.

> What becomes of the original port numbers, IP addreses, HTTP headers, and
> HTTP methods when the message  that came in via HTTP gets relayed over MQ,
> BEEP, a JMS implementation, or whatever?

They are either dropped, consumed in order to modify the semantics of
the message, transformed without semantic loss, or are passed through

The important point for the purpose of this discussion being, that in
not all cases are the semantics of the message maintained.  And that's
assuming that there's even a semantically similar method with which to
do any bridging (i.e. HTTP POST <-> SMTP DATA); if there isn't, then in
no case are the semantics the same, and indeed, most multi-protocol
bridges or routers should fault in that case.

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
Received on Saturday, 1 March 2003 18:39:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:05 UTC