[ogsa-wg] BES query

[Tom Maguire]

owner-ogsa-wg at 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 at univa.com
>