From A.Gray at cs.man.ac.uk Thu Jan 14 03:46:07 2010 From: A.Gray at cs.man.ac.uk (Alasdair J G Gray) Date: Thu, 14 Jan 2010 09:46:07 +0000 Subject: [DAIS-WG] WS-DAI Core WSDL Message-ID: <42A175D4-CF35-4D49-ABA6-1251AD07D89C@cs.man.ac.uk> 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. 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. Here are some specific questions: 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]? Are there plans to update the WS-DAI standards, specifically to use WSDL 2.0 with its single interface declaration per service? Why does the WS-DAI Core specification WSDL not declare the GenericQueryFactory operation in the same way that it has a GenericQuery operation? Thanks, Alasdair [1] http://www.semsorgrid4env.eu/ [2] http://www.ogf.org/documents/GFD.74.pdf [3] http://ws.apache.org/axis2/ [4] http://cxf.apache.org/ [5] http://ws.apache.org/axis/ Dr Alasdair J G Gray Research Associate A.Gray at cs.man.ac.uk Room 2.126 School of Computer Science Kilburn Building University of Manchester Oxford Road Manchester M13 9PL, UK tel: (+44) 0161 275 6132 fax: (+44) 0161 275 6204 Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/dais-wg/attachments/20100114/f9f01f1b/attachment.html From michaelj at epcc.ed.ac.uk Thu Jan 14 04:57:19 2010 From: michaelj at epcc.ed.ac.uk (Mike Jackson) Date: Thu, 14 Jan 2010 10:57:19 +0000 (GMT) Subject: [DAIS-WG] WS-DAI Core WSDL In-Reply-To: <42A175D4-CF35-4D49-ABA6-1251AD07D89C@cs.man.ac.uk> References: <42A175D4-CF35-4D49-ABA6-1251AD07D89C@cs.man.ac.uk> Message-ID: Hi Alasdair, On Thu, 14 Jan 2010, Alasdair J G Gray wrote: > 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. 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. > > Here are some specific questions: I'm an OGSA-DAI developer, so can answer this question... > 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]? We didn't encounter the issue as the WS-DAI WSDLs are based on WSDL 1.1 so we continued to use Apache Axis 1.4, which (in addition to GT4.0/4.2) we traditionally use for web service development. I should clarify at this point the distinction between WS-DAI and OGSA-DAI. OGSA-DAI is not an implementation of WS-DAI as it currently stands - its service APIs are based on a version from March 2003 which featured workflows. The specifications diverged from OGSA-DAI after this point and WS-DAI no longer has the notion of workflows. However, the product retained them as they were of use to our users. OGSA-DAI WS-DAIR and WS-DAIX are however reference implementations of the latest WS-DAIR versions. These were built using OGSA-DAI - WS-DAI-compliant service layers have their functionality implemented behind the scenes using OGSA-DAI's workflow engine. AMGA WS-DAIR provides another reference implementation using a different approach. There are no plans at this time to update OGSA-DAI to use more recent web service frameworks. I'll leave these questions to the specification authors... > Are there plans to update the WS-DAI standards, specifically to use WSDL > 2.0 with its single interface declaration per service? > Why does the WS-DAI Core specification WSDL not declare the > GenericQueryFactory operation in the same way that it has a GenericQuery > operation? Cheers, mike > Thanks, > > Alasdair > > [1] http://www.semsorgrid4env.eu/ > [2] http://www.ogf.org/documents/GFD.74.pdf > [3] http://ws.apache.org/axis2/ > [4] http://cxf.apache.org/ > [5] http://ws.apache.org/axis/ > > Dr Alasdair J G Gray > Research Associate > A.Gray at cs.man.ac.uk > > Room 2.126 > School of Computer Science > Kilburn Building > University of Manchester > Oxford Road > Manchester > M13 9PL, UK > > tel: (+44) 0161 275 6132 > fax: (+44) 0161 275 6204 > > Please consider the environment before printing this email. > > ------------------------------------------------------------------- Dr. Michael (Mike) Jackson E-mail: m.jackson at epcc.ed.ac.uk OGSA-DAI project EPCC WWW: http://www.ogsadai.org.uk WWW: http://www.epcc.ed.ac.uk http://sourceforge.net/projects/ogsa-dai The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From mario at epcc.ed.ac.uk Thu Jan 14 07:47:13 2010 From: mario at epcc.ed.ac.uk (Mario Antonioletti) Date: Thu, 14 Jan 2010 13:47:13 +0000 (GMT) Subject: [DAIS-WG] WS-DAI Core WSDL In-Reply-To: <42A175D4-CF35-4D49-ABA6-1251AD07D89C@cs.man.ac.uk> References: <42A175D4-CF35-4D49-ABA6-1251AD07D89C@cs.man.ac.uk> Message-ID: 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. From steven.lynden at aist.go.jp Thu Jan 14 23:34:41 2010 From: steven.lynden at aist.go.jp (Steven Lynden) Date: Fri, 15 Jan 2010 14:34:41 +0900 Subject: [DAIS-WG] WS-DAI Core WSDL In-Reply-To: References: <42A175D4-CF35-4D49-ABA6-1251AD07D89C@cs.man.ac.uk> Message-ID: <8ac07a241001142134x7b104a7br97ed7933e8ba06cf@mail.gmail.com> 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. I think its worthwhile, especially if it gets more people involved/interested. On a related note there is some interest in a RESTful profile/bindings, discussed last year on this list. > 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. One reason could be that if you implemented a GenericQueryFactory operation and created a new resource the only thing that you could describe it with using the core specification would be the basic DataResourceDescription. Probably you would want to extend that in order to describe the characteristics of the new resource. If it was extended you would be defining a new type of resource and the correct place for that would be in an extension of the core spec such as WS-DAIR or WS-DAIX etc. GenericQuery is defined without any assumptions about the way it is used (including use of factory patterns), you can send any type of query and get anything back. As Mario said its usefulness was debated during the interop process. Do you envisage using 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. > > -- > dais-wg mailing list > dais-wg at ogf.org > http://www.ogf.org/mailman/listinfo/dais-wg > Steven.