RE: Proposal for new last call issue: Some unprocessed headersshould stay

The "relay" role seems to put soap extension designers into a 
straitjacket if it means that for all time there will be only one role at 
which one must target header blocks to elicit the "forward-if-not-
understood" behavior.

The "relayIfNotProcessed" attribute seems to be a more flexible 
option, as it can be used in conjunction with arbitrary roles. As has 
been said, of course, it's nonsensical with roles "none" and 
"ultimateReceiver". OTH, there will plenty of roles defined for 
specific applications that could take advantage of it. It may make it 
easier for a deployed application with roles already defined to be 
retrofitted to use the forwarding behavior, or enable applications to 
evoke this behavior only occasionally, depending on circumstances.

RC

> 
> 
> I think you may have flipped (pun intended :) my point of view. I 
have
> on several occasions argued that we should have only one 
concept of
> identifying a node. In the current terminology, this means that we
> *only* think of identity in terms of roles:
> 
> * A node is the actual processor of SOAP messages
> 
> * A role is a URI identifying a node
> 
> This model is very similar to the relationship between a resource 
and a
> URI in traditional Web terminology--and for a good reason! As a 
result
> of this model, a message path only contains a set of roles that 
are
> linked to specific nodes through late binding. In other words, this 
is
> the Web as we know and love with respect to URIs vs. resources.
> 
> I completely agree that targeting is about establishing a contract
> between the sender and a receiving role. Flipping the default has
> nothing to do with the node/role model above but everything to do 
with
> how we think of the contract. In addition, we use the mU flag to
> indicate whether the contract is mandatory or optional. I think we 
all
> agree that when combined, targeting and mU provide a very 
powerful
> processing model.
> 
> The reason why the default is that a contract is between the 
sender and
> the first receiver acting in the specified role is that the receiver 
can
> not know whether the sender intended the contract automatically 
to be
> extended to downstream nodes acting in that role. As Jean-
Jacques points
> out, there are scenarios where this is the case and there are 
scenarios
> where this is not the case.
> 
> Mark Jones originally asked the question of how a sender can 
request the
> contract to be extended to other SOAP nodes acting in the same 
role in
> the case that the first node didn't understand the optional header
> block.
> 
> This question is based on the assumption that the sender has 
some
> knowledge of the role being targeted. At least, it has to know that 
the
> role may be acted in by a number of SOAP nodes and not just 
uniquely
> identify a SOAP node. That is, an implicit assumption is that 
roles have
> properties and characteristics. This is in fact in line with the roles
> we define in the spec, for example:
> 
> * "ultimateReceiver" is the last role in a message path indicating 
that
> a node acting as the ultimateReceiver has to process the body.
> 
> * "next" always identified a node which means that contracts are 
always
> for you.
> 
> That is: a sender needs to know something about a role in order 
to
> target a header block at it and a receiver needs to know 
something about
> a role in order to be able to act in it.
> 
> Given this, I think we really only have two options: the "relay" role or
> an "RelayIfIgnored" attribute. I would evaluate them as follows:
> 
> 1) Based on where we are at the current time, I prefer the "relay" role
> as it does solve Mark's scenario. It has the smallest impact on the spec
> and can be defended in the same manner that "next" can--the two are in
> fact very similar.
> 
> 2) After that I prefer a separate attribute as this also solves Mark's
> problem. My concern is that it has a bigger impact on the spec.
> 
> Flipping the default, by itself, doesn't solve anything, and if we have
> either a "relay" role or a separate attribute then it is not necessary.
> I therefore see this as a dead end.
> 
> Henrik Frystyk Nielsen
> mailto:henrikn@microsoft.com
> 
> >Jean-Jacques, others,
> >
> >there are two different views of the world competing here. The 
> >views concern in particular how a sender node views the 
> >message path in terms of nodes and roles:
> >
> >1) (status quo) the message path contains some nodes and some 
> >roles, and the mapping from a role to a node is unambiguous. 
> >In other words, a role name identifies at most one node (from 
> >the POV of the sender) and the contract is between the sender 
> >and that node.
> >
> >2) (after proposed default flip) the message path contains 
> >some roles, the contract is between the sender and the role 
> >(anyone playing the role).
> >
> >I think Henrik assumes the first view but wants to make an 
> >exception for a specific scenario.
> >
> >I think the specific scenario is very close to the second view 
> >so I thought that view was being adopted here.

Received on Thursday, 17 October 2002 17:48:28 UTC