W3C home > Mailing lists > Public > www-ws@w3.org > May 2003

Re: DAML-S ProcessModel

From: Sheila McIlraith <sam@ksl.Stanford.EDU>
Date: Mon, 19 May 2003 10:35:43 -0700 (PDT)
To: Stanislaw Ambroszkiewicz <sambrosz@ipipan.waw.pl>
cc: www-ws@w3.org, <agarwal@aifb.uni-karlsruhe.de>
Message-ID: <Pine.GSO.4.44.0305191024490.29752-100000@ksl.Stanford.EDU>


Dear Stanislaw and Sudhir,

On Mon, 19 May 2003, Stanislaw Ambroszkiewicz wrote:

>
> Sudhir Agarwal wrote:
>     "i currently can not understand the purpose of the ProcessModel
>     completely. I understand why an AtomicProcess is needed.
>     But, why does ComplexProcess exist? Isn't it enough to have
>     only AtomicProcess? Why should a web service
>     provider show how his services works? On the other hand,
>     im not sure that a web service requester is interested in
>     knowing all that (if-then-else, while, split, fork etc.)
>     stuff as long as the service does what he wants. Even if
>     someone really wants to know that, what can he do with that
>     knowledge? Does it help him in any way?
>     ... "
>
> Really good point concerning DAML-S.
> A service requester is interested merely in the type of service, i.e.,
> what the service does expressed in *a declarative way*.

Indeed.  Some of this is provided by the service profile.

> ProcessModel offers a description of service type,
> however in a procedural way, using "if-then-else, while, split,
> fork etc."

The DAML-S process model is still a declarative description of a process.
Nevertheless the process is described in terms of procedural programming
language/workflow constructs such as "if-then-else", "while"  etc.. As
such, you can reason *about* the workflow/process using the DAML-S process
model description.  This description provides the requester with
the building blocks to have a conversation with the service -- an
exchange of messages.  A composite process can have many possible
execution trajectories, depending upon what messages are exchanged
(imagine all the different executions you could have with amazon.com,
depending upon what answers you gave to questions posed by the service).
By providing this composite process model, a requester can analyse what
answers it should give to questions to achieve a desired outcome.  This
is important for automated composition tasks, among other things.

>
> IMHO, a missing point of DAML-S is a clear definition of the
> concept of service type.

Could you please expand upon this point.  I'm not sure what you mean
by service type.

>
> It seems that the CompositeProcess defines service composition
> (integration) in a procedural manner.

Again -- the representation is declarative, the constructs that relate
the process model are, by necessity procedural.

> If it is the case, then it should be possible to make an abstraction
> and to expose a composite process as an atomic process like in BPEL4WS.

Indeed, you can do this.  There is a discussion of compiled IOPE's in the
release, and the notion of a "Simple Process" in DAML-S provides for an
abstraction in much the same way as an Abstract Process description in
BPEL4WS.

>
> Best regards,
> Stanislaw,
>
> -- Stanislaw Ambroszkiewicz
> http://www.ipipan.waw.pl/mas/
>
>

Sheila McIlraith


==============================================================================

Sheila McIlraith, PhD                 Phone: 650-723-7932
Senior Research Scientist             Fax:  650-725-5850
Knowledge Systems Lab
Department of Computer Science
Gates Sciences Building, 2A-248       http://www.ksl.stanford.edu/people/sam
Stanford University                   E-mail sam@ksl.stanford.edu
Stanford, CA 94305-9020
Received on Monday, 19 May 2003 13:35:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:42 GMT