Re: Issues to think about in the MOM

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