owner-ogsa-wg@ggf.org wrote on 09/05/2005 01:10:24 PM:
Tom Maguire wrote:
owner-ogsa-wg@ggf.org wrote on 08/31/2005 01:32:59 AM:
The other major camp places a high priority on implementer and application freedom to use different reference formats. It considers that references always exist in some implicit relational model (maintained by applications, communities, etc.) where interesting or important identity attributes are maintained. As such, the references themselves do not need to express identity for interop.
Yes, Distributed Computing 101. If you authoritatively want to test if two things are the same you MUST ask the things. Placing the identity in the reference is an "interesting" optimization technique. The real difficulty for me (and implementers) is the "universal" context in which these identities live. One of the reasons that hierarchical namespace lookups exist is because they are capable of massively scaling. Logically flat identity spaces do not scale. There may be ways of making AbstractNames scale but I am not suitably well versed to understand how.
1. WSDM has a ResourceId (case?) property that is required to be unique. If you do a WSDM-compliant endpoint then anything can ask for the resource and all is well.
Yes, WSDM has a ResourceId property. There is little guidance on how to create the ID for a resource. Still less is said about what happens when multiple endpoints are available for a given resource. And if a ResourceId is identical then you know something; if they are different you don't know much. This is why coorelatable properties where introduced into the model. To allow a client to interogate multilple properties that allow for coorelation of differing endpoints to the same resource.
2. Having just submitted something to the editor, I am reluctant to keep chasing the moving targets that are the OGSA set of requirements. You cannot keep adding more and more unstable specifications to the requirement list if you ever want to see a working implementation ship.
So I understand your point but the question is "Does OGSA need an interoperable way to specify AbstractNames (read identity)"? I am fairly confident that AbstractNames/Identity has been an OGSA requirement for quite some time. Granted the latest incarnation is still unstable. The intent is to have composable specifications. To that end I think I am in the camp that say use WS-Addressing and keep moving. Any client that expects an EPR should continue to work even after WS-Naming is introduced.
I actually had a lot of fun in the CDDLM trying to deal with the problem of fault tolerance (=different EPRs for things), and resource lifetime (=operations to delete resources at the end of the wire), and to address things consistently. The original WS-* specification (and functional implementation) used simple unique IDs to identify things. You pass the UID down to the endpoints with your requests, you got answers back. There was no need to have uniqe EPRs; any endpoint that acted as a portal to the set of nodes you were deploying onto should be able to handle requests related to the UID.
Its only once you add the notion of state-as-described-by-a-remote-reference into the equation that suddenly we are left with the problem that that you cant do fault tolerance in a resolvable address without extra magic in the system. Maybe this is a good argument for not using URLs/WS-A addresses in this way.
I disagree with this statement. If what you mean is that by having a separation of a UID and an endpoint that this magically gives you some better ability to be fault tolerant. I don't see it. This model just pushes the fault tolerance out of the architecture and into the lap of the clients. Tom