Tom, Keep in mind that this is email and tone is not carried well. You state below that " 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." So actually I have taught (and been taught) "Distributed Systems 101". :-) It is not the case that you MUST ask the things if they are the same. That is the lesson of the strength of good naming systems. If the minter of the names ASSERTS that if the two strings are the same - they are the same, then you don't have to go to the service itself. (With respect to the spoofing problem, see my mail to Karl a few minutes ago.) Systems such as Amoeba (Tannenbaum), Globe (), Clouds, and others have this property. Going back to the first ACM workshop on Distributed Systems in Tromso (1988, Sape Mullender), and in particular to the short exposition by Roger Needham in the Second ACM Workshop on Distributed System, pp 312-327, the use of abstract names (called pure names by Needham) to be able to determine if the endpoint is the same endpoint has been used. There are issues of alias', and one to many bindings of course, but the key concept is that the client does not need to be aware of those usually. So to me it is more than an optimization technique. As to the scaling - there are many ways to scale "flat" names spaces. Keep in mind that a hierarchical name space can be represented in a flat name space - and vice versa (with no loops - i.e., DAGS). As an aside I want to re-iterate that I am not proposing that WS-Names be mandatory for all OGSA interactions - only that they be used were appropriate - i.e., were one can reasonably assume that clients may need to be able to know if to endpoints are the same. I would argue that BES fits this description. Andrew -----Original Message----- From: Tom Maguire [mailto:tmaguire@us.ibm.com] Sent: Wednesday, August 31, 2005 9:51 AM To: Karl Czajkowski Cc: Michael Behrens; Dave Berry; Ian Foster; Andrew Grimshaw; ogsa-wg@ggf.org; owner-ogsa-wg@ggf.org; Tom Maguire Subject: Re: [ogsa-wg] BES query owner-ogsa-wg@ggf.org wrote on 08/31/2005 01:32:59 AM:
On Aug 31, Michael Behrens modulated:
The major aspects are:
1. whether a reference avoids aliasing for all time, e.g. it either addresses a specific service/resource identity or nothing at all
2. whether a stale reference can be renewed to address a specific service/resource identity after migration etc.
3. whether references can be compared for a remote service/resource identity predicate
4. whether references can be remotely mapped or projected to a unique AbstractName
I hesitated to use the word "reference" but cannot think of a more neutral term right now.
I think that all the camps feel that (1) should be mandated for the Grid.
I think (less certainly) that everyone feels that (2) should be optional for the Grid. This is what was proposed in the "renewable reference" draft. This is, for example, an EPR containing a resolver EPR.
I agree that (1) and (2) as stated are generally agreed upon as necessary traits. What I am less certain about is the likelihood that WS-Naming (as a profile) will address (2). If not, then I believe we need another profile that would address this need. In fact this is where we started with OGSA Basic Profile (BP). The "renewable" requirements were redacted from the BP after several discussions with the WS-Naming WG.
The major point of division falls on (3) and (4):
There is one camp who place a high priority on having a global one-to-one mapping of AbstractName to service/resource identity. Such identity must be tied up in the stateful semantics of the service/resource. The opposing camp continues to argue two things: 1) that this is not really very important, and 2) that perhaps it is even misleading or impossible to have one universal notion of identity across different application domains, communities, or implementation technologies.
I guess I am in the opposing camp :-).
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.
I note that there is an underlying clash in "worldviews" here between the camps. One camp considers AbstractName to be central to architecture with other reference/addressing data to be secondary implementation requirements---the reference/address data is to be resolved, refreshed, or discarded at will. The other camp considers reference/addressing data to be central to architecture with AbstractName or other identifying attributes to be secondary, domain-specific associations that might apply in one community or another.
What I am struggling to answer for myself is: is there a sensible third camp that puts these two views on equal (neutral) footing, or do we have to adopt one view to make standards for interoperability?
Perhaps but I am not clear on how you would do this.....
karl
-- Karl Czajkowski karlcz@univa.com