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