Issue i021 WSDL Extension for Addressing: status and discussion on requirements

As per the joint action item with Anish, the email discusses
description requirements for Addressing in WSDL.

-=- Summary of issue i021 -=-

Here's a summary of where we stand right now with i021.

Last discussion at the F2F in Redmond of the latest proposal[1]:

    http://www.w3.org/2002/ws/addr/4/dec-f2f-minutes.html#item12

The minutes detail three sub-issues that emerged from this discussion:

1. Props/features vs. extensions discussion: WSDL 1.1 extensions use
   its open content model, while WSDL 2.0 has 2 mechanisms (open
   content model and F&P): what model/syntax should we use in WSDL
   1.1? in WSDL 2.0?

2. Semantics/syntax of what does it mean to use these
   props/extensions: I am not sure what exactly this is
   supposed to capture, but I think it can probably be combined with
   the last issue below:

3. What are the actual requirements, i.e. which props should be
   defined: what properties do we want to describe and at which level?

The discussion mainly focused around 1. There was some agreement
around using the open content model for WSDL 1.1 as opposed to
backporting F&P, and mixed feelings around what to do for WSDL 2.0,
i.e. pick one way versus accomodate both. There was agreement however
that we ought to notify the WSDWG that the presence of both F&P and
open content model without more guidance in WSDL 2.0 was likely to
spawn a similar debate in other groups developing extensions.

It was noted that, if we go the open content model route, we will need
to define some scoping rules for defining properties, which F&P
provide out of the box.

Finally, there was some discussion about at which level to define
those properties that we want to describe — maybe this is what 2.
above was about:
- in the core, so that it applies to any protocol that Addressing
  would be bound to; it was noted that this was implicitely opening
  the door to an F&P description.
- in the SOAP binding, in order to define SOAP properties.
- in the WSDL binding, which just gives hints/directions about using
  message addressing properties to a service requester.

-=- Description requirements -=-

However, the discussion ended on noting that what we should really
start doing was working on 3., i.e. which properties should appear in
a WSDL description, and at what level, which is what this action item
is about.

We are interested in describing the message addressing properties.
Their list is the following, adding the refP's as I pointed out
before[1]:
- [destination]
- [source endpoint]
- [reply endpoint]
- [fault endpoint]
- [action]
- [message id]
- [relationship]
- [reference properties]
- [reference parameters]

Out of all of those, the following have to be set at run time and do
not make sense in a WSDL description:
- [source endpoint]
- [reply endpoint]
- [fault endpoint]
- [message id]

That leaves us with the other ones. Here is a proposal to which level to
attach these properties at:

- [destination]: endpoint; this is the endpoint address; we don't need
  to add any new property to the WSDL model, as they are identical.

- [action]: message reference in an interface operation / message in a
  portType; note that its value is identical to the SOAP action
  (@wsoap:action, {soap action} in WSDL 2.0) property on a binding
  operation component, but it is a property at the interface/operation
  level.

  ISSUE: SOAP action's granularity is a binding operation while the
  [action] property is set at the message level; there is a mapping
  problem when an operation has more than one message with different
  [action] values.

- [relationship]: message reference in an interface
  operation/portType; this is the relationship of a particular message
  to others.

- [reference properties]: endpoint; as different [reference
  properties] have the implication that "endpoints [..] accept
  different sets of messages or follow a different set of policies,
  and consequently may have different associated metadata (WSDL, XML
  Schema, and WS-Policy policies)", I think that this is a property of
  the service endpoint as a whole.

  However, this depends on the relationship between a service endpoint
  (as interpreted by WSDL) and endpoint as interpreted by Addressing,
  which is issue i020. For example, can I have different operations in
  an interface have send different RefPs?

- [reference parameters]: message reference in an interface operation
  / message in a portType; these are data "associated with the
  endpoint to facilitate a particular interaction"; if we consider an
  interaction to be a message exchange, it probably make sense to make
  this message specific.

The scoping rules would define things like: if [reference parameters]
are specified on an service element, this defines the [reference
parameters] for all the messages of all the endpoints of this
interface unless one is stated at a lower level (endpoint,
interface/portType, binding, etc.).

Another way to look at scoping would be to have additive effect. In
this mode, if RefPs are defined at the service level and also at the
interface, the RefPs in scope are the ones defined at the service
level + those defined at the interface level.

In addition to specifying those properties, one may want to indicate
in one's WSDL just the fact that Adressing is used.

On top of that, one may optionally want to say that a particular
operation in an interface follows the MEP rules defined in
http://www.w3.org/TR/2004/WD-ws-addr-wsdl-20041208/

Once we agree on this, then we can talk about syntax.

Cheers,

Hugo jointly with Anish, though I won't claim that Anish agrees with
every single word

  1. http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0067.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/