Motivation for R131

A long time ago, I took an action a while ago to provide motivation for
R131.

From the latest editor's copy of the requirements document, R131 says "The
WG SHOULD define components that may be used within Messages to refer to
other WSDL components. (From DO. See also R085 and R120. Last discussed 6
Feb 2003.)"

From the charter [2], some relevent quotes.

Section 1. "One of the requirements for the development of Web services is
the ability to describe the interface, the boundary across which
applications (Web services user agents and Web services) communicate.
Applications can then interoperate using this interface."

Section 1.4 "The description language defined should therefore describe how
to reach the Web Service in a form which is orthogonal to its message
exchange patterns and its messages."

You will notice that there is no text in the charter which mentions anything
about "design-time" versus "run-time" use of WSDL.  

Perhaps one could stretch and say that the Out of Scope section 2.3,
Discovery, precludes any "run-time" WSDL construct exchanges.  However, that
seems a large stretch given that most people do not think of exchanging
references as "discovery", more that discovery is the exchange of an entire
description of a web service.  This is typically expected to be UDDI or some
other kind of registry.

Therefore, I conclude that R131 is within the scope of the charter and not
precluded.  Of course, the group could choose for other reasons not to meet
R131, but a charter reason cannae be used.

Now let us progress to the motivation.

One of the most important pieces of information about a web service is the
URI of the service.  There are a number of ways that this information can be
provided to a service consumer:
- within a WSDL file binding
- from a registry
- from a service
 - as part of the protocol
 - as part of a message

A common scenario is that one service will send a request to another
service, but will want the response delivered to an address that is
specified in the message.  This is expressed as scenario #70 in the Web
Services architecture usage scenarios [3].  From the scenario, "The sender
may also tag the message with an identifier for another service (other than
the originating sender) which will be the recipient of the response."  Now
the example does not show such an identifier, though this is listed in the
requirements section 1a.

The interpretation of the requirement is that it should be possible for a
sender or receiver to specify the URI of the service.  Now perhaps the
requirement is slightly unclear in the use of the term "other WSDL
components".  This could be interpreted as saying refering to a WSDL
Service, WSDL Interface, etc.  The intent was to be able to have a type in
order to pass around address, and potentially other reference information,
in messages.  

There is an interesting relationship between R131 and R085, "The description
language SHOULD allow describing Messages that include references (URIs) to
typed referents, both values and WSDLServices."  The interpretation of R085
that the WSDL group is currently using is that a WSDL file must be able to
specify which portions of a message are references.  

There are two ways of specifying which portions of messages are references,
either by including the reference type in the message itself or in a
separate description, particularly wsdl 1.2.  WS-Addressing could be viewed
as a mechanism for marking message by typing the reference and Arthur's
proposal does so in a separate description.  

I propose that WSDL 1.2 containing a type that can be exchanged dynamically,
such as ws-addressing endpoint references, is within the scope of wsdl 1.2,
as much as a type that statically defines reference types.

Further, there is likely to be synergy between these two types.  There are a
number of aspects of the reference that may be static in some cases and
dynamic in others.  URIs are the type that are most commonly thought of as
sometimes being dynamic, other times static.  But bindings are also
flexible. 

This motivation does not include the exchange of these dynamic references,
such as a ws-addressing replyTo.  It merely argues that a type that contains
reference information such as URIs, binding, service invocation properties,
and more is within the scope of wsdl 1.2.  I would expect that any headers
or message bodies that would contain such types would be defines elesewhere
and in a layered fashion.

I also would like to point out that I have seen the "describe in wsdl"
versus "exchange in messages using a type" discussion in other contexts,
such as identifying correlation ids.  It is clear that there is a need for
both constructs, that is the identifier can be typed inline or out-of-band.
And web services need to be able to make the choice between types described
in wsdl and types contained in messages.

This email will hopefully suffice to motivate that a type that contains
reference information that is exchanged within messages - aka endpoint
reference - is within scope of wsdl 1.2.  The questions about whether the WG
chooses to do this work, and what works would serve as the basis of such
work, are separate.  It may very well be that the wg decides an endpoint
reference type is within scope but there are no works that are submitted or
acceptable to the group.  The acceptance of this requirement leaves the
possibility of standardization in wsdl 1.2 open, when standardization of
such a construct is currently precluded.

Cheers,
Dave

[1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/requirements/ws-desc-reqs.h
tml
[2] http://www.w3.org/2002/01/ws-desc-charter
[3] http://www.w3.org/TR/2002/WD-ws-arch-scenarios-20020730/#S070