Re: DAML-S ProcessModel

Stanislaw,

Why are you saying that your approach is akin to Prolog? I don't see
anything specifically Prology in it.

But, in any case, I don't think that what you want to do requires a new
architecture for Web services (as somebody said in a followup email).

Instead, there can be another service which takes user goals as input
(something like "I want to buy a book of J.R.R. Tolkien") and it comes up
with a plan that includes a few steps one of which is contacting the book
service and the other filling out the order.

Talking to this planning service seems to account for your conversation
phase.


	--michael 



>>>>> Message from Stanislaw Ambroszkiewicz <<sambrosz@ipipan.waw.pl> > writes:

    > Dear Sheila,

    > You wrote: 
    > "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. "

    > My reply:

    > There is another way to realize this using "pure" 
    > declarative approach like in Prolog. 
    > In this case "a composite process" has exactly one
    > "execution trajectory", however it has two phases: 
    > Query phase, and execution phase.
    > This may be sketched as follows. 

    > Query phase:
    > The requester specifies its "desired outcome", e.g., 
    > "I want to buy a book of J.R.R. Tolkien". 
    > In the cyberspace it means that "an invoice for a book 
    > of Tolkien is delivered to the requester". 
    > The "desired outcome" must be expressed in a common 
    > generic conversation language. 
    > (As far as I know there are no means to express 
    > explicitly the "desired outcome" in DAML-S)
    > The "desired outcome" is sent to bookstore.com. 
    > The bookstore.com has a look at its database and replies: 
    > "I will send you the invoice for a book of Tolkien, if
    > you send me an order where:
    > The title is 'The Lord of the Rings' and the price is 60 euro and ...
    > or
    > the title is 'Hobbit' and the price is 30 euro  and ...
    > ... 
    > This completes more or less the query phase. 

    > Execution phase: 
    > Once the requester receives the reply from the bookstore.com, 
    > it creates the order according to the options delivered by 
    > bookstore.com, fills some additional personal data to 
    > complete the order, and sends the order to the bookstore.com. 
    > (Of course, the choice made by the requester determines the 
    > execution path. However, it is done only by the requester 
    > who delivers the initial resources)
    > The bookstore.com creates appropriate invoice and sends it 
    > back to the requester. 
    > This completes more or less the execution phase. 
    > Note that transactions is missed, however it is no problem 
    > to extend this approach with a transaction phase. 

    > As to "the service type" I will explain my view in the next 
    > email if it is still of interest. 

    > Best regards,
    > Stanislaw,

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

Received on Wednesday, 21 May 2003 16:50:25 UTC