[ogsa-wg] BES query

[Steve Loughran]

Tom Maguire wrote:
> 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.


maybe, but by putting identity information into the metadata of an 
address, we would be ignoring the bit of the WS-A spec that says "while 
embedded metadata is necessarily valid at the time the EPR is initially 
created it may become stale at a later point in time."

The nice thing about interrogating things at the far end for identity is 
you are interrogating them there and then, not some time previously and 
hoping that things havent changed.

Furthermore, if there is uncertainty about the semantics of WSDM 
resourceids, then that uncertainty must be clarified. It would seem 
superfluous just to add more stuff just because we havent nailed down 
the notion of WSDM identity. Which, I believe must implicity refers to 
the resource, not to the address you use to access it, because of course 
it is the resource that responds to the request.

> 
>>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

fine


> 
> 
>>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.

fault tolerance is always pushed out to the clients.

1. Take a URL that never, ever fails - http//www.amazon.com/

2. write an app that hits it every 15 seconds, halting with a timestamp 
when the fetch fails.

3. Put that app on your laptop, start it running, and leave it running 
as you move around from LAN to WLAN, net to VPN, home to work to travel.

4. check if the application is still running, and if not, how long it 
survived.