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

RE: Protocol binding and middleware

From: Anne Thomas Manes <anne@manes.net>
Date: Mon, 3 Mar 2003 09:28:16 -0500
To: "Jacek Kopecky" <jacek@systinet.com>, "Assaf Arkin" <arkin@intalio.com>
Cc: "Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>, "WS Description WG" <www-ws-desc@w3.org>
Message-ID: <ECEDLFLFGIEENIPIEJJPKEJHDKAA.anne@manes.net>

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 09:28:53 GMT

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