- From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
- Date: Tue, 04 Mar 2003 10:29:42 +0100
- 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 UTC