Re: Automatic Web Service Composition

> [Yuji Sakata]
>  I think AI  has achieved great success in planning. But it looks like 
> practical use of AI planning is not spread as a method  for composing 
> program or component. (Sorry if just a shortage of my knowledge)

AI has in a sense achieved "great success."  There are several
algorithms developed in the last decade that produce much bigger plans
from bigger domain descriptions than was possible before.  However,
these domains are quite artificial.  They suffer from the usual
classical-planning limitations that Jim Hendler has outlined, but also
from severe weakness in what one might call "diagrammatic" as opposed
to "logical" reasoning.  A key feature of all such algorithms is the
ability to reason backward from a goal to actions that could achieve
it, and their preconditions, which become subgoals.  This "regression"
process is easy for actions described using Strips (or its descendant
PDDL), but much harder for actions described as actions on objects
described geometrically.  Most realistic domains have involved some
amount of geometry, so that AI planning has been of little use

> Experts in Semantic Web Services ML look like conclude that AI planning 
> will be useful  for composing web services.
> 
>  Please teach me what are the characteristics  of web services which  
> practically enable  AI planning to compose a service process, though it 
> is fairy difficult to compose programs or components to achieve a 
> requirement.

The beauty of web services is that it is one of the few practical
domains in which geometry really doesn't matter.  Numbers do, but
ordinary arithmetic reasoning can be assimilated into PDDL without
many problems.  Unfortunately, while AI planning benefits from this
feature of the web-service problem, it has to overcome all those other
limitations (no perfect knowledge, and the need for contingent and
partial planning).  So once again AI planning is still mainly in the
theory stage, but at least it hasn't failed yet.

>  In my humble opinion, 
>   1.  higher abstraction of the functionality of service than primitive 
> codes or components.
>   2. useful standards are fixed like XML, SOAP, WSDL,RDF..., though 
> previous program language are components are both proprietary.
>   3. 'just' increasing actual requirements for dynamic service composing 
> in the intra/internet, which are motivated from a decentralized  
> services environment. There was no need for run-time composition and was 
> just a need for design-time composition.
>   
>   I think "1" is the most important characteristic.

I'm not sure I understand what 1, 2, and 3 are.

-- 
                                             -- Drew McDermott
                                                Yale University CS Dept.

Received on Monday, 2 February 2004 15:11:35 UTC