[ogsa-wg] BES query

[Karl Czajkowski]

On Aug 31, Michael Behrens modulated:
> 2-cents:  It is my understanding that EPRs can't by themselves be
> guaranteed to be unique or that bit-wise comparisons are unreliable
> considering canonicalization and embedded metadata issues.  If so, then
> a unique AbstractName is needed in order to accurately resolve EPRs,
> especially considering the potential service migration.
> Instead of mandating, perhaps the speficiations can recommended the use
> of WS-Naming?  Specifications could still accept EPRs and
> implementations can check them for the presence of an AbstractName and
> take advantage of it if available (internal hash table, etc).
> 

I have to admit, I may not entirely understanding the different
viewpoints in this ongoing discussion (ongoing at least since OGSI was
unveiled in Toronto?)... but, there are many separable aspects to
these notions of uniqueness and naming, and I get the impression that
there are at least two camps who prioritize these aspects in different
ways.

I want to emphasize that I am personally sitting on the fence, but
trying to reinterpret what everyone is saying!  I would love to see
comments on whether I am fairly portraying the different positions
here...

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.

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.

The other major camp places a high priority on implementor 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.

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?


karl

-- 
Karl Czajkowski
karlcz at univa.com