Difference between revisions of "Talk:Service Collaboration Demos"

From Earth Science Information Partners (ESIP)
Line 32: Line 32:
  
 
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
 
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.

Revision as of 10:05, June 2, 2006

Go back to Service_Collaboration_Demos

Discussion on Service_Collaboration_Demos.
  • To add to the discussion, log in to DataFed wiki
  • Begin each entry with ====Username: Subject====
  • To respond, add dots ====......Username: Subject====
  • Indent response text by adding : for each tab.
  • Sign your entry by ending with '~~~~',



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