W3C home > Mailing lists > Public > public-sws-ig@w3.org > July 2006

Re: agents

From: Terry Payne <trp@ecs.soton.ac.uk>
Date: Tue, 25 Jul 2006 10:09:11 +0200
Message-Id: <8DF9B6E4-8B1D-4F8B-8046-25BB045FD74D@ecs.soton.ac.uk>
Cc: Mark Burstein <burstein@bbn.com>, jpsequeira@netvisao.pt, public-sws-ig@w3.org
To: "Xuan Shi" <Xuan.Shi@mail.wvu.edu>

On 24 Jul 2006, at 20:11, Xuan Shi wrote:

> Once a service provider publishes a service, how can the provider know
> which, whether, and how service requester will consume this  
> service? ...

It doesn't know.  It can't!

> ... A
> service provider does NOT know whether the requester will only consume
> this single service or will consume this service with many other
> services. So how can you prescribe a process.owl file for your service
> requesters when you develop a service?

There are few, if any assumptions you can make about the requesters who
will consider, and consequently consume your service.  All you can do is
represent the service such that a requester then has sufficient  
detail to be
able to utilize the service, without a priori information about the  
service instance in question (by a priori, I mean that the  
implementation of
the requester does not assume any knowledge of the providers service,  
the only knowledge available is that in the OWL-S declarations).

> Just as you said, "The OWL-S files are intended to be consumed by  
> client", how can service providers determine and control whether this
> specific service can be used in whatever process model on the
> client-side? For example, how can a rental car service provider know
> whether or nor this service will be consumed by a service requester  
> who
> will just want to find a rental car, or who will also want to book an
> airline ticket, or more want to reserve a hotel, and more want to  
> get a
> ticket packet for Disney World?

Some of these are good questions that need to be addressed.  However,  
should assume that a service is an encapsulated entity, that can be  
used in
isolation, as well as composed / aggregated by some third party.

> The process.owl tries to describe or mimic the client-side activity  
> for
> a specific service requester. How a service provider can model or
> imagine all possible client-side behaviors? Service
> integration/aggregation is not the business of service provider.

It can't model all client-side behaviors per sey, but model a set of
permissible client-side behaviors that a client could use to access
the service.

> As for service requesters (i.e. application developers who integrate 1
> or many services together to serve the end-users), is it necessary to
> have such a process model? Then please see the following question:

Yes.  Look, don't make the mistake of thinking that the OWL-S model  
is simply
provided to some back-room programmer who is writing code to aggregate
services.  Sure, SWS, along with appropriate tools can greatly  
facilitate the
development of applications constructed from composed services, or via
higher level workbenches (such as the myGrid Taverna workbench used
by bioinformatitcans) for users who need simple tools for workflow  
But OWL-S was also designed (and originally motivated) to support  
utilization of services by intelligent Agents; i.e. where there is no  
at all in the loop.  In this case, one needs a detailed, knowledge- 
rich model...

> Whom do you want to present such a "process model"?
> --1. To the service provider? The provider does not care about and
> control how requesters integrate the service for whatever purpose. As
> for provider in this case, if the preconditions are satisfied, it will
> invoke the service and return the result to you otherwise fail.
> --2. Or do you want to present the process model to yourself - service
> requester? It's strange as you know what you are doing (You may be
> wondering why you show it to yourself).
> --3. Or do you want to show the model to your client - the end-user?
> It's ridiculous as I said before - the end-users (they may not be CS
> professionals) are waiting for a result, not the process details of  
> how
> you hire subcontractors and how your subconstractors accomplish the  
> task
> for you.

Process models can be used for a number of reasons.  For example, a
service provider may model *many* processes, and through planning,
or perhaps a tool used by the providers human owner to configure
the offered services, to assemble a set of legitemate processes that can
then be published.

A more important issue is the one raised in point 3 - it might be  
essential for
a client to know whether or not the provider delegates part of the  
process to
a third party.  For example, my agent may be prepared to trust your  
but not the third party you use to validate my credit card details.   
By being able
to inspect the process model, my agent can determine if it should use  
your service!

The bottom line is that if you're looking at sws purely from a  
programmer perspective,
then it can come over as heavy weight.  But if you consider wider  
issues of distributed
computing, and especially those issues that have been addressed by  
the Distributed AI
and Multi-Agent system community for the last twenty years, then many  
of the motivations
behind OWL-S make much more sense!


> So, why they must be available on the web?
>>>> Mark Burstein <burstein@bbn.com> 07/24/06 11:21 AM >>>
> ......
> The process model must provide precise
> semantic correlates for all inputs and outputs that are possible in
> the WSDL messages that they correspond to, and must link these data
> to the corresponding preconditions and effects so that a service
> requester can mechanically determine whether and how it will provide
> the correct inputs and interpret the resulting outputs.
> ......
> The OWL-S files are intended to be consumed by OWL-S client agents
> that are then able to call the described services. So they must be
> available on the web.

Terry R. Payne, PhD.        | http://www.ecs.soton.ac.uk/~trp/index.html
AgentLink III Co-coordinator    | AgentLink III - http:// 
University of Southampton    | Voice: +44(0)23 8059 8343 [Fax: 8059  
Southampton, SO17 1BJ, UK | Email: terry@acm.org / trp@ecs.soton.ac.uk
Received on Tuesday, 25 July 2006 08:09:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:56 UTC