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 08:50:16 UTC