RE: Protocol binding and middleware

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
> > >>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >
> >
>