requirements for a standard WSDL

[Paul Harrison]

Doug Tody wrote:

>Hi Paul -
>
>Thanks, I will take a look at this.  It looks like we are working on the
>same problem.  Who all is working on this within Astrogrid?
>  
>
It is mainly myself and Noel Winstanley that are working on this. The 
primary motivation was to provide a uniform interface for our worklow 
system to drive. So in terms of what we have implemented right now the 
principal client of the CEA is the workflow component, the server part 
being called Job execution system (JES), and all the communication is 
over SOAP.  CEA is implemeted as a layer on top of the SOAP transport at 
the moment, but as it is a distinct layer,  and it should be possible to 
use other transports.

>What I think we need is a component-framework architecture.  At the core is
>a standard component model which wraps some component, be it a piece of the
>VO infrastructure, or an astronomy data analysis component.  Probably the
>component interface should be capable of supporting multiple interface
>protocols, one of which would be SOAP (another might be parameter-based
>host execution, e.g., as in a unix shell).  The parameter abstraction is
>needed to support all of these models.
>
>  
>
The approach that we have taken with unix shell executables is to create 
a web services component that can act as an adapter for a unix 
executable, so that in the simplest of cases we can add web services 
access to the executable in this framework by deploying the adapter and 
adding a registry entry describing the parameters of the unix 
executable. Something more sophisitcated is really needed for the large 
astronomical packages such as AIPS or IRAF, and we will be exploring the 
approaches necessary in these cases.

>Your Astrogrid CEA is an example of an execution framework which would
>use these components.  Probably there would be multiple frameworks given
>the range of execution environments targeted.  Ideally we would like to
>be able to run on a desktop system, on a cluster, or on the grid with a
>workflow, using the same components.  We need standards for things like
>the component model and interface, including the parameter abstraction.
>
>	- Doug
>
>
>On Fri, 18 Jun 2004, Paul Harrison wrote:
>
>  
>
>>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
>>>      
>>>
>
>
>  
>

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