requirements for a standard WSDL

[Doug Tody]

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?

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.

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