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 Friday, 14 February 2003 03:09:59 UTC