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

[Steve Fisher]

2008/12/18 Andre Merzky <andre at merzky.net>:
> 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.

Sorry that is what I meant. The session has not expired but it is
inoperable because credentials have expired

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

Which approach is optimal depends upon the information system. However
there are advantages in making sure that list_services gets everything
loaded into memory because as you have pointed out it makes sure that
the subsequent get methods cannot fail.

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

Yes I agree it would be best to get all the service info in one go.
Then it either succeeds or fails

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

This time I don't agree. For someone looking for one service it would
mean two calls to the info system rather than one, also even if you
find the service is available in the constructor it may have died by
the time you do list_services. So you need the exceptions in
list_services to cover lost credentials, timeouts/dead services,
authz, I would be happy to assume that the constructor only contacts
another service as part of the session setup and does not contact the
info system.

Actually I don't think that much use will be made of the url
parameter. Rather I expect the sysadmin to make sure that the desired
set of adapters is installed and each will probably have its own
configuration file

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