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

 

-----Original Message-----
From: Mark Baker
To: David Orchard
Cc: 'Champion, Mike'; www-ws-arch@w3.org
Sent: 2/25/2003 8:12 AM
Subject: Re: Visibility (was Re: Introducing the Service Oriented
Architectural style, and it's constraints and properties.

> Fair enough.  But do you agree with Mike that visibility is *improved*
> by the SOA style, or not?  You previously claimed it was reduced.

I think Dave Orchard and I are more or less on the same wavelength here.
Here's how I'd put it, perhaps as a draft paragraph for the document.

 Visibility is a desireable property [for reasons we could steal from Roy or
Mark :-) ], and the lower down the protocol stack you go, the more "visible"
attributes are.  To the extent that Web intermediaries can make cacheing,
routing, and filtering decisions based on IP address, TCP port number, or
HTTP URIs, headers, and methods, they will be easier to implement and more
robust across platforms or time, and can work even if the format of the
message body is unknown or encrypted.  On the other hand, if message bodies
are in one or more standardized XML-based formats, this allows
intermediaries to perform cacheing, routing, and filtering based on the
content of the message, and as of this writing actual firewall products are
available that implement this approach.  For example, routing can be done on
the basis of WS-Routing SOAP headers, or XPath or XQuery examination of the
actual message payload; firewalls can use WS-Security headers and/or XACML
assertions to make quite fine-grained decisions as to whether to allow a
specific message from a specific user requesting a specific service to pass
through.  This flexibility comes a a cost in performance (since the entire
message must be parsed by the firewall), robustness in the face of change
(since knowledge of actual message formats must be propagated to the
intermediaries as well as the endpoints), and could require security
tradeoffs (since message content would have to be decrypted before being
examined).  

Actual specwriters and systems designers must consider the costs and
benefits of exploiting the visibility that XML messages offer and design
accordingly.  For example, visibility considerations might mandate a
separation of information that is clearly confidential from information that
intermediaries may use to operate on.  This can work both ways: A pure REST
approach might compromise security if confidential information is encoded in
URIs (e.g., the identity of the user requesting a specific resource), or a
pure REST approach might enhance security by allowing the entire contents of
a resource representation to be encrypted in a manner that only the ultimate
consumer of a representation can decrypt while allowing intermediaries to
make decisions based on URI, HTTP method, etc.  In any event, a better
appreciation of the Web Services Architecture and the possibilities it
enables should allow better engineering decisions by designers.

OK, Mark, Walden, or whoever ... what don't you like about that?  How about
you Dave ... are we on the same wavelength, and can you suggest
improvements?  Editors, do we have anything like this in the document, and
do you agree that something like this SHOULD be in there somewhere?

Received on Tuesday, 25 February 2003 09:38:30 UTC