RE: Issues to think about in the MOM

Frank,

I don't understand why you consider this mechanism disingenuous. I think you object to the potential disconnect between the message processing aspects and the aspects related to routing across different intermediaries.

Please keep in mind that intermediaries can be present on behalf of the originator and/or the ultimate receiver (the distributed state machine you mention), but can also be inserted (some times after the initial deployment of originator and receiver) by third parties (e.g. part of an overall system performance monitoring framework) and have no semantic relationship to the service itself.

One thing I found useful in the past is to review all the possible ways an intermediary can be interposed between originator and ultimate receiver. Here is a list (taken from a recent presentation by Mark Nottingham):

- IP address interception (e.g., "transparent proxies")
- DNS address interception/redirection (e.g., Akamai, "virtual hosting")
- HTTP proxy configuration (and autoconfiguration...)
- IP routing interception (e.g., firewalls)
- HTTP redirection (Status code 30x)
- SOAP routing / redirection  (e.g., WS-Routing, WS-Addressing)
- WSDL-based extensions
- Using application-specific semantics

As you can see, in some cases the routing is done deep below the transport itself and is not under the control of anything that the SOAP spec directly talks about. I think that is good, because it allows for a whole variety of different uses for SOAP intermediaries.

Ugo

> -----Original Message-----
> From: Frank McCabe [mailto:frankmccabe@mac.com]
> Sent: Wednesday, November 19, 2003 10:42 PM
> To: Ugo Corda
> Cc: www-ws-arch@w3.org
> Subject: Re: Issues to think about in the MOM
> 
> 
> Ugo:
>   SOAP talks about binding; but, in SOAP-land, that is really the 
> relationship between a message and how it should be processed. In 
> addition, binding is essentially outside the message itself:
> 
> The creation, transmission, and processing of a SOAP message, 
> possibly 
> through one or more intermediaries, is specified in terms of a 
> distributed state machine. The state consists of information 
> known to a 
> SOAP node at a given point in time, including but not limited to the 
> contents of messages being assembled for transmission or received for 
> processing. The state at each node can be updated either by local 
> processing, or by information received from an adjacent node.
> 
> I.e., SOAP binding is viewed as an aspect of the state of nodes that 
> are processing messages; and don't have much to do with the message 
> itself.
> 
> I don't particularly quarrel with this view; but I think it is 
> disingenuous. In particular, contrary to the SOA view of things, it 
> focuses on the internals of SOAP processors rather than the messages 
> being exchanged. We need to some more clarity here.
> 
> Frank
> 
> On Nov 19, 2003, at 10:36 PM, Ugo Corda wrote:
> 
> > Frank,
> >
> >> SOAP 1.2 seems essentially silent on the transport aspects of 
> >> messages.
> >
> > I don't fully understand what you are referring to. Could 
> you please 
> > clarify?
> >
> > Thank you,
> > Ugo
> >
> >> -----Original Message-----
> >> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org]On
> >> Behalf Of Frank McCabe
> >> Sent: Wednesday, November 19, 2003 10:18 PM
> >> To: www-ws-arch@w3.org
> >> Subject: Issues to think about in the MOM
> >>
> >>
> >>
> >> Some issues to consider in the MOM
> >>
> >> 1. Does correlation still belong?
> >> 2. Should we have message intermediaries?
> >>    Pro: Allows us to explain router-style intermediaries
> >>    Con: If a message has been modified in *any* way, is it 
> still the
> >> same message
> >> 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!)
> >> 3a. In effect, is an address that is used by a transport
> >> mechanism part
> >> of the message or not? What about message oriented audit
> >> trails? (Where
> >> the message carries with it a record of its trajectory through the
> >> system.)
> >> 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.
> >> 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.
> >>
> >> Probably there is more, but this is a pretty good list already!
> >>
> >> Frank
> >>
> >>
> 
>

Received on Thursday, 20 November 2003 12:19:52 UTC