Re:Was Process Model

Mark

Thanks again for your valuable help.

As regards the IOPEs,
When a requester agent queries a matchmaker then as a result the latter
would return information regarding a matched web service. This information
would include the IOPEs which come from the service Profile and which the
provider would have advertised with the matchmaker earlier. Correct?

So in practice the requester would already know about these IOPEs, what it
doesn't know is the type of process, be it atomic or composite. If it is
atomic then no intermediary steps are needed, and presented with the input
the provider agent should present the output, but if it is composite then
there has to be a continuous "consultation" with the process model to
identify the workflow from the input to the output (with the possibility
that the intermediary output of one atomic service is used as an output to
the next atomic process in the sequence) until all the processes involved
are executed.
Is this what you meant?

So the process model would be a guide for the requester agent that indicates
to it which inputs it (requester) has to present and which outputs to
pretend from an atomic process (from the provider). So in practice the
requester must avail itself of an interpreter and a parser, so that with one
it parses the process ontology and with the other it understands what to
make out of this parsed structure. Correct?
Any suggestions of already available interpreters to use?
Is it sensible to think of an interpreter as for example a group of java
classes specializing in giving meaning to DAML constructs?

And the work of the provider is to advertise the service profile with a
matchmaker, pass the required inputs into the web service's methods and pass
the computed outputs to the requester. Is it not? Have I left something out?

Regards

Charlie


Charlie Abela writes:
 > Hi Mark
 >
 > Thanks for your reply.
 >
 > I have re-viewed the docs regarding DAML-S and have come to a conclusion,
 > hopefully the right one, about the utility of the Process model.
 >
 > By having the possibility to describe the web service as a number of
 > processes, gives the programmer the advantage of not hard coding the web
 > service's work flow. The code that would be necessary must not handle how
 > the service is going to be executed but a way of interpreting this
execution
 > from the Process model.
Correct, as long as you understand that this is the code for the CLIENT.

 > Considering the example of an atomic process, such as LocateBook, the
 > interpreter should be able to verify that the input presented by the
 > requester agent is infact a string and is matched to the bookName
parameter.

I don't think I follow you here. "the input presented by the requester
agent" sounds like you are now talking about the service provider, not the
what the requester needs to do to request the service (the requester is the
intended consumer of the process model.)

 > Eventually it must identify which outputs and their type are to be
presented
 > to the requester agent if the necessary conditions are satisfied, ie that
 > the InCatalogueBook returns some Boolean truth-value.
The IT here still seems to be the server, not the client.

 > Is this line of thought correct? Is an interpreter the tool that a
software
 > agent needs to make sense out of the constructs?

Turn it around and think about it this way: A user tells his software agent
to buy a copy of Lord of the Rings from Amazon. There is no pre-coded
mechanism in that agent to talk to Amazon.com, but it can ask Amazon for
its service model and, using the ontology of terms associated with the
inputs and outputs to the atomic processes described there, figure out what
sequence of messages to send Amazon to order the book.

 >
 > What seems to be missing though, from this scenario is the mapping
between
 > the inputs and outputs. Namely there seems to be no relation between the
 > input, bookName and the output bookDescription.
 > Right?
 > If so, why is it the case?

You are correct on this last point, which has been a subject of intense
debate, as the DAML language does not provide primitives to do this in a
convenient way.

 > Can't the model be extended further to handle this part as well?

It will be, but we are awaiting the results of the deliberations of the
language committee.



 >
 > Can you please help me out?
 >
 > Charlie
 >
 > -----Original Message-----
 > From: Mark Burstein [mailto:burstein@bbn.com]
 > Sent: Tuesday, December 18, 2001 11:34 PM
 > To: Charlie Abela
 > Subject: Re: Process model
 >
 > I don't know if anyone responded to your question.
 > The short answer, is that the process model, at least a simple one that
 > says what the atomic processes are is
 > needed in order for an agent to determine whether the service is the
right
 > one to use. Atomic processes are essentially like operations in WSDL
 > terms. Composite processes are what one might use to interact with a more
 > complex web site, such as an amazon.com, where a sequence of messages and
 > replies is needed to buy a book.  The point is not to get inside the
 > "head" of the server, but to be able to specify multi-message dialogs
 > between clients nad servers.
 >
 >
 > Charlie Abela writes:
 >  > Hi All
 >  >
 >  > Some more questions regarding DAML-S.
 >  >
 >  > I understand the use of the Profile and Grounding ontologies but not
 > fully
 >  > that of the Process Model. The Profile and Grounding are obviously the
 >  > ontologies that an agent needs to look at for service description and
 > use,
 >  > but the Process model describes how the service works. Why would this
be
 >  > important for an agent? The provider agent's task would be that of
 >  > communicating with a requester agent and if the write inputs are
supplied
 >  > then the requester can utilize the web service.
 >  > On the industrial front looking at UDDI and WSDL, if I am not
mistaken,
 >  > there is no need for this process model. I can only see a use for the
 >  > Process model if one wants to dynamically create the web service's
code
 >  > dynamically, by generating it from the model using some form of code
 >  > generator.
 >  >
 >  > Am I missing something important...can someone shed some light in this
 >  > direction please?
 >  >
 >  > Charlie
 >  >
 >
 > --
 > *    Dr. Mark Burstein              *     Email: burstein@bbn.com
 > *
 > *    BBN Technologies               *     Phone: (617)873-3861
 > *
 > *    10 Moulton St.                 *     FAX: (617)873-4328
 > *
 > *    Cambridge, MA 02138            *
http://openmap.bbn.com/~burstein
 > *
 >
 >
 >
 >

--
*    Dr. Mark Burstein              *     Email: burstein@bbn.com
*
*    BBN Technologies               *     Phone: (617)873-3861
*
*    10 Moulton St.                 *     FAX: (617)873-4328
*
*    Cambridge, MA 02138            *     http://openmap.bbn.com/~burstein
*