- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Wed, 15 Mar 2006 16:55:05 -0500
- To: "Battle, Steven" <steve.battle@hp.com>
- Cc: "rajesh k" <rajk_cs@hotmail.com>, <public-sws-ig@w3.org>
On Mar 15, 2006, at 10:12 AM, Battle, Steven wrote: >> -----Original Message----- >> From: public-sws-ig-request@w3.org >> [mailto:public-sws-ig-request@w3.org] On Behalf Of rajesh k >> Sent: 14 March 2006 18:27 >> To: public-sws-ig@w3.org >> Cc: rajk_cs@hotmail.com >> Subject: OWL-S Composition using Multiple Partners >> >> >> Hi, >> >> I am trying to work on an example to compose services using >> OWL-S. I am using the OWL-S editor of SRI for OWL-S services >> creation. I have a few clarifications regarding the >> composition that can be done with OWL-S. >> > > There has always been disagreement in the community I'll speak of my understanding of the disagreement in the coalition, since I was part of it (the coalition and the disagreement :)). > about exactly what > kind of composition OWL-S describes. At the moment, consensus (over my grumpy body) is that it describes orchestration. > I'm sure that everyone that replies > to this message will have a different opinion. Well, if the opinions are different than mine...dismiss them! :) > It is precisely because > OWL-S lacks a formal semantics Well, that's not the reason, yes? I mean, adopt one of the formal semantics for the process model out there...doesn't necessarily settle things. One thing for sure is that OWL-S is underdescribed, which makes it bendable. Currently, the additional description the coalition has been putting forth have been toward supporting orchestration. > (something that SWSF > http://www.w3.org/Submission/2005/07/ looks at) that this continues to > be a problem. > >> I understand that OWL-S is an orchestration language like >> BPEL and it cannot support choreography [1]. > > One difficulty here is that the word 'choreography' is used in many > ways. Amen. > The view from the W3C is that a choreography describes a > multi-party interaction, as distinct from an orchestration which > defines > the way one party invokes other services. From this perspective OWL-S > does not describe choreography in general. It really only describes the > conversation between a client and a single service. That seems false. I can interact with multiple services. Oops, maybe this is my blind spot again! (I don't see how an orchestration language can sanely restrict you to interact with only one service. I mean, you'd have to do a lot of work (only interact with one endpoint, etc.) > I regard a > conversation as a special case of choreography where interactions with > other parties have been elided. > > But neither does OWL-S fully describe an orchestration, at least not in > the sense that you can execute it in the way you can execute BPEL. Why not? > OWL-S > allows partial (ie. non-algorithmic) ?? OWL-S Api and OWL-S virtual machine directly interpret/execute composite proceses. > description of a conversation, and > can be viewed as describing a set of process constraints (that a BPEL > or > some other executable should conform to). You might argue that what the above systems do in impose more (execution) semantics, but that seems to be a bit nice. >> But in the case >> of BPEL the services are combined from partner services to >> form a composition, but I am not sure how this could be done >> with OWL-S. > > Here I agree with [1] that OWL-S (at least the process model) does not > describe service composition, but process composition. Of course it's > possible to describe a process composition where each operation happens > to have a different end-point (as defined in the grounding of each > atomic process) and that these end-points just happen to belong to > different service providers. This may be good enough to invoke the > operations in the correct order. And why isn't this orchestration with more than one service? > My argument with this is, does this > adequately describe the _service_ composition? For example, where in > the > process model can we describe which service each atomic process is > associated with? Why do we need to? In the WSDL sense, afaict, if you use any operation that a service offers at an endpoint of that service, then you've used the services. Thus, service composition can be simply stringing together operations from distinct services. What else should it be? > And where is the composition of the services (as > opposed to the processes) themselves described? I don't see the difference. > ... > >> Please also let me know about composition examples involving >> multiple providers and if possible please provide me the >> pointers for them. >> > > "Semi-automatic Composition of Web Services using Semantic > Descriptions" > by Evren Sirin, James Hendler and Bijan Parsia is well worth a read. Oh great, let me beat up on you THEN say something nice at the end to make me look like a cad!!!! :) Cheers, Bijan.
Received on Wednesday, 15 March 2006 21:55:27 UTC