- From: Assaf Arkin <arkin@intalio.com>
- Date: Wed, 5 Mar 2003 12:53:48 -0800
- To: "Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>, "Christopher B Ferris" <chrisfer@us.ibm.com>
- Cc: "WS Description WG" <www-ws-desc@w3.org>
I also agree with Chris ;-)
But it dosen't solve the problem in terms of having generic application data
and generic headers that do not carry that data but can provide it.
For example, the application data may be <userName> but the protocol may
standardize some way to communicate it (e.g. <securityToken>) which does not
contain the <userName> value. On the other hand, since the token was
generated from a user name, the user name is known and can be passed to the
application.
So instead of saying <userName> goes in header <userName>, I want to say:
header <securityToken> guarantees that <userName> data could be handed over
to the application. And more interestingly, feature securityToken guarantees
that <userName> would be part of input/output. So by electing to use that
feature I do not need to pass that information as is in the header, but I
know that information is communicated somehow in the SOAP message (or
whichever other protocol we use).
I think the proposal for having feature/property defined for the interface
would solve that. It would allow me to require a feature at the interface
level which describes the relevant application data sent/received (in this
case <userName)). It would also allow me to reference all the headers used
for exchanging them and defined once (e.g. <securityToken>), and understand
that by using a certain security feature the SOAP message contains a set of
headers which are easily mapped to the application input/output.
arkin
> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Jean-Jacques Moreau
> Sent: Tuesday, March 04, 2003 1:30 AM
> To: Christopher B Ferris
> Cc: WS Description WG
> Subject: Re: Protocol binding and middleware
>
>
>
> 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 Wednesday, 5 March 2003 15:55:31 UTC