Issue i001: what and how many things are we identifying?

In the midst of discussing the nature of EPRs as identifiers, we
started discussing what a Web identifier was identifying, and I
pointed out that the interesting question for us was how many things
we were identifying, since whatever we identify, a Web identifier can
identify. I got the following action item[1]:

    ACTION: Hugo to start discussion on what and how many things we
    are identifying

To make things clear up front, I am talking in the email about
identifier in the Web architecture sense and not in the formal sense
as we discussed on the 2004-12-03 teleconference.

I have tried to draw a parallel with WSDL concepts to try and clarify
this issue.

Here is what the specification currently says about EPRs and their
properties in terms of identification:

- an EPR is used for "identification [..] of specific service
  instances".

- the [address] property "identifies the endpoint".

- the [reference properties] property identifies "the entity or
  resource being conveyed"; it also says that "endpoints represented
  by endpoint references with different [reference properties] [..]
  may have different associated metadata (WSDL, XML Schema, and
  policies)".

- [reference parameters] are parameters "associated with the endpoint
  to facilitate a particular interaction".
  
  RParId. The definition above is a very fuzzy one; based on people's
  feedback at the F2F, [reference parameters] can be used as data or
  identifier. Therefore, a subset of those, that we concentrate on
  here, has a role as identifier. Let us call this subset RParId from
  now on.

- [selected port type] identifies "the primary portType of the
  endpoint being conveyed".

- [service-port] "[identifies] the WSDL service element that contains
  the definition of the endpoint being conveyed".

[address], [reference properties], and RParId (defined above) are
properties used to identify the destination and properties of the
message as we have been talking since the beginning of issue i001.

[selected port type] and [service-port] are actually metadata. The
role of ([address], [reference properties], RParId) and ([selected
port type], [service-port]) as identifiers indeed differs in that,
when EPRs are bound to SOAP for addressing a message, only the former
are being used. Therefore, the latter can be considered along with
[policies] as metadata and it is assumed that the former contains all
the necessary information to identify what needs to be identified,
i.e. the service instance.

This means that only a portion of an EPR is the identifier, and this
portion is ([address], [reference properties], RParId).

Let's draw a parallel with WSDL concepts.

We are identifying a service instance. A service being a collection of
endpoints, a service instance is restricted to one of these endpoints.
An endpoint has an an address, and [address] clearly identifies the
address part of an endpoint.

Several services and instances of those may sit at this endpoint
location, so [reference properties] and RParId are used to identify
which one is targetted.

What are [reference properties] doing? They "identify the entity or
resource being conveyed", but they also qualify the endpoint with
"associated metadata (WSDL, XML Schema, and policies)". Going back to
our WSDL definitions, [reference properties] reflect a different
service or binding component, or a difference policy, without
necessarily explicitely identifying those with say their WSDL QName.

In practice, people have expressed their desire to do routing based on
SOAP headers. Therefore, they want to address particular code which is
behind the endpoint address. Since RParId have no impact on the
description of the service, they may be used to identify a different
instance of the service identified by combination of [address] and
[reference properties].

This results in the following identification mapping, the left-hand
column being concepts identified/referenced by the property in the
right-hand column:

 endpoint address  ↔ [address]

 ---------------------------------------------------------------

 (service, binding, policy) ↔ [reference properties]

 instance of service  ↔ RParId

Therefore, issue i001 is essentially about the use of several services
at the same endpoint address requiring routing headers in the message
to be addressed.

If we adopt my proposal to remove [reference properties] (archived at
[3]), we basically encourage people to make sure that a message can be
dispatched with the [address] URI, and the message content only.

Since the definition of [reference parameters] is fuzzy, they can
still be used by people in case they really want to use header
routing, but we're basically discouraging them to do so. Basically,
just like with the Web today, one can do whatever one wants, but one
is encouraged to do things the Web architecture friendly way.

As an amendment to my own proposal, in addition to removing [reference
properties], I would like to specify that [reference parameters]
SHOULD NOT be used to identify services. In other words, RParId should
be an empty set, because [reference parameters] SHOULD NOT be used to
identify service instances.

In essence, we're aligning our spec with the Web architecture by using
one URI as the service instance identifier, while leaving a not
recommended door open for people to use SOAP headers to identify a
service if they must.

Regards,

Hugo

  1. http://www.w3.org/2002/ws/addr/4/12/13-ws-addr-minutes.html#item08
  3. http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0051.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/