RE: Protocol binding and middleware

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 Monday, 3 March 2003 10:26:07 UTC