[SAGA-RG] Suggested errata to the SD spec

Steve Fisher dr.s.m.fisher at gmail.com
Wed Apr 15 07:54:15 CDT 2009


2009/4/15 Andre Merzky <andre at merzky.net>:
> Hi Steve,
>
> Quoting [Steve Fisher] (Apr 15 2009):
>>
>> Hi,
>>
>> We would like to get rid of the URL passed into the discoverer
>> constructor. Its comment is:
>>
>> "the url specified as in input parameter is to assist the
>> implementation to locate the underlying information system such that
>> it can be queried"
>>
>> The problem we have is that this does not work with an adapter based
>> implementation as the URL is normally specific to the adapter.
>
> I'm sorry, you lost me: why is that not working?  The
> implementation should be able to forward the URL to the
> adaptor, where it is needed?

The implementation must pass it to all adapters - but it will only
make sense to one of them. For gLite it would point to some BDII
server which provides information for gLite. No other adapter is
likely to be able to make sense of this.

The only real benefit of the engine with multiple adapters is if
multiple adapters can be used in one call.

I think the Job Service will have much the same problem as typically
only one adapter can actually be expected to respond sensibly and
accept the job it is given. Even if you have used Service Discovery to
get the URL of the Job Service to use the saga engine will still have
to cycle through making calls to all the adaptors ahead of the one
that is going to work for you. So in this case you really want to be
able to dynamically influence the sequence of adaptors to avoid a load
of wasted network calls - and timeout delays ...

Steve


>
>
>> This information can be passed to the adapter using a
>> configuration file or an environment variable according to
>> the style adpopted by the adaper writer.
>
> That is an orthogonal issue IMHO.
>
> I would like to compare that to the job::service, where we
> give a contact URL for the job submission endpoint.  That
> URL is adaptor specific, e.g. it could be
> 'gram://remote.globus.host:123/'.  That URL would then be
> forwarded to the adaptors.  Only the globus adaptor would
> accept it, and act on job submission requests.
>
> OTOH, if the URL is not specified (it is optional in te
> API), then a default URL from the adaptor configuration
> files is used.  That could also be an env variable, as you
> state above.
>
> What is the problem with that scheme?  Seems to work for
> job::service and other classes - why not for the service
> discoverer?
>
> Thanks, Andre.
>
>
>
>> The constructor then just has the session handle
>>
>> The other change is to make the attribute names consistent with the
>> rest of SAGA - i.e. CamelCased
>>
>> Steve
> --
> Nothing is ever easy.
>


More information about the saga-rg mailing list