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

To aid discussion of Hugo's action item, I came up with a simplified UML
data model of endpoint references, which helps to illustrate the things 
being
discussed in Hugo's contribution below.  It is attached as a one page 
PDF document.

Tom Rutt


Hugo Haas wrote:

> 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/
>


-- 
----------------------------------------------------
Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133