Re: Context proposal

Arkin,

You've lost me when you say: "I would [...] use XMLP as the 
interface between the WS gateway and the implementation, and SOAP 
as the interface between two WS gateways." Are you referring to 
the (now defunct) XMLP Abstract Model and it's "API"?

Also, what is a "WS gateway"? Is it what used to be called a 
"SOAP processor", and is now only a "SOAP node"?

Jean-Jacques.

Assaf Arkin wrote:
> Jean-Jacques,
> 
> SOAP and XMLP do not present a problem. If I assume SOAP encoding and
> XMLP-like processing then the application can access body part or header
> part in the same way, and given that the content an can be as rich in either
> case (XML), I do not care whether the data is contained in the body or the
> header.
> 
> My issue is only with the WSDL representation and the manner in which a
> generic WS gateway that is configured with that WSDL can fulfill the
> requirements of the WS implementation. Whether it passes the entire SOAP
> document or an XMLP collection of blocks makes no difference, though I would
> tend to use XMLP as the interface between the WS gateway and the
> implementation, and SOAP as the interface between two WS gateways.
> 
> The only requirement is that a generic WS gateway written by X can pass all
> the correct information to some WS implementation written by Y, aided only
> by available specifications (including any such extensions to WSDL).
> 
> arkin
> 
> 
>>Arkin,
>>
>>As far as SOAP is concerned, 2. and 3. below are implementation
>>issues. Whether certain SOAP headers blocks are handled by the
>>application or by some middleware is irrevelant as far as SOAP is
>>concerned. SOAP is a wire protocol and does not deal with what
>>happens at either end, as long as header blocks (and the body)
>>are processed according to the rules set forth in the processing
>>model. Even a real SOAP implementation may not have quite the
>>type of machinery you seem to be having in mind.
>>
>>I need to think more about 1. below.
>>
>>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 10:10:38 UTC