Re: Context proposal

Arkin,

Continuing to respond to this particular message, you seem to be 
implying that "protocol binding"s are akin to "middleware" (this 
may be a gross exageration of your more subtle statements). Am I 
reading to much in your message?

Regarding point 1, some of us have been contemplating introducing 
features at the abstract level. For example, you might declare 
that a given portType relies on an abstract security feature with 
certain guarantees. Bindings would map that abstract feature to a 
concrete security feature, for example via SOAP header blocks or 
a secure underlying protocol.

I don't think there is a specific "feature proposal" currently on 
the table, but I expect that the PFTF will at least be giving 
some attention to this and related topics.

Does this help?

Jean-Jacques.

Assaf Arkin wrote:
> Jean-Jacques,
> 
> This is all good but still does not answer three of my concerns.
> 
> 1. The data of interest to the application is defined in the abstract
> operation. As I understand it, headers that are specific to the protocol
> binding can be added in the protocol binding by referencing other messages.
> Since these headers are not known at design time the application cannot
> assume their existence!
> 
> One solution is to add the data and feature to the abstract operation
> definition. That will force the data to exist in any operation and all
> protocol bindings to use that feature. Is that part of the feature proposal?
> 
> 2. The data of interest to the application is typically a subset of the data
> of interest to the middleware. In the example I gave, the application is
> only interested in the identity of the sender, while the middleware is
> interested in a variety of security information. Furthermore, the identity
> is resolved from the security token which is generated by the middleware.
> 
> In this particular case the application needs good understanding of the
> header in order to extract the relevant information (security token) and
> also needs to talk to the middleware to resolve an identity from the
> security token (breaking the layering).
> 
> An alternative proposal is to let the middleware do the resolving and then
> pass on the value to the application. That would decouple the application
> from the middleware through a generic mechanism, as opposed to having APIs
> specific for resolving security context, transaction contexts, etc. It will
> also allow more efficiency in the middleware.
> 
> 3. The middleware must not remove any headers before they reach the
> application, and while possible to build such an implementation, unless the
> middleware must act in that manner it is impossible to build an application
> that depends on that behavior.
> 
> Was that point already discussed, and if so what solution was reached?
> 
> arkin
> 
> 
>>-----Original Message-----
>>From: Jean-Jacques Moreau [mailto:jean-jacques.moreau@crf.canon.fr]
>>Sent: Monday, February 17, 2003 12:35 AM
>>To: Assaf Arkin
>>Cc: www-ws-desc@w3.org
>>Subject: Re: Context proposal
>>
>>
>>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
>>>>>>
>>>>>>
>>>>>
>>>>>
>

Received on Tuesday, 25 February 2003 09:44:03 UTC