requirements for a standard WSDL

[Paul Harrison]

The Astrogrid Common Execution Architecture (CEA) has been designed, in 
part, as a possible solution to this problem. The approach that we have 
taken is to have a single set of WSDL and schema that describe the meta 
information about the real parameters to a particular service. This meta 
information for the parameters allows them to have many of the 
attributes that are desired below e.g. being optional, having defaults, 
descriptions etc.

I am preparing a note on this

http://www.astrogrid.org/maven/docs/snapshot/applications/design/CEADesignIVOANote.html

It contains links to all the WSDL and schema that we are currently using 
in our live implementation.

Cheers,
    Paul.



Doug Tody wrote:

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

-- 
Dr. Paul Harrison, Astrogrid Developer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572681 (direct), 571321 (switch) - 07904025192 (mobile).