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

On Tue, Feb 25, 2003 at 07:37:54AM -0700, Champion, Mike wrote:
>  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.

Sounds good.

>  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.

Right.

>  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).  

Right.

> 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.

Right.

> OK, Mark, Walden, or whoever ... what don't you like about that?

I like what's there.  I don't like what's not there. 8-O

What's not in there, is any mention of the issue of what the impact is
on visibility, of using methods/operations/actions other than the
methods of the underlying application protocol.  Roy and I say this
reduces visibility.  Even Dave seemed to agree when he wrote;

 "The RESTful SOA has the advantage better visibility, as the firewall can
  simply examine the generic interface to determine the action being
  performed."
  -- http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0055

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis