[DAIS-WG] WS-DAI Core WSDL

[Mario Antonioletti]

Hi,

> As part of the SemSorGrid4Env project [1], I have been developing a Web
> service to enable data access to data streams. As a project, we have
> decided to adopt the WS-DAI standard for data access and define suitable
> extensions for streaming data.

I am glad to hear this though one slight correction. These specs are 
still officially proposed recommendations. We have just been through
an interop process that corrected a number of points in GFD.74 
(WS-DAI) and GFD.76 (WS-DAIR). The process and proposed changes are
outlined in GFD.160 (http://www.ogf.org/documents/GFD.160.pdf).

> However, I have encountered numerous problems in using the WS-DAI 
> Core WSDL specifications [2] with recent Web service frameworks, 
> specifically Axis2 [3] and CXF [4]. The root cause of these problems 
> stems from the use of multiple porttypes in the WS-DAI Core 
> specification, which is not so well supported in these Web service 
> frameworks due to the move to using a single interface for a Web 
> service in WSDL 2.0.

I am sorry to hear this. I'm not the original author of the WSDL/XSD
and I am no expert in this space so bear with me ...

> Here are some specific questions:
>  1. Have other developers, e.g. the OGSA-DAI team, encountered such
>     issues and how have they resolved them? Also, are there plans on
>     moving the OGSA-DAI software to use a more recent Web service
>     framework than Axis [5]?

Mike already answered this.

>  2. Are there plans to update the WS-DAI standards, specifically to use
>     WSDL 2.0 with its single interface declaration per service?

Not at the moment. However, if you like to help do this we could
possibly take it on if the other group members think that this would
be a worthwhile thing to do. Is it possible for a client to 
interoperate with a WSDL 1.1 and a 2.0 service or is this not 
possible? Are the two message types specified in the WSDL compatible
at all?

>  3. Why does the WS-DAI Core specification WSDL not declare the
>     GenericQueryFactory operation in the same way that it has a
>     GenericQuery operation?

You mean why does it not declare it at all? The core spec only 
proposed a set of patterns to be adopted by extensions to the core 
spec. At the time I think it was thought that that would become the 
responsibility of the extensions to particular data models as indeed 
has become the case. In the interop process it became somewhat 
superfluous to use Generic Query when there were more suitable 
alternatives from the Relational spec. In a context where a service 
might operate with a more diverse type of data this might be a nice
way to generically access data. As for the GenericQueryFactory as far 
as I recollect the rationale, as I said, was that the core spec would 
infer the message exchange pattern and it would be up to the 
realisations to actually implement it.

I think these are partial answers but if you are willing to enter a 
dialogue can try to substantiate these matters. I also welcome any 
input from my colleagues who might have a point of view.

Mario

+-----------------------------------------------------------------------+
|Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ.   |
|Tel:0131 650 5141|mario at epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ |
+-----------------------------------------------------------------------+
-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.