requirements for a standard WSDL

[Ray Plante]

Hi,

In this week's NVO MWG telecon, we discussed the topic of how best to
define standard interfaces using WSDL.  Among the issues we discussed were
how one supports optional and non-standard arguments (like the HTTP
version of SIA allows).  This discussion spilled a little onto our NVO
metadata mailing list.  This led me to jot down a strawman set of
requirements for an IVOA standard WSDL document which I thought I would 
share with this list, too.  That message appears below.  

(Hopefully, this intro gives you enough context to get something out my 
list.)

cheers,
Ray

---------- Forwarded message ----------
Date: Thu, 17 Jun 2004 13:51:26 -0500 (CDT)
From: Ray Plante <rplante at poplar.ncsa.uiuc.edu>
Reply-To: Ray Plante <rplante at ncsa.uiuc.edu>
To: metadata at us-vo.org
Subject: Re: Optional elements in WSDL

On Thu, 17 Jun 2004, Matthew Graham wrote:
> I suspect that you are using something like:
[snip]
> <message...>
>   <part name="GETRequest" type="fooType"/>
> </message>

Yes that is correct.  

> but what happens if someone comes along with their own version of, say, a
> SIAP service which uses an extended schema from the above; is there any
> way we can write the standard schema that would allow compatibility with
> this so that the same client could handle both types?

That's a good question (that I don't have an answer to) and would be 
good to prototype.  

I think the base requirements for the standard service definition is 
something like the following:

  1.  A client developer (or application) should be able to download
      the standard WSDL from the IVOA web site (i.e. as a static file)
      and from it generate a client interface.  That client can then
      interact with any compliant implementation of the WSDL by
      plugging in the appropriate endpoint address.  It should *not*
      be necessary for the client to download and process the WSDL
      associated with the specific service instance (apart possibly
      from determining the endpoint address).

  2.  To create an implementation of the standard service, it should
      be sufficient download the WSDL and use it to create a service
      binding; the standard WSDL is then sufficient to describe that
      particular instance apart from inserting the endpoint address.

  3.  Standard WSDLs must defined in such a way that optional operations 
      (i.e. methods) incur no (or negligible) cost to implementers
      that choose not to support them.

  4.  It should be straight-forward for a client to determine which
      (optional) operations an instance supports.  

  5.  When the WSDL is retreived from a particular service instance,
      it should be possible to determine that whether it (claims to)
      comply with a standard WSDL.

  6.  The standard WSDL be able to, in effect, "import" the so-called
      "VO Support" operations to include them as part of the standard
      interface.  

Augmentation of the interface in terms of "added-value" capabilities
should be okay as long as the base requirements are met.  So here are
some of the augmentations that we've come up with that we *might* want
to allow.  (Whether we do allow it depends on how easy it is leave the
door open in the standard WSDL and the cost to the implementor doing
the simplest implementation.)  

  o  allow an implementation to support additional, non-standard
     operations.

  o  allow an implementaton to support standard operations using
     extended types.  

  o  allow different portions of the interface to be supported via
     different endpoints.

It is assumed that a client that wishes to make use of this
specialized capability would have to retrieve that instance's WSDL (as
opposed to the standard one at the IVOA site) to create a proper
interface to it.  

So what we need to develop is a "best practice" specification for
defining standard WSDLs that meet these requirements.

cheers,
Ray