- From: Hugo Haas <hugo@w3.org>
- Date: Wed, 24 Nov 2004 15:27:07 +0100
- To: public-ws-addressing@w3.org
- Message-ID: <20041124142706.GE8914@w3.org>
This email fulfills my action item:
Hugo to send a refined proposal for issue 021. Due 2004-11-26.
It raises a couple of additional issues. See "ISSUE" below.
I'm afraid that this is a little long, but it should provide ample
details for the WG to take a decision, which is I think what people
were after last time i021 was discussed.
* Jonathan Marsh <jmarsh@microsoft.com> [2004-11-15 11:38-0800]
> WSDL 2.0 provides two appropriate mechanisms, WSDL 1.1 provides one. I
> think it's up to us to design the mechanism (or mechanisms in the worst
> case) that is appropriate for us, not to ask the WSDL WG to do it for
> us.
>
> I don't believe we can make any useful progress (e.g. defining URIs for
> message information properties) until we've made this big decision. It
> is equally true that we can "cover out bases" with a preliminary
> proposal based on element extension.
>
> Designing a single extension that works across WSDL 1.1 and WSDL 2.0 is
> very attractive to me, and element extension therefore seems like a
> natural fit.
I took an action item on October 15 to give a detailed proposal for
the following part of the proposal:
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-
> > request@w3.org] On Behalf Of Hugo Haas
> > Sent: Saturday, November 06, 2004 1:54 AM
> > To: public-ws-addressing@w3.org
> > Subject: Re: Issue 021: WSDL Extension for Addressing
> >
> > * Hugo Haas <hugo@w3.org> [2004-11-05 22:57+0100]
> > > * Hugo Haas <hugo@w3.org> [2004-11-03 19:36+0100]
> > > > This is to start discussion about issue 021:
> > > >
> > > > Does there need to be an extension for WSDL to explicitly call
> out
> > > > the use of Addressing?
> > > >
> > > > http://www.w3.org/2002/ws/addr/wd-issues/#i021
> > > [..]
> > >
> > > Here is a concrete proposal for resolving this issue. Motivation
> pour
> > > such a solution was detailed in my previous email and on this week's
> > > call.
> > >
> > > As it was unclear after last call what the WG wants to do about
> > > incorporating addressing into the WSDL 2.0 SOAP binding or not - or
> at
> > > least suggest it to the WS Description WG -, I will be proposing two
> > > options at the end.
> > >
> > > Preliminary proposals:
> > >
> > > a. Identify the core specification with a URI.
> > >
> > > That will allow to refer to our addressing mechanism in different
> > > bindings and at the interface level in WSDL, as a feature.
> > [..]
> >
> > To be complete about a WSDL description of addressing, I forgot to
> > mention that the message information properties should be given a URI
> > and flagged as properties of this feature. Some of those will be set
> > at run time while others (e.g. reference properties, if I understand
> > them correctly) will be described in the WSDL.
> >
> > Please note that this is not a WSDL 2.0 F&P versus content model
> > discussion that I want to start here, which is a topic that belongs to
> > the Web Services Description Working Group. Giving URIs to those
> > properties just identifies them so that they can be easily described
> > and talked about. I believe that this solution covers our bases for
> > whatever the Web Services Description Working Group ends up with in
> > this space.
In particular, I accepted to document the two approaches for
describing addressing in WSDL 1.1 and WSDL 2.0: open content-model and
features & properties.
The other part of the proposal identifying our SOAP module with a URI
was agreed on on the 2004-11-15 call.
I believe that the rest of the work has to do with the core
specification. The steps/layers that I believe are necessary are:
1. Identification of the our extension
2. Identification of the properties that a message can carry
3. Description of those properties in WSDL
-=- 1. Identification of the our extension -=-
I am proposing to identify the Web Services Addressing Core
specification as a feature, which essentially means giving it a URI,
say:
http://www.w3.org/YYYY/MM/ws-addressing
All this means is that the spec and its semantics are unambiguously
identified by a URI. That should not be controversial, and is used as
the basis for step (2) and (3) below, whatever direction is chosen:
QNames or URIs, description with open-content model or F&P.
-=- 2. Identification of the properties that a message can carry -=-
This also affects the core spec.
A message may carry some addressing properties. We need to identify
them unambiguously to talk about them, e.g. in WSDL.
Those are the MIHs plus reference properties and reference parameters,
to which I am associating each an XML Nmtoken:
- [destination] -> destination
- [source endpoint] -> sourceEndpoint
- [reply endpoint] -> replyEndpoint
- [fault endpoint] -> faultEndpoint
- [action] -> action
- [message id] -> messageId
- [relationship] -> relationship
- reference properties -> referenceProperties
- reference parameters -> referenceParameters
ISSUE: it's interesting that ref p's are _not_ MIHs as they do need
to be specified in a reply which makes them some addressing headers;
you also may want to specify reference properties in your WSDL, I
suppose. I have listed them up there for the sake of discussing
i021, but I believe that it is an orthogonal issue.
Some of those values may be specified at run time, e.g. [message
id]'s, or at design time, e.g [action]'s.
Those properties can then be identified either with QNames or URIs,
which has some consequences in (3) below.
With QNames, using the wsa prefix for the URI defined in (1) above,
[destination] can be identified with wsa:action, etc.
With URIs, still using this same URI as a base, [action] can be
identified with http://www.w3.org/YYYY/MM/ws-addressing/action.
Note: I would prefer to propose
http://www.w3.org/YYYY/MM/ws-addressing#action for the names, but
the SOAP F&P framework[1] only allows URIs AFAIK for property names.
However, WSDL Properties[2] are named with wsdls:anyURI's, which do
allow URI references after resolution of a LC issue. Maybe that's an
option then.
Using a URI, we make these properties Properties with an uppercase P,
from Features and Properties. Features and Properties, as defined in
[3], [1], [4] and [2], is essentially a way to formally exposing Web
services extensions to the world which has some nice properties (see
Glen's presentation of F&P background[5]). The description in WSDL of
the extension — and the open-content model versus F&P debate — is not
directly linked to identifying properties of the description.
As shown by this proposal, the mapping between QNames and URIs is
trivial and could actually be called out specifically in case the WG
decides to go the QName way to allow things like RDF assertions to be
made.
-=- 3. Description of those properties in WSDL -=-
This affects the WSDL part.
Describing the properties listed in (2) in a WSDL document means
assigning a value to them. To a certain extent, the way it's done is
independent from the way those have been named: for example, the
open-content model syntax can be used to assign the value of a
Property, which is what I was meant when I talked about covering our
bases by using URIs in step (2) in an earlier email. However, choosing
QNames at step (2) would basically rule out describing addressing with
F&P components.
Let's talk first about WSDL 2.0, which offers us the choice in how to
describe our extension's properties. I'll be using the [action]
property as an example.
- F&P-based description:
+ declaring the support of Web Services Addressing: using a WSDL 2.0
feature component and the feature URI:
<feature uri="http://www.w3.org/YYYY/MM/ws-addressing"/>
+ requiring the use of Web Services Addressing: still with the
WSDL 2.0 feature component:
<feature uri="http://www.w3.org/YYYY/MM/ws-addressing"
required="true"/>
+ setting a property's value: using a WSDL 2.0 property component
and the property's URI defined in (2); properties can be set at
all levels (service, endpoint, binding, operation, etc.):
<property uri="http://www.w3.org/YYYY/MM/ws-addressing/action">
http://example.com/GetQuote
</property>
ISSUE: [editorial] as I'm writing this and I'm thinking about the
specification of a SOAP Action in the SOAP binding in WSDL; I think
that some text will need to be added in the Addressing WSDL spec
about the relationship between our action and the SOAP action and
their declaration.
- open-content model description:
+ declaring the support of Web Services Addressing: we need to
declare an element to identify the use of our spec:
<wsa:Addressing/>
+ requiring the use of Web Services Addressing: similar to
above:
<wsa:Addressing wsdl20:required="true"/>
+ setting a property's value: this can be done with attributes and
elements put wherever desired, using the QNames defined in (2):
wsa:action="http://example.com/GetQuote"
Note that if we identify properties with QNames in (2), the
mapping with the description in WSDL is straightforward with this
solution. If the F&P framework is used in (2), then we can still
use the open-content model here and say that wsa:action sets the
value of the http://www.w3.org/YYYY/MM/ws-addressing/action
Property.
WSDL 1.1 does not have support for F&P-based description, so only the
latter works for it.
-=- Summary -=-
In a nutshell, the proposal is:
1. a URI for addressing core
2. URIs or QNames to identify properties of addressing core
3. open-content model or f&p to describe the properties value in WSDL
I have mixed feelings about the WSDL description based on the current
F&P debate in the WS Description WG, and the WSDL 1.1 and 2.0
difference F&P-based description would create.
However, I do favor using the F&P model in our core spec, i.e. URI
identification of properties, for the reasons I listed above.
Cheers,
Hugo
1. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapfeatspec
2. http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Property
3. http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#extensibility
4. http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Feature
5. http://www.w3.org/2004/10/presentations/glen.ppt
--
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
Received on Wednesday, 24 November 2004 14:27:08 UTC