- From: David Orchard <dorchard@bea.com>
- Date: Tue, 25 Feb 2003 10:39:08 -0800
- To: <www-ws-arch@w3.org>
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