RE: SOAP actor model

Henrik,

So I think that this is clear - let me see if I've got it:

From the SOAP 1.1 spec defenition of the actor attribute [1]: "A SOAP
message travels from the originator to the ultimate destination, potentially
by passing through a set of SOAP intermediaries along the message path. A
SOAP intermediary is an application that is capable of both receiving and
forwarding SOAP messages. Both intermediaries as well as the ultimate
destination are identified by a URI."

Which seems to imply that originator, ultimate destination and intermediary
are all 'SOAP applications' and that an the value carried in an actor
attribute is a URI that denotes a 'SOAP application'.

From [2] "A SOAP application receiving a SOAP message MUST process that
message by performing the following actions in the order listed below:..."

It is then the responsibility of the 'SOAP application' to understand (and
presumably apply) the rules associated with processing the header element
targetted at the 'application'.

I also think, that although SOAP 1.1 uses terms like 'processor' and
'application' it doesn't make a clear distinction between them (there are no
glossary defns) and it is probably best to think of there being a one-to-one
mapping between 'SOAP processor' and 'SOAP application' - this would mean
that identifying one implicitly identified the other.

I think that the abstract model (fig 2.1 and the derivative in the new
requirements document [3]) are broadly in line with this... which would seem
to put the burden on the 'SOAP/XMLP application' to dispatch particular
handlers and (implicitly) to be sensitive to any processing order
dependencies.

Basically: The answer to the question "What sort of thing is an SOAP
header/XMLP block target at?" is "A SOAP/XMLP processor and/or it's
associated application."

Does this seem anywhere close to your world view?

> Are there any scenarios that this model doesn't cover regarding
> targeting?
> 

Personally, simply on the matter of targetting I think I understand it and
it looks fine. Where I have a little trouble answering the question directly
is that when I think of looking at a SOAP message with a bunch of headers,
say each header targetted (by URI) at a different SOAP processor/application
I don't know where to send it to next nor how to make that choice. Without
other guidance I guess that I'd make an arbitrary choice on where next based
on the headers present in the message at the time it needs to be sent on to
it's next destination. I'm also not at all sure how the ultimate destination
is carried with the SOAP message, so how is, say, the last SOAP intermediary
in a message path meant to determine the ultimate destination intended by
the original sender?

So in principle I think I could answer your question in the negative,
however, I find that the lack of guidance on how to select a next
destination along a path leaves me feeling that not enough has been
specified in SOAP (yet) make intermediaries and paths useful.

Stuart

[1] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383499
[2] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383491

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:frystyk@microsoft.com]
> Sent: 19 March 2001 17:36
> To: 'Williams, Stuart'; 'Mark Nottingham'
> Cc: 'Mark Jones'; xml-dist-app@w3.org
> Subject: SOAP actor model
> 
> 
> 
> Forgot to include xml-dist-app :(
> 
> ***
> 
> >Not sure... I first came across this notion reading an
> >Overview document from the Apache SOAP 3.0 team at [2] 
> >(overview.pdf pp12-13) who seemed to be wrestling with how to 
> >handle the SOAP actor attribute.
> >
> >I haven't been tracking their work closely, so their thinking
> >may have moved on.
> 
> The model of the SOAP actor attribute is intended to be quite 
> simple. It is based on the following assumptions:
> 
>   * Any SOAP processor is identified by a unique URI
>   * This identifier can be used to target one or more blocks
>     at that SOAP processor
> 
> This is in many ways a generalization of what we have in HTTP with the
> Connection header field. The only difference is that in SOAP *all*
> parties in a message path are identified by URI - not only the final
> destination.
> 
> SOAP defines two URIs that identify special case SOAP processors:
> 
>   * the next guy: actor value of
"http://schemas.xmlsoap.org/soap/actor/next"
>   * the end: indicated by not using "actor"
> 
> The reason is that these actors are so commonly used that it is nice to
> be able to use them independently of where the message is actually going
> or how it gets there. For example, an initial sender might dynamically
> be routed between a set of "next" actors but doesn't want to change the
> message each time. The same is the case for the ultimate destination
> which can get redirected quite often but again, we don't want the whole
> message to change because of that.
> 
> The semantics of inserting a block into a message is like establishing a
> contract between the party responsible for the message and the party
> receiving it. If an intermediary inserts a block into the message then
> it does so on behalf of the initial sender as this is who the
> intermediary is acting on behalf of.
> 
> It also means that an intermediary cannot take a block out if it is not
> intended for it. There is nothing that prevents it from looking at
> blocks not intended for it, however. If this was not true then we
> couldn't build caches and signature verifiers for example.
> 
> Handlers as such do not have names as they are always associated with a
> processor. However, modules have names which is the XML NS URI of that
> module. How a processor finds a handler is an implementation choice but
> it could for example be based on the XML NS URI of the module. 
> 
> When we look at the XML NS URIs and the actor URIs we in fact have two
> names in a SOAP message:
> 
>   * The actor URI identifies the "name" of the receiving SOAP processor
>   * The XML NS URI identifies the "type" of the block.
> 
> Combining the two provides a fair amount of flexibility. It allows me to
> target specific blocks at specific actors and allows me to introduce
> blocks that can be looked at by everybody in the chain. The actor model
> can of course be combined with the optional/mandatory flag in which case
> there are even more options.
> 
> There is one combination that might warrant some more thought and that
> is the combination of "mandatory for all parts in a message path". The
> way that I would build that would be to use the "next" semantics and
> define it as part of the "mustUnderstand" semantics of the module that
> it is intended to be reinserted in the message path. 
> 
> Are there any scenarios that this model doesn't cover regarding
> targeting?
> 
> Thanks,
> 
> Henrik

Received on Tuesday, 20 March 2001 08:43:46 UTC