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 Monday, 19 March 2001 12:38:58 UTC