[SAGA-RG] Service Type

[Andre Merzky]

Hi Steve, 

Quoting [Fisher, SM (Steve)] (Feb 21 2008):
> 
> > -----Original Message-----
> > 
> > Quoting [Fisher, SM (Steve)] (Feb 20 2008):
> > > 
> > > Hi,
> > > 
> > > I was just making the agreed chnages to the SD spec when I relaiszed
> > > that you said to use saga::<package>::<class> with package and class
> > > according to the implementation language. This won't work easily as
> > > means altering the string from the information service or 
> > wherever it
> > > comes from according to the chosen language. I think that a 
> > service type
> > > must be independent of the chosen language and so taken 
> > from the spec.
> > 
> > I don't think that language dependence is a problem, as I
> > would expect the SAGA implementation to translate that into
> > valid types anyway.
> > 
> > In other words: I would not expect a SD _service_ to know
> > about saga::job::service service types, but, for example,
> > about
> > 
> >   service_type=job_submission
> >   service_type=job
> >   service_type=job_management
> >   service_type=DRMAA
> >   service_type=BES
> >   etc
> > 
> > and the SAGA implementation would translate
> > 'saga::job::service' into the respective values (the
> > SAGA implementation is what shields the application
> > programmer from middleware details, and the exact service
> > type strings are exactly that, middleware details...).
> > 
> > Does that make sense to you?
> 
> Not really. The SD part of SAGA should cannot be expected to translate
> from the real service type in the information system to some language
> specific one as this would require translation from the language
> specific name to the langugae neutral name before looking up - and
> updating this table for each new service or language binding. I find
> this not very manageable. It is the responsibilty of the service to
> publish its type in a language independent manner

You are actually the expert here.  But my gut feeling would
be that it is _very_ difficult to impose a SAGA schema onto
service publishers.  Also, that would give problems with
currently sxisting schemas, and already published services
etc.

Yes, mapping to specific schemas is certainly difficult -
but well, someone _has_ to do it, and I am actually fine
with any solution, as long as this problem stays away from
the end user.


> My favoured way of naming services is reverse DNS style. So the job
> service would be org.ogf.saga.job. However these names cannot be derived
> automatically from the spec - as this would give
> org.ogf.saga.job.job_service. Maybe the best approach is an erratum to
> the main spec which for each service like thing gives it a unique
> reverse DNS type name

Well, of course you like that reverse DNS, that is soooo
Java ;-))  hehehe

Well, naming is always matter of taste, I like the C++ style
more, obviously.  But I agree, there is no need to make that
lnaguage specific.  But possible it is.

As for managing that mapping list: again I think that a
receipe on how these names are formed should be enough.
Your reverse DNS name is just the Java class, right?  Thats
unique, and easily defined...  Same can be done in C++ etc.


Anyway, I think we are running circles at the moment.  We
first should agree upon who is doing the mapping, then we
can agree on the naming, and the mapping table...


> I am sorry I am being so slow to respond. I am trying to do too many
> things at once - I hope it will be better in April.

np, same here.  Hope you are not getting frustrated with the
slow progress....

Best, Andre.



> Steve



-- 
"We've got too much time to waste to stand around here doing things."
                                                             - Tigger