Re: OWL-S Composition using Multiple Partners

I was just going to offer some clarifications, but I see Bijan has beat 
me to it, and done a great job.  I agree with all that Bijan has said, 
and I particularly want to stress:

(1) OWL-S can fully describe an orchestration, and when such a full 
description is specified, it can be executed.  Various environments / 
libraries have been built that do this, notably by MINDSWAP and CMU.

(2) An OWL-S process model can specify interactions with several service 
providers, not just one.

Also, for the benefit of Rajesh - the composite process of SP4 would 
invoke the processes of SP1, SP2, and SP3 using 3 different "Perform" 
constructs.  However, SP4's composite process *by itself* isn't actually 
committed to any particular *providers* of SP1, SP2, and SP3.  In that 
sense, the composite process is incomplete.  The grounding fills in the 
commitments as to which particular providers will be used (and, in the 
default grounding approach, it relies on WSDL to specify these details).

Regards,
David

Bijan Parsia wrote:

> 
> 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 Thursday, 16 March 2006 23:26:07 UTC