- From: <noah_mendelsohn@us.ibm.com>
- Date: Sun, 30 Jan 2005 19:14:47 -0500
- To: $)CHugo Haas <hugo@w3.org>
- Cc: $)Cpublic-ws-addressing@w3.org, www-tag@w3.org
- Message-ID: <OF55AD9979.8A0F8987-ON85256F97.007FF3C4@lotus.com>
$)CHugo, You wrote this note on January 10th, and it occurred to me then that some of the issues you explore might be fruitful points of discussion in the F2F meeting between the TAG and WS-Addressing groups at the plenary (for the moment, I'm speaking for myself here, and not on behalf of the TAG). Since then, you've had your Melbourne F2F, and I believe there has been progress on identity issues. I wonder whether you might care to send a note updating the attached, either informally or officially on behalf of the WS-Addressing group, and whether you agree that some of these issues might be likely points of discussion? I'd also of course welcome opinions from the TAG. Thank you. -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- Hugo Haas <hugo@w3.org> Sent by: public-ws-addressing-request@w3.org 01/10/2005 06:18 AM To: public-ws-addressing@w3.org cc: (bcc: Noah Mendelsohn/Cambridge/IBM) Subject: 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 !j [address] --------------------------------------------------------------- (service, binding, policy) !j [reference properties] instance of service !j 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/
Attachments
-
$)C
- application/octet-stream attachment: signature.asc $)C
Received on Monday, 31 January 2005 00:17:08 UTC