Talk:Service Collaboration Demos
Go back to Service_Collaboration_Demos
- 1 PZhao: Lets Discuss Chaining Specifics
- 2 ......RHusar: RE: Lets Discuss Chaining Specifics
- 3 ............PZhao: RE: Lets Discuss Chaining Specifics
- 4 ..................RHusar: RE: Lets Discuss Chaining Specifics
- 5 .....................pzhao: RE: Lets Discuss Chaining Specifics
- 6 .......................RHusar: RE: Lets Discuss Chaining Specifics
- 7 Rhusar:Proposed Specific Service Chain
- 8 ......PZhaoRe:Proposed Specific Service Chain
- 9 ..........KHoijarvi:Re:Re:Proposed Specific Service Chain
- 10 ...............Rhusar:Re:Re:Re:Proposed Specific Service Chain
- 11 ..................PZhao:Re:Re:Re:Proposed Specific Service Chain
- 12 .......................Rhusar:Re:Re:Re:Proposed Specific Service Chain
PZhao: Lets Discuss Chaining Specifics
We take lots of time to discuss the WCS capability. But we still have no a clear scenario for this service chain demo (maybe I miss something). I think it is time to discuss what services will be used and how to chain them based on the existing service capabilities, not just WCS. PZhao 23 May 2006 (EDT)
......RHusar: RE: Lets Discuss Chaining Specifics
- I am happy that you brought up this issue. At the last NASA Web Services telecon Liping had a really nice suggestion that I fully subscribe to.
1. We all expose our respective DATA ACCESS services so the other Chainers can assess our DATA. 2. Next we access each others remote data through formal standard interfaces, WCS and/or SOAP 3. Then we perform WS chaining within our own backyard using our respective BPEL, SciFlo, WIPE, or DataFed workflow engines 4. At ESIP: a. demonstrate our respective data access and chaining operations; b. we describe our approach and experiences; c. compare with each other's approach and experiences.
This simplification would allow us to make it through the first, obviously very difficult hurdle of accessing each others data. It would also demo service chaining within our own home environments. Based on last Monday's telecon Brian also agreed with the simplified approach to our first interoperability demo.
In order to make a step in this direction we have prepared a somewhat formal description of our data access services as applied to a set of nine "interesting" air quality datasets DataFed_Data_Access_Services.
Liping, please note that these air quality datasets could be potentially useful for the Denver IGARSS06 GSN demo as well. In fact, I stuck a few notes in this regard into the above wiki page. I would like to talk to you more about the GSN demo, possibly before the May 31 telecon. If we play our cards right we may be able to combine this ESIP service chaining effort with the GSN demo. What do you think?
............PZhao: RE: Lets Discuss Chaining Specifics
I have gone through your wiki page about air quality data. That is great. We can register these data and services in our catalog and use them in our demo. Do you know any known Web service which can process and overlay these data? If yes, we can definitely chain them in our ESIP and GSN demo. PZhao 31 May 2006 (EDT)
..................RHusar: RE: Lets Discuss Chaining Specifics
Yes, in DataFed we have an array of services for processing (filtering, aggregation..), overlay etc. Thes are all legit SOAP services. Therefore, you should be able to access each service and chain those in the by the BPEL engine. A simple scenario would involve: (1) accessing a point monitoring dataset (2) aggregating from hourly to daily average (3) portraying as a geoimage (4) accessing satelllite data (5)overlaying the point and satellite data. This is a typical service chain we use in DataFed using our own chaining engine.
Hey Brian, what if we try executiong these services through SciFlo?? I would love to see how these work (or flop) through SciFlo.
The DataFed Services for data access are alredy 'published'. The other services will be exposed shortly.
This would be a terrific demo for multiple reasons: (1) it would demonstrate accessing/verifying remote SOAP services (2) allow comparison of different chaining engines (3)eliminate the difficulties of finding 'mashable' service sets. User:RHusar 1 June 2006
.....................pzhao: RE: Lets Discuss Chaining Specifics
This simple scenario as a start point looks great. In this scenario, we need at least a aggregating service, a portraying service (or a service combining aggregating and protraying) and a overlaying service besides data accessing service. For the purpose chaining, the output data of each service should be URL. Can DataFed provide above services? GMU can provide satelliete data service and overlay service. For the demo, GMU can register all necessary services and build service chain in our designer and BPEL engine. 1 June 2006
.......................RHusar: RE: Lets Discuss Chaining Specifics
Peisheng, terrific! Next week we can expose our SOAP services that can be chained:
- Data Access to spatial point data (WCS SOAP, netCDF_Table out) - AIRNOW, VIEWS_OL
- Gridding Service (netCDF_Table in, netCDF_CF grid out)
- Portrayal Service (netCDF_CF grin in, PNG out)
- Overlay (PNG & PNG in, PNG out)1 June 2006
Rhusar:Proposed Specific Service Chain
Peisheng & all, In accordance with our telecon discussions Kari Hoijarvi, from our group, has prepared a demonstration package that accesses and chains DataFed services.
Example 1: http://wiki.esipfed.org/index.php/WCS_GetCoverage_for_Grid_returning_CSV_Example This example illustrates the data access. Note that all data access services in DataFed follow the WCS protocol and as enhanced by a SOAP interface.
Example 2: http://wiki.esipfed.org/index.php/DataFed_Service_Chain_Example This example illustrates a chaining of data access, render, and save services.
Both examples use python scripts to call the services. We feel that the script approach makes the service invocation open, such that these service calls can be mimicked in any other programming environment.
The wiki pages that describe the two examples are rather detailed, but we are sure that further questions might arise for the implementation of the service chaining using BPEL or SciFlo. Therefore, Kari will be happy to respond to your questions promptly. I would hope that both the questions as well as the answers could be placed on the wiki. However, e-mail is also acceptable.
As I see it, this service chaining activity is directly applicable to both the ESIP as well as for the GSN IGARSS'06 - Denver demos.
Please do not hesitate to call on us. Rhusar 7 June 2006
......PZhaoRe:Proposed Specific Service Chain
- I just try your WCS WSDL, but we can not parse it, due to following: <import namespace="http://www.w3.org/1999/xlink" schemaLocation="../../gml/3.1.1/xlink/xlinks.xsd"/> It uses the relative directory to identify gml shema. We can not locate it. Can you change it?PZhao 7 June 2006
..........KHoijarvi:Re:Re:Proposed Specific Service Chain
- Hello, This schema is defined by OGC, so I'd rather not change it. The schemaLocation attribute in the WSDL context is meaningless. I do not remove it though, because I don't want to change schemas unless I really have to. The WSDL embeds all the schema documents, so it's easy to locate them: it's inside the WSDL. Schema tools don't always understand this, so You could try one of the following:
- Create your SchemaCollection object yourself, loop thru the WSDL schemas and add them. This is what I do that with .NET
- Load the Main schema from http://datafed.net/xs/WCS.xsd. Now all the paths are correct, and your schema loader should be able to load it all.
- Dump all the schemas from the WSDL into a folder and remove all the paths from the schemalocations.
- What tools are you using? If there's a simple change that would enable a tool, I'll be glad to implement it.KHoijarvi 7 June 2006
...............Rhusar:Re:Re:Re:Proposed Specific Service Chain
- Hey Peisheng, Its a bit quit out there. Too quiet. Would you have any news regarding your BPEL chaining effort of the services we provided? If so, it would be good to report the outcome on today's NASA Infusion telecon. If there is any piece you need from us, let me know. Rhusar 15 June 2006
..................PZhao:Re:Re:Re:Proposed Specific Service Chain
- Rudy, Sorry. These days I am out of office for OGC meeting. We are trying to test your SOAP WCS. The WCS WSDL is too complex to parse by our engine. We are still in revising our source code. Now I only know your WCS WSDL. Except WCS and render service, how about other services,such as aggregate service? Could you tell me other services' URL and WSDL? Thanks. PZhao 15 June 2006
.......................Rhusar:Re:Re:Re:Proposed Specific Service Chain
- Peisheng, In order to use the DataFed service set, we should make one of the data access services accessible from your server. I think that chaining the other services for processing and portrayal is quite doable in BPEL or any other engine provided we can make the data access working. So lets work on getting one of the data access services working on your server.
- In May I posted a set of typical data access services on the Service Collaboration Demos wiki page. Table 1 in the DataFed Data Access Services page indicates that for each dataset we have a number of different data access protocols, typically WCS, WMS, WFS, and and the services are also in URL or SOAP version. This multi-service data access approach was designed precisely to allow at least one of the protocols to be shared between our server and the client. So, it should be possible to make at least one of the data connections work.
- I would recommend accessing the AIRNOW dataset with the access services WCS, WFS, WMS, Datafed Url, Datafed SOAP. I would suggest using the WCS service - see if you can execute this from BPEL. As I recall, Liping Di stated that you can use WCS url query in BPEL.
- Once you can execute this, we should move on to the chaining. Good luck. Talk to you tomorrow on the telecon, Rhusar 18 June 2006