RE: Context proposal

Jean-Jacques,

It was my understanding that a header targeted at the ultimate SOAP receiver
would be processed by the WS layer (e.g. security token or transaction
context), but does not necessarily have to be passed on to the application.
At least as far as I understand it, the WS layer can change the header
possibly removing information that would be interesting to the application.
And the WS layer is under no obligation to include that information to begin
with.

For example, the security header will contain a large set of information
that is of no interest to the application and can further depend on the
communication protocol (encryption protocol, token mechanism, etc). It will
also contain a minimal set of information that is of interest to the
application (in this particular example the identity of the sender).

Asking the application to receive a complex security header and strip out
the essential bits of data seems like an overkill. That's something the WS
layer can do in a more efficient manner. Furthermore, the application would
need to look at something like WS-Security + WS-Attachment to determine if
the information is even contained in all messages, but cannot enforce the WS
to include that information. As I understand it the WS layer can decide
which features to require but without knowing what the application requires
could make the wrong decision.

I have not looked at the WS security specs in detail, but I suspect that the
information may not even be present in the header to begin with. If the
sender is required to send its identity in every message than clearly the
application can extract that information from the header using an XPath
expression. But if the sender can establish a security token and only send
that token in every message than the application will have no way of
obtaining the sender identity from the abstract and temporary security token
contained in the header.

On the other hand, we can define an abstract input to the application which
contains the identity of the sender and constrain the cardinality to {1,1}
or {0,1}. We can then define how that information is extracted from any
combination of headers and let the WS layer deal with the technical details
of presenting that value to the application. If the cardinality is {1,1}
then the WS layer will be forced to include that information, e.g. by
forcing all such services to use a given feature.

If in BPEL/BPML I define that the application requires an 'identity'
property, that forces all WS definitions to somehow pass that information to
the application. The WS layer can use any combination of extensions to
SOAP/WSDL and even different combinations. It could extract that information
from the header, or it can extract that information from the security token
by referencing an identity passed in a previous message, etc.

I understand this increases complexity, but it establishes a separation
between the information that is of interest to the application, the headers
that are of interest to the WS to support a particular kind of interaction,
and the manner in which the WS layer handles such information.

arkin


> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Jean-Jacques Moreau
> Sent: Friday, February 14, 2003 12:09 AM
> To: Assaf Arkin
> Cc: www-ws-desc@w3.org
> Subject: Re: Context proposal
>
>
>
> Arkin,
>
> I'm not sure we need the extra complexity. SOAP header blocks are
> not just meant for intermediaries; they can also be targeted to
> ultimate SOAP receivers. It is up to the application to process
> the header block as it sees fit, whether the application is an
> intermediary or the ultimate receiver. So, as long as contexts
> can be represented as SOAP header blocks, I think we're just fine.
>
> Jean-Jacques.
>
> Assaf Arkin wrote:
> > Are there any cases where one would want to apply a context to
> a body part
> > rather than a header?
> >
> > Typically security contexts, transactions contexts and sessions
> are handled
> > by the middleware and are of no interest to the application. Information
> > that is processed by the infrastructure definitely belongs in
> the header.
> > But I can think of cases where the application would like to carry that
> > information from one process to another in a manner than transcends
> > contexts.
> >
> > For example, the BankService may be interested in storing the
> identification
> > of the user that performed the transaction (e.g. shared bank
> account) or the
> > identification of the ATM at which it was performed (location
> of withdrawl),
> > to present it from a different context (e.g. the monthly statement).
> >
> > The information can be duplicated in the body and header, but that means
> > that the infrastructure and application can disagree. If the
> infrastructure
> > successfuly identifies the user and presents a 'principal' in
> the context in
> > which the operation is performed, being able to store that
> principle would
> > be useful.
> >
> > BPEL4WS and WSCI have a mechanism that allows information to be
> extracted
> > from the message and presented to the application or the infrastructure
> > (properties). Would it make sense to introduce a similar
> mechanism, allow
> > properties to obtained from both header and body, and then
> define contexts
> > that make use of these properties? It might even be possible to
> use these
> > properties to convey RPC message parts as part of eliminating
> the message
> > definition.
> >
> > arkin
> >
> >
> >
> >>-----Original Message-----
> >>From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> >>Behalf Of Jonathan Marsh
> >>Sent: Thursday, February 13, 2003 1:04 PM
> >>To: www-ws-desc@w3.org
> >>Subject: Fault naming & context proposals
> >>
> >>
> >>
> >>For those of you who didn't hear it on today's call, please review and
> >>comment upon Paco's fault naming proposal and Sanjiva's context
> >>proposal.  We plan to discuss these proposals further on our next
> >>telcon.
> >>
> >>--------------------------------------------------------------------
> >>6.  Fault naming.  Paco suggests eliminating fault names [.1].  Some
> >>    support at [.2].
> >>
> >>[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0045.html
> >>[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0047.html
> >>
> >>--------------------------------------------------------------------
> >>7.  Context proposal from Sanjiva [.1].
> >>
> >>[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0063.html
> >>
> >>
> >
> >

Received on Saturday, 15 February 2003 19:15:42 UTC