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

FW: DAML-S ProcessModel

From: Charlie Abela <abcharl@keyworld.net>
Date: Tue, 3 Jun 2003 19:19:41 +0200
Message-ID: <OBEOLJNEPKKHAJJIGKDKIELACEAA.abcharl@keyworld.net>
To: <www-ws@w3.org>
Hi,

Just catching up with some maile thread about the process model as defined in DAML-S is interesting and
unfortunately there is not enough information on the DAML-S site that
describes how the composition process will be handled. I would like to
expand a bit on the middle part of the reply by Massimo to get a clearer
picture.
In particular, I am referring to this part:
>Also, during composition of web services clients need to know details on
how the web service >performs its tasks so they can integrate different
services.  For example, before spending >some money a client may want to
make sure that there is money in an account.  This requires >careful
composition of the process model of the selling Web service (which withdraw
the money >from the account) with the process model of the Web service of
the Bank that holds the account >(which tells if there is enough money).

I am assuming that a matchmaker will return to the user a list of selling
and banking services in reply to the user's query. If we are to assume an
autonomous composition of web services it is of utmost importance that
either the user or especially his agent have access to the process model of
each service so that the workflow of composed services will be defined. In
the case of the user agent, some form of reasoning in the agent will have to
identify that composition of web services is required and a process starts
with the aid of a composition engine to handle such integration. This I
would imagine will be based on two major issues, the IOPEs of each service
and also the control constructs defined in the process model.

What is still an enigma and also a bit far fetched in MHO, presuming that
the above argument is valid, is the reasoning ability of the agent required
to collaborate with the composition engine (again I am assuming that such an
engine will be available for example as a web service itself) to perform the
tasks as described above, in the correct order of execution. I would imagine
that the reasoning part should be very powerful to perform such types of
inferencing. Even if the user performs this workflow definition manually, I
would imagine that he would have to be knowledgeable about the area of web
services and all that comes with it. My assumptions also include that such a
scenario will require a solid communication framework between agent and
engine, such that the services are composed in their exact order and
execution state. The result of such a composition could be a new process
model that is generated as a result of this composition and possibly cached
for future use.

Does the argument above make sense? Am I missing something?
I would appreciate any feedback

Regards,

Charlie

-------------------------------------------------
Charlie Abela
Research Student,
Dept. of Computer Science and AI
University of Malta,
MSD06. Malta
Web: http://alphatech.mainpage.net


-----Original Message-----



All email is scanned by Keyworld against known Viruses. This service is offered to all Keyworld subscribers and hosted domains and does not carry any warranty. You are advised to protect your PC with updated antivirus software at all times.

attached mail follows:


Sent: 16 May 2003 18:53

attached mail follows:



Sudhir,

There are many reasons why a Web services may want to display its
process model.  The first one is that its clients can derive the
interaction protocol from the Process Model.  For example a book
selling Web service like Amazon allows you to browse and to reserve
the book (amazon's web service does not allow to buy right now).  so
you could have a process model that looks like
sequence(browse-atomic-process, reserve-atomic-process).  The client
at this point knows that first it has to deal with the browsing
task, then with the reserve task.  Acting differently from what the
process model require will lead to errors.

But there are other reasons.  I understand that supply chain
management depends on the providers to provide information on the
state of processing of the different orders.  Ultimately this requires
the providers to display parts of their process model.  Also, during
composition of web services clients need to know details on how the
web service performs its tasks so they can integrate different
serices.  For example, before spending some money a client may want to
make sure that there is money in an account.  This requires careful
composition of the process model of the selling Web service (which
withdraw the money from the account) with the process model of the Web
service of the Bank that holds the account (which tells if there is
enough money).

Ultimately, the DAML-S Process Model allows implementors of Web
services to display as much of the Web service they want to display.
If they do not want to display anything, they use only one atomic
process.  Minimally, they have to display enough information to allow
their clients to derive the interaction protocol, and in a way this is
what e-shops do already (amazon or orbitz ask you quite a few
questions before letting you to buy something) everything else it is
up to their business model and what they want to achieve.

I hope that this helped,

--- Massimo


Sudhir Agarwal writes:
 >
 > Dear all,
 >
 > 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?
 >
 > could someone help me?
 >
 > Thanks and regards
 >
 > Sudhir
 >
Received on Tuesday, 3 June 2003 13:16:36 GMT

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