Service invocation metadata

[Tony Linde]

Thanks, Bob. I'm getting confused looking at my hacked versions :)

> Service.StandardURI is intended to provide this information.

How does that identify whether it is implemented as CGI or web service? 

Unless you mean it is another ResourceID and the call type, input/output
spec etc is defined in there? That sounds a good way of reducing duplicated
information. But we'll need a schema for StandardService. Going around in
circles! 

Why not define the standard as just a service with the type and other
metadata defined. Then any implementation of that interface can have a
relationship of 'ImplementsInterface' with a pointer to the standard
service.

> Service.InterfaceURL provides this.  I don't think we should 
> consume the entire contents of the WSDL, although this is 
> perhaps the same discussion we've been having all over again 
> about granularity.  But particularly for a service, where the 
> interface could change and that change could be handled 
> dynamically by referring to the current WSDL, I don't think 
> we should try to put all of this in the registry.

We do need to identify inputs and outputs: WSDL will specify this for web
schemas but we'll need it for any other interface and may want to harvest
the WSDL for fine-grained registries. I like using MIME types but we'll also
need to allow namespaces (eg to identify a VOTable input or output).

The interface should not *change* - it is a contract between the service and
its users (consumer services). It can create and implement another interface
(a V2 perhaps) but must maintain the old one as well for some time.

Using the above example, the service could add another 'ImplementsInterface'
relationship with a pointer to the new spec.

Again, I think we do need to put all this in the registry *schema* otherwise
nothing is standardised and nothing can be automated. How can I add a cone
search service to a workflow such that the workflow engine can determine
what inputs I need to provide and whether the outputs can be fed into
another service. If the user has to interpret all this non-standard
specification of interfaces then the VO will provide little more than
existing services.

Finally...

I'm not sure about ServiceMSR. There's an unlimited number of restrictions
we might want to put on services - it seems strange to single out one
limitation from one type of service to include in our schema.

Cheers,
Tony. 

> -----Original Message-----
> From: Robert Hanisch [mailto:hanisch at stsci.edu] 
> Sent: 26 September 2003 18:13
> To: Tony Linde; registry at ivoa.net
> Subject: Re: Service invocation metadata
> 
> 
> If you go back to RM0.8x I think you'll find the necessary metadata.
> 
>     Service.InterfaceURL
>     Service.BaseURL
>     Service.HTTPResults
>     Service.StandardURI
>     Service.StandardURL
> 
> 
> ----- Original Message ----- 
> From: "Tony Linde" <ael at star.le.ac.uk>
> To: <registry at ivoa.net>
> Sent: Friday, September 26, 2003 12:57 PM
> Subject: Service invocation metadata
> 
> 
> > How do we specify in the metadata for a *service*, the way that that
> service
> > should be invoked?
> >
> > The current schema has minimal Capability and Interface, neither of 
> > which describes how to call the service.
> >
> > We need to specify:
> >
> > 1. what type of service it is (enumerated list: WebService, 
> CGI - any 
> > others?).
> 
> Service.StandardURI is intended to provide this information.
> 
> > 2. what parameters it takes and the data types of those 
> parameters (I
> guess
> > for a web service we just need to include some part of the 
> WSDL) and 
> > how they are referenced ('name' part of the 
> ?name=value&name2=value2 
> > for cgi).
> 
> Service.InterfaceURL provides this.  I don't think we should 
> consume the entire contents of the WSDL, although this is 
> perhaps the same discussion we've been having all over again 
> about granularity.  But particularly for a service, where the 
> interface could change and that change could be handled 
> dynamically by referring to the current WSDL, I don't think 
> we should try to put all of this in the registry.
> 
> > 3. the address of the service (url mostly).
> 
> Service.BaseURL
> 
> >
> > 4. anything else?
> >
> > Cheers,
> > Tony.
> >
> > __
> > Tony Linde                       Phone:  +44 (0)116 223 1292
> > AstroGrid Project Manager        Fax:    +44 (0)116 252 3311
> > Dept of Physics & Astronomy      Mobile: +44 (0)7753 603356
> > University of Leicester          Email:  ael at star.le.ac.uk
> > Leicester, UK   LE1 7RH          Web:    http://www.astrogrid.org
> >
> >
>