[SAGA-RG] Service Discovery spec updated at last ...

[Andre Merzky]

Quoting [Steve Fisher] (Dec 18 2008):
> 
> > In the attached version, I tried to address the things we
> > agreed upon, and changed the service types/names table as
> > proposed.  Could you give it another pass, please?
> > I left the Constructors untouched for now, until we agreed
> > on something, ok?
> >
> > Also, there is a question from me at the bottom of page 5:
> >
> >  "Note: Why not TimeOut, AuthorizationFailed, etc??"
> 
> For the discoverer constructor, I guess the Authentication exception
> can be thrown if you don't pass in a session or if you pass in what
> used to be a valid session that has since expired. How would you class
> that one?

A session cannot expire - its lifetime is defined by the
lifetime of the objects which use that session.  If a
context (or credential) attached to that session expired,
you can expect to see a lot of AuthenticationFailed
exceptions, whenever that credential is being used.


> Unfortunately quite a lot of the allocation of exceptions is
> implementation dependent. It would be better to be able to just throw
> a Security exception - but that is not an option as it is not in the
> core spec. If you need to get authenticated this could result in a
> timeout if contact with some remote server is required.

Well, than that is a TimeOut exception :-))  In general, it
is of course difficult to map backend exceptions to SAGA
exceptions in a meaningful way, but that cannot be avoided
really, if the end user is to stay away from middleware
exceptions.


> In our current implementation, list-services does most of the work and
> so can throw timeouts and could throw security errors except that we
> happen to connect to a non-secured information service. However the
> subsequent calls (such as get_data) can throw the same exceptions as
> they could choose to go back to the information service to pick up
> information that was not originally needed when making the selection.
> If we don't allow the possibility to throw these exceptions the
> implementation is needlessly restricted. This is why I like the
> NoSuccess everywhere. In other words I would use NoSuccess for those
> conditions which are implementation dependent - which in this case is
> quite a lot.

Good point, so NoSuccess may make sense in all calls.  I
expected all implementations to simply fetch complete
service descriptions, not only parts, but that may have been
to limiting.  

But, is that really the way you expect implementations to
work: to fetch some part of the service description, but,
e.g., the name and URL just later on, on the get_attribute
calls?  That adds an awful latency overhead, which easily
kills any bandwidth savings, as long as you stay below x.000
returned service descriptions - which is the dominating use
case I dare to say. 

Requiring the implementation to fetch complete desciptions
is a certain limitation, sure, but allows more tightly
defined semantics for the application and end user...

So, that is up to you (I do not know the implementations),
but please consider the argument.


> For example you have added DoesNotExist for the
> constructor - implying that the API would contact the underyling
> information service. However there is no reason why it should do so at
> this stage.

We have the same problem with the RPC package - there the
Constructor has the following note:

  - according to the GridRPC specification, the constructor
    may or may not contact the RPC server; absence of an
    exception does not imply that following RPC calls will
    succeed, or that a remote function handle is in fact
    available. 

and the call() method has the following one:

  - according to the GridRPC specification, the RPC server
    might not be contacted before invoking call(). For this
    reason, all notes to the object constructor apply to the
    call() method as well.

Also, call() has all exceptions of the Constructor, to allow
for delayed throws.  

These notes are, as noted, a result of an underspecification
of the GridRPC standard.  I would really like to avoid to
sprinkle such notes all over the place, as it makes a tight
semantic definition of the API rather impossible.

I think, if you have no really hard constraints from an
underlying standard (as we had with RPC), or from a
absolutely dominating implementation, it is not too much to
ask from an implementation to ensure in the Constructor if
the given (or chosen) URL actually points to a service which
is alive and usable - what do you think?

Otherwise, indeed, you need to repeat all exception on all
calls (which makes catching and error recovery tedious for
the application), or map them all to NoSuccess later on
(which also gives the application no useful means to
recover, e.g. an application does not get the info that a
different URL or context may have helped).


> > Nothing is ever easy.
> 
> I am inclined to agree

:-))

Best, Andre.


> Steve



-- 
Nothing is ever easy.