RE: Context proposal

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 Friday, 14 February 2003 01:45:54 UTC