requirements for a standard WSDL

[Doug Tody]

I think I agree with everything Ray said below but I would like to say more
about the concept of optional parameters to a service call.

The issue here is whether our service has a simple "function with
arguments" method call, as when SOAP is used to serialize a distributed
method call from some language, or a higher level "parameter" mechanism,
where parameters may be optional, may have default values, constraints,
and so forth.  The higher level parameter mechanism is what is most
needed to interface complex services such as SIA/SSA, or to expose most
astronomy components (tasks) as services.  Such tasks may have many
(dozens) of parameters, most of which are optional and have default values.

In general, for each service, what we want is to be able to define a
"parameter set" schema which defines a set of parameter objects, some of
which are required, some of which are optional, each of which may have a
default value, and possibly other attributes such as minimum and maximum
values, an enumerated list of values, a descriptive string, possibly
a units specifier, etc.  This could then be used on the client side to
compose a valid parameter set instance before invoking the remote service,
or it could be used on the service side to implement a parameter handling
front-end to the service.  The actual invocation would pass parameters as a
simple parameter and value whether rendered into in GET or SOAP.  Ideally it
should be possible to input parameters in any order, and services should
be permitted to extend the interface to add service-specific parameters.

Below Ray also suggests permitting interfaces to be extended to add non-standard
methods, which is also desirable.    Doug




On Thu, 17 Jun 2004, Ray Plante wrote:

> 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
> 
> 
> 
>