Re: Context proposal

+1; any discussion of "layers" should be discouraged. There is no mention 
of
processing layers in the SOAP1.2 specification for a reason.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-desc-request@w3.org wrote on 02/17/2003 03:34:49 AM:

> 
> Arkin,
> 
> I'm not disagreeing with anything you say, but as far as SOAP is 
> concerned, this is an implementation choice. Some header blocks 
> will likely be processed at the middleware level, for example a 
> header block used to implement a request-response interaction 
> over a one-way protocol; other header blocks will be processed by 
> the application itself, for example a validity token inserted by 
> a payment intermediary to validate a book purchase; but, at the 
> end of the day, where the header block is processed depends on 
> the feature(s) being used, the provider's network (i.e. how 
> intermediaries are deployed) and the particular vendor's protocol 
> stack.
> 
> See also my response [1] to a similar thread on ws-arch.
> 
> Jean-Jacques.
> 
> [1] http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0119.html
> 
> Assaf Arkin wrote:
> > 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
> >>>>
> >>>>
> >>>
> >>>
> > 
>