Service invocation metadata

[Ray Plante]

Hi Tony,

(I'm back in IL and catching up with 2 days of email.)

On Fri, 26 Sep 2003, Tony Linde wrote:
> 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. 

Not all of the details handling this in v0.1 got back in v0.8.3.  To see 
what was intended by v0.1 see these diagrams:

  Service & Interface metadata
  http://www.ivoa.net/internal/IVOA/IVOARegWp03/Service.jpg

  SIA Interface
  http://www.ivoa.net/internal/IVOA/IVOARegWp03/ParamHTTPGet.jpg

  SIA Capability
  http://www.ivoa.net/internal/IVOA/IVOARegWp03/SIA.jpg

For Interface, the contents would depend on the interface class.  A Web 
Service would be simple: the Interface would be represented by a 
"WebService" and contain an "InterfaceURL" that points to the WSDL 
document.  An SIAv1.0 Interface would be represented by a "ParamHTTPGet" 
element; it's contents describes the base URL, input parameters, and the 
mime type of the results.  The Capability part is also specialized based 
on the kind of service (i.e. in terms of what it does).  

Wil and I talked about the model this week, and we thought the Interface 
part could be simplified a bit.  As you can see from the diagrams, all of 
the types shown are described either by an "InterfaceURL" or a "BaseURL".  
Only one type of Interface, "ParamHTTPGet", required other metadata to 
sufficiently describe it.  Thus, an alternative model for "Interface" 
could be:

   Interface ------------ ServiceURL (either a base URL or full URL, 
      ^            |                  depending on type)
      |            ------ InvocationType  
      |                      (= one of WebService, WebBrowser, GLUService, 
      |                                ParamHTTPGet)
      |
     ParamHTTPGet ------- ServiceURL
                  |
                  ------- InvocationType = "ParamHTTPGet"
                  |
                  ------- Param  (multiple, describes input parameters)
                  |
                  ------- HTTPResults  

One disadvantage is that this model assumes that all interfaces are 
web-based because of the required use of a URL.  Are we happy to commit to 
this?  The only examples of a service interface I can think of that 
cannot be expressed as a URL are Z39.50 and snail mail.  

I'm open to suggestions.

cheers,
Ray