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

Mike,

I think this is getting pretty good.  Allow me to make a bit of rewrite that
I think ought to go into the document.  In general, I removed some of the
examples, as I wanted it more "definition-like".

Visibility is a desireable property, as described in a variety of
literature.
To the extent that Web intermediaries can make cacheing,
routing, filtering and other 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.  HTTP, IP, TCP, specifications
provide standardized places for intermediaries to examine for their
purposes.

On the other hand, XML provides two mechanisms that may be used for the
purposes of expressing properties that may be used by intermediaries.  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.  In the same manner as a intermediaries "knows"
about URIs,
the intermediary can "know" the standard location for a particular data
item.
One example is the "SOAP BODY first child element QName".
Secondly, XML has very robust and powerful mechanisms for dynamically
evaluating
arbitrary expressions, such as XQuery and XPath.

This flexibility comes at a cost in performance (since some, if not all, of
message must be parsed by the intermediary), 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).

Visibility and Security are linked.  The visibility that is provided to
intermediaries must be within the context of appropriate non-visibility of
secure information.  This provides a constraint upon the desirability of
the visibility property.

Visibility and Simplicity are linked.  As some applications may be designed
for use via multiple protocols, it is simpler (please note the IS as opposed
to MAY BE) to design them if the XML mechanisms can be re-used across the
protocols.  A standardardized format, or the use of dynamic queries, is
simpler
to configure and deply than a per-protocol format operator or query.  For
example, a
service across HTTP and SMTP, the options are to configure for both HTTP and
SMTP specific queries, or to perform an XML based query and a single HTTP
and SMTP method.  It may be simpler for an intermediary
to be configured if only XML mechanisms are used, rather than a large number
protocol and content specific areas.  One postulates that a "virtual"
infoset of all the
data in the message - IP address, port number, URI, message, headers,
attachments
- could be provided and queried against in a uniform manner.  This provides
simplicity and visibility, again with a degradation in performance.

The following should be in a "guidance" section.  The facts are above.

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.

> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
> Sent: Tuesday, February 25, 2003 6:38 AM
> To: 'Mark Baker '; 'David Orchard '
> Cc: 'www-ws-arch@w3.org '
> Subject: 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 16:49:53 UTC