Re: OWL-S Composition using Multiple Partners

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