Conversation-enabled Web Services for Agents and e- Business James E. Hanson, Prabir Nandi, David W. Levine IBM T.J. Watson Research Center P.O. Box 704, Yorktown Heights, NY 10598 { jehanson | prabir | dwl } @us.ibm.com Abstract: In this article we outline some enhancements to the existing Web Services architecture and programming model, which will enable them to support the needs of fully-realized dynamic e-business and software agents—which have much in common. Of particular importance is conversation support, with its core element, conversation policies. 1. Introduction The emergence and continued development of Web Services has brought them to the brink of supporting rich e-business applications. The simplified invocation model afforded by SOAP[1], the standardized, public description of invocation syntax provided by WSDL and UDDI, and the encapsulation of detailed message-transport plumbing behind a standard invocation framework (WSIF) all are essential stepping- stones toward full support of e-business interactions. But at present, Web Services remain a “vending machine” model—that is, they provide a way in which functions can be made available for invocation over the internet. Rich e-business interactions require a more loosely-coupled, peer-to-peer, dynamic, proactive mode of interaction. A fully realized e-business acts as both the “invoker” and “invokee” in two-sided (or multi- sided), multi-step, complex patterns of interaction with other e-businesses. Its internal business processes are under its unilateral control, both as to what to do in any given interaction, and when and how to make changes; while its interactions with other businesses are mediated by public (or at least commonly held) protocols. Even in cases where there is an agreement in place, the business retains control over the extent to which it follows the agreement. Interacting software agents correspond almost exactly with the above description. In terms of how they interact, differences between agents and fully-realized e-business are largely a matter of scale and emphasis. But from a Web Services architectural standpoint, they are synonymous. Consider the following scenarios: • EB1, an e-business, contacts another e-business, EB2, about purchasing supplies. EB2 replies that the supplies are currently up for auction, and offers to include EB1 among the bidders. EB2 names the auction protocol in use. EB1 checks whether it has the business process logic to support that protocol; it does; so it agrees to participate. EB1 then engages in the auction. It bids, but does not win. It then contacts another e-business, EB3; finds that the goods are available, either at auction or via one-on-one negotiation over price, quantity, and delivery time. EB1, as a result of having lost the previous auction, opts for the negotiation. EB1 and EB3 exchange offers & counteroffers, eventually arriving at a deal. Then they exchange payment and delivery information, confirmation numbers, and so forth. • Agent1 contacts Agent2 about renting a car. They engage in a dialogue about Agent1’s preferences, Agent2’s inventory, and so forth. For protocol, they agree to use a modified ACL (Agent Communication Language), in which each message contains one of a half-dozen standard performatives to identify the intent of message, and message contents follow a standard car-rental