StandardInterfaces V0.1

[Guy Rixon]

On Fri, 16 Jan 2004, Wil O'Mullane wrote:

> > >>- why restrict this to web services? We should be able to agree more than
> > >>one way of implementing services: web service and cgi as a minimum I guess.
> > In my mind, I would be very surprise if the future of the astronomy will
> > be only WS. I think that after this fashion time, this technology will
> > take its real place : an open remote procedure call mechanism. Not more,
> > not less. And it certainly won't replace simple CGIs for which there is
> > no real client side.
>
> Yes of course .. I took this out of SkyNode which is SOAP based and it was in the WEb/Grid Servives section. Hence the WS leaning.
>
> Then I have a question.
> If we have these standard interfaces for any CGI how do we relate that to the
> cgi. DO we add a single parameter like SI where
> SI=metadata returns metadata
> and SI=HarvetLog&fromDate=1-1-2000  returns the log.
> I presume we may still asume XML is returned from these type fo calls.

At the Strasbourg meeting you suggested (IIRC) a ?metadata prefix on the HTTP
GET URL; similar to ?WSDL for Axis SOAP services.  Is that idea still
feasible?

> Or should we assume for each CGI a seperate CGI so if i have
> ../cgi-bin/X
> I should have
> ../cgi-bin/stdifX
> which implenets the standard interfaces..
>
> I rather like option 2 as it means no changes to existing code.

If we do it this way, how do we associate the CGI call for metadata etc with
the CGI for the basic service?  Should it be like

.../cgi-bin/ServiceXyx/TheActualService
.../cgi-bin/ServiceXyz/stdifX
.../cgi-bin/ServiceXyz/stdifY
etc?

In that case it won't fit trivially to all existing services without recoding
as not all will have the right directory structure.

We could also allow

.../cgi-bin/TheActualService
.../cgi-bin/ServiceXyz/stdifX
.../cgi-bin/ServiceXyz/stdifY
etc

or

.../cgi-bin/AnyPathYouLike1/TheActualService
.../cgi-bin/AnyPathYouLike2/stdifX
.../cgi-bin/AnyPathYouLike3/stdifY

and sort the paths out in the registry, with a recommendation to use the same
path for all three parts for new work.

However, if we do this we don't allow the standard interfaces to be coded as
part of the basic service, and some authors may prefer to do that.

Is it better to simplify the writing of CGI services by allowing any paths or
the writing of clients by prescribing the path?



>
> For SOAP services of course the document as stands would be fine.
> XSD may be worked up for the indidvidual return types...
>
>
> wil
>
>
> >
> > Regards,
> > Pierre Fernique
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523