W3C home > Mailing lists > Public > www-ws-desc@w3.org > March 2003

Re: Protocol binding and middleware

From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
Date: Tue, 04 Mar 2003 10:29:42 +0100
Message-ID: <3E647206.3010308@crf.canon.fr>
To: Christopher B Ferris <chrisfer@us.ibm.com>
CC: WS Description WG <www-ws-desc@w3.org>

I agree with Chris, and I think I now understand why I seemed to 
disagree with Arkin and Jack. Application data is first described 
as a "part" in the portType, but then it may get serialized as a 
"header block" in the binding. So, as a result, the binding is 
not just about the middleware, but also about the application.

Jean-Jacques.

Christopher B Ferris wrote:
> 
> Hmmm... IMO, "headers" are in and of themselves a binding artifact
> (e.g. it isn't a "header" or "header block" until some choice has been 
> made to
> determine the serialization format of the message). At best, if there is 
> any application-specific
> information, then it should be described in the abstract as a "part" in 
> the portType
> regardless of whether the serialization will carry that part as a header 
> block in a SOAP-specific
> binding. It isn't clear to me that there is need of describing in the 
> abstract that the
> information (part) is a "header".
> 
> 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 03/03/2003 10:25:47 AM:
> 
>  >
>  > I agree. In which case you ought to have a way to specify header 
> blocks as
>  > part of the portType. My request is just that you consider using 
> reuseable
>  > versus application-specific as a criteria in your thought process.
>  >
>  > Your point reiterates Jack's point -- portTypes represent the information
>  > that applications are concerned with. So any information pertinent to an
>  > application should be defined in the portType. Bindings represent
>  > information that middleware is concerned with -- but there are two 
> levels of
>  > protocol information -- that which is reusable and that which is
>  > application-specific.
>  >
>  > Best regards,
>  > Anne
>  >
>  > > -----Original Message-----
>  > > From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
>  > > Behalf Of Jean-Jacques Moreau
>  > > Sent: Monday, March 03, 2003 9:35 AM
>  > > To: Anne Thomas Manes
>  > > Cc: Jacek Kopecky; Assaf Arkin; Jean-Jacques Moreau; WS Description WG
>  > > Subject: Re: Protocol binding and middleware
>  > >
>  > >
>  > >
>  > > Anne,
>  > >
>  > > I think header blocks cross the boundary. Some are
>  > > implementation-specific, others are application-level. For
>  > > example, an imaging application might encode the image to be
>  > > processed in a dedicated header block, other headers may encode
>  > > the image's metadata, and further header blocks may specify the
>  > > various processings to be done. SOAP is fairly flexible in that
>  > > respect and does not require application data to appear only as
>  > > body blocks.
>  > >
>  > > Jean-Jacques.
>  > >
>  > > Anne Thomas Manes wrote:
>  > > > Perhaps another way to think about bindings is in terms of
>  > > what's shareable
>  > > > and what's not. We've been debating this issue in the UDDI team 
> that's
>  > > > defining a new WSDL to UDDI mapping. According to our proposed
>  > > mapping, we
>  > > > now map each portType and binding to a different tModel. The
>  > > idea is that
>  > > > each of these artifacts is a reusable entity. But as Jacek
>  > > says, a binding
>  > > > actually represents a specific implementation -- it contains reusable
>  > > > information (XML and transport protocols, message style, etc.),
>  > > but it also
>  > > > contains implementation-specific information (headers, 
> SOAPAction, etc.)
>  > > >
>  > > > I'd encourage you to split the binding into reusable and
>  > > > application-specific definitions.
>  > > >
>  > > > Anne
>  > > >
>  > > >
>  > > >>-----Original Message-----
>  > > >>From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org]On
>  > > >>Behalf Of Jacek Kopecky
>  > > >>Sent: Monday, March 03, 2003 8:50 AM
>  > > >>To: Assaf Arkin
>  > > >>Cc: Jean-Jacques Moreau; WS Description WG
>  > > >>Subject: RE: Protocol binding and middleware
>  > > >>
>  > > >>
>  > > >>
>  > > >>I think I agree with Arkin that bindings should be directed towards
>  > > >>middleware.
>  > > >>
>  > > >>I've always thought of portType as the abstract interface, the one
>  > > >>defining the application; and of binding as the details of a 
> deployment,
>  > > >>a specific instance of the application. Ideally, the application 
> should
>  > > >>only care about the portType part of WSDL; this approach is taken for
>  > > >>example by the WebServices Invocation Framework (WSIF) [don't have a
>  > > >>link, sorry].
>  > > >>
>  > > >>This is also why I'm opposed to Gudge's idea of merging portType and
>  > > >>binding into one, layerable/inheritable construct.
>  > > >>
>  > > >>Best regards,
>  > > >>
>  > > >>               Jacek Kopecky
>  > > >>               Systinet Corporation
>  > > >>               http://www.systinet.com/
>  > > >>
>  > > >>
>  > > >>On Wed, 2003-02-26 at 21:27, Assaf Arkin wrote:
>  > > >>
>  > > >>>>-----Original Message-----
>  > > >>>>From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org]On
>  > > >>>>Behalf Of Jean-Jacques Moreau
>  > > >>>>Sent: Wednesday, February 26, 2003 1:05 AM
>  > > >>>>To: Assaf Arkin
>  > > >>>>Cc: www-ws-desc@w3.org
>  > > >>>>Subject: Protocol binding and middleware
>  > > >>>>
>  > > >>>>
>  > > >>>>
>  > > >>>>Arkin,
>  > > >>>>
>  > > >>>>I disagree that the entire "protocol binding" is directed towards
>  > > >>>>the "middleware". Part of the "protocol binding" deals with lower
>  > > >>>>level stuff, such as implementing request-response over a one-way
>  > > >>>>underlying protocol, or setting specific protocol header fields.
>  > > >>>>However, another (and maybe larger) part of the "protocol
>  > > >>>>binding" specificies how message parts (i.e. application data)
>  > > >>>>are serialized as, for example, SOAP header and body blocks.
>  > > >>>
>  > > >>>True. But is this interesting to the application or the middleware?
>  > > >>>
>  > > >>>Let's say I have an abstract message definition and my application
>  > > >>>consumes/produces XML documents based on that definition. The WS 
> stack
>  > > >>>(which I refer to as middleware) then does the encoding,
>  > > enveloping etc.
>  > > >>>Given the protocol binding it decides where to put the headers.
>  > > >>
>  > > >>The header
>  > > >>
>  > > >>>could have one name in protocol X and another in protocol Y,
>  > > it can be a
>  > > >>>header in SOAP and a payload in ebXML, or maybe it's always in
>  > > >>
>  > > >>the message
>  > > >>
>  > > >>>which is true for any number of encodings that uses TCP underneath.
>  > > >>>
>  > > >>>As long as the application does not care which protocol ends up
>  > > >>
>  > > >>being used
>  > > >>
>  > > >>>and how the abstract message becomes an over-the-wire message 
> for that
>  > > >>>particular protocol, I would say it's a middleware issue.
>  > > >>>
>  > > >>>
>  > > >>>
>  > > >>>>This is one of the reasons why some people (including I) have
>  > > >>>>proposed to separate bindings into two sections, for example
>  > > >>>><messageBinding> and <protocolBinding> (some people have
>  > > >>>>mentionned that the two sections are not entirely orthogonal).
>  > > >>>
>  > > >>>Let's say my application wants to send a message containing a
>  > > >>
>  > > >>purchase order
>  > > >>
>  > > >>>to some service. Service X has one <messageBinding> which has
>  > > >>
>  > > >>some type of
>  > > >>
>  > > >>>enveloping/encoding and service Y has another <messageBinding>
>  > > >>
>  > > >>that has some
>  > > >>
>  > > >>>other type of enveloping/encoding. Before the message is sent
>  > > >>
>  > > >>it has to be
>  > > >>
>  > > >>>enveloped/encoded based on what the service expects.
>  > > >>>
>  > > >>>If the application has to do that then it's an application
>  > > issue. If the
>  > > >>>middelware can do that than it's a middleware issue. Which part 
> of the
>  > > >>>system, the application or the middleware takes care of that?
>  > > >>>
>  > > >>>
>  > > >>>>It would be worth talking to Glen about your specific security
>  > > >>>>example. I think he has been thinking along similar lines.
>  > > >>>
>  > > >>>Thanks ;-)
>  > > >>>
>  > > >>>arkin
>  > > >>>
>  > > >>>
>  > > >>>>Jean-Jacques.
>  > > >>>>
>  > > >>>>Assaf Arkin wrote:
>  > > >>>>
>  > > >>>>>>Jean-Jacques Moreau wrote:
>  > > >>>>>>
>  > > >>>>>>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?
>  > > >>>>>
>  > > >>>>>
>  > > >>>>>More like 'protocol binding is something that is directed
>  > > >>
>  > > >>towards the
>  > > >>
>  > > >>>>>middleware'. The middleware is agnostic to what the application
>  > > >>>>
>  > > >>>>is doing,
>  > > >>>>
>  > > >>>>>the application is agnostic to what the middleware is doing.
>  > > >>>>>
>  > > >>>>>
>  > > >>>>>
>  > > >>>>>
>  > > >>>>>>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?
>  > > >>>>>
>  > > >>>>>
>  > > >>>>>Yes.
>  > > >>>>>
>  > > >>>>>But I think we need to types of features here.
>  > > >>>>>
>  > > >>>>>At the abstract level I would want to have a feature that 
> requires a
>  > > >>>>>security credential to be known and passed to the application
>  > > >>>>>(authentication). Then I could have multiple different
>  > > >>
>  > > >>operations that
>  > > >>
>  > > >>>>>require this feature, so it's a more generic and reusable
>  > > >>
>  > > >>definition.
>  > > >>
>  > > >>>>>At the protocol level I would want a more precise feature.
>  > > >>
>  > > >>I may include
>  > > >>
>  > > >>>>>access control (authentication + authorization), and I may
>  > > >>
>  > > >>elect to use
>  > > >>
>  > > >>>>>security tokens for single sign-on for some port and not
>  > > >>
>  > > >>for another.
>  > > >>
>  > > >>>>>There may be a mismatch between the abstract feature and
>  > > >>
>  > > >>the protocol
>  > > >>
>  > > >>>>>feature. For example, in the actual header there may be a
>  > > >>
>  > > >>security token
>  > > >>
>  > > >>>>>that represents a prior authentication, but at the abstract
>  > > >>>>
>  > > >>>>level it needs
>  > > >>>>
>  > > >>>>>to be an actual credential.
>  > > >>>>>
>  > > >>>>>So the protocol features need to be aware of the abstract 
> feature it
>  > > >>>>>supports and figure out how to map the data in the actual
>  > > >>>>
>  > > >>>>header to the data
>  > > >>>>
>  > > >>>>>required at the abstract level. If I created a security
>  > > >>
>  > > >>token then all I
>  > > >>
>  > > >>>>>have to pass around in messages is that security token, but
>  > > >>
>  > > >>I know the
>  > > >>
>  > > >>>>>principle and can pass that on to the application.
>  > > >>>>>
>  > > >>>>>I am not sure what is the best way to do that. The idea of
>  > > >>>>
>  > > >>>>defining an input
>  > > >>>>
>  > > >>>>>as a set of values, some of which are described by the
>  > > >>>>
>  > > >>>>operation-specific
>  > > >>>>
>  > > >>>>>message and some of which are described by the generic/reusable
>  > > >>>>
>  > > >>>>feature is
>  > > >>>>
>  > > >>>>>appealing to me.
>  > > >>>>>
>  > > >>>>>arkin
>  > > >>>>>
>  > > >>>>>
>  > > >>>>>
>  > > >>>>>
>  > > >>>>>>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, 4 March 2003 04:30:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:23 GMT