[ogsa-wg] BES query

[Tom Maguire]

owner-ogsa-wg at ggf.org wrote on 09/05/2005 01:10:24 PM:

> Tom Maguire wrote:
> > owner-ogsa-wg at 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