- From: Paul Denning <pauld@mitre.org>
- Date: Thu, 20 Nov 2003 17:51:41 -0500
- To: www-ws-arch@w3.org
At 01:17 AM 2003-11-20, Frank McCabe wrote: >Some issues to consider in the MOM > >1. Does correlation still belong? >2. Should we have message intermediaries? A web service, as we define it, must use SOAP, and SOAP defines intermediaries. Depends how you define "message intermediary". There should be a taxonomy of types of intermediaries, like [1]. Perhaps this is something we leave for the OWL ontology of WSA in the future. I imagine WSA should say something about some types of intermediaries, but others would be out of scope. SOAP 1.2 discusses soap forwarding intermediaries, and active intermediaries [2]. [1] http://www.rfc-editor.org/rfc/rfc3234.txt [2] http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#relaysoapmsg > Pro: Allows us to explain router-style intermediaries > Con: If a message has been modified in *any* way, is it still the same > message Some apps may not care if the message is modified. Others will care, in which case they should have a "feature" that allows the sender to tell intermediaries "do not modify in any way" mustUnderstand="true". (I'm not sure if any of the WS-* specs define this). See http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapinterminfoset >3. The SOAP notion of an envelope is essentially the outer wrapper of the >message infoset. However, SOAP 1.2 seems essentially silent on the >transport aspects of messages. I don't think we should be so silent; >especially since we cannot explain routers without it. However, the >natural place for this is in the envelope (after all, envelopes have >addresses written on them!) But you don't care if the postal service sends them by truck, boat or air transport. >3a. In effect, is an address that is used by a transport mechanism part of >the message or not? SOAP 1.2 has the notion of properties. For example, the property identified by [3] is defined in [4] [3] http://www.w3.org/2003/05/soap/mep/ImmediateDestination [4] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#bindformdesc You may be able to put the value of the properties in a message if you define a "feature" which includes the specification of a header block in which to place the properties. >What about message oriented audit trails? (Where the message carries with >it a record of its trajectory through the system.) The record of trajectory would be another "feature" with headers specified to carry the trajectory or hops (SOAP intermediaries). This gets into another issue about how to identify SOAP nodes. Do we identify a SOAP intermediary by it "role" URI used to target it? What if more than one node assume the same role? I don't think SOAP 1.2 says that a node is identified by a URI, but a message path is "The set of SOAP nodes through which a single SOAP message passes. " >3b. The current definition of envelope is not really consistent with the >SOAP view. However, it *does* capture the concept of a message's address. The message may not have an address. The recipient may have an address. The sender may have one. The sender and receivers of a message are metadata. A message has metadata, which may not be carried with the message. If you have the message, you don't necessarily know how to retrieve the associated metadata. And the metadata may be distributed (sender may not know recipients, 1st hop may know about 2nd hop, ...) >4. The diagram that is in the text does not reflect the discussion that we >had in Palo Alto. That includes delivery policies as well as intermediaries. I just remembered something I have thought about before: SOAP faults are "generated", but whether or not they are sent is a matter of policy. A hacker trying to attack a box may want to see what sorts of faults are received for various attacks. So a policy that returns faults to a sender may actually help the attacker figure out vulnerabilities. A different policy may be to audit the faults, and not send them to the originator, or perhaps to scrub the fault data to a minimum. Is a fault just another message for which a policy applies? Or do we have message policies and fault policies? Do we need to distinguish in the WSA? >Probably there is more, but this is a pretty good list already! > >Frank >
Received on Thursday, 20 November 2003 18:05:27 UTC