DANIEL H. WAGNER ASSOCIATES, INC

A Leader in Applying Mathematics and Computer Science to Industry

 

Operations Research - Mathematics - Software Development

Home

About Us

Technology

Projects

Products

Careers

Contact Us

Search

You are at: Wagner Home > Technologies> Software Agents

Software Agents

Daniel H. Wagner Associates has recently been awarded seven SBIR contracts relating to software agents, Web Services, and large-scale distributed data management.  During these research projects for Army, Air Force, DARPA, OSD, and MDA programs, we have designed and developed prototype implementations of two products:  the AgentSEA™ and SOAPi Services™ .  Below, we provide some background on agents, Web Services, our patent-pending agent creation process (embodied in the AgentSEA™), and our large-scale distributed agent architecture for real-time data management (SOAPi Services™).

What Do We Mean By "Agents?"

During our initial software agent project for the Defense Advanced Research Projects Agency (DARPA) in 1999, our technical monitor, Dr. Jim Hendler, who at the time was the head of DARPA’s Information Technology Office (ITO), addressed the difficult task of defining software agents.  His definition, which we have adopted as our own, was the following:  an agent is a small, autonomous or semi-autonomous software program that performs a set of specialized functions to meet a specific set of goals, and then provides its results to a customer (e.g., human end-user, another program) in a format readily acceptable by that customer.  The goals of an agent might include providing a specific end-user or system with a specialized data stream, monitoring a database for changes to a specific table, monitoring network usage, searching the network for data relevant to a specific topic, brokering messages between agents to foster collaboration, etc.

By our definition, an agent does not necessarily contain artificial intelligence in the classic sense (e.g., neural networks, genetic algorithms), though we develop such agents to meet specific goals (e.g., genetic algorithms are particularly good for optimal route planning).  Much like a human travel, real estate, or insurance agent, the level of “intelligence” of the program doesn’t determine whether it’s an agent or not – some agents are more intelligent than others.  By autonomous, we mean that the program requires no human interaction, and by semi-autonomous we mean that it requires little human interaction.  The level of autonomy is strictly dependent on the task, and some agents may have separate threads (i.e., subprograms) with different levels of autonomy. 

For example, an agent performing search and retrieval functions for a human end-user would initially require close guidance to determine which data sources are trusted and which are to be avoided; however, once a data source is trusted by the end-user, the agent need never bother the end-user again to verify it.  Each agent also has levels of autonomy with regard to other software (e.g., GUIs, other agents), which may drive or direct the agent’s behavior through dynamic message passing (e.g., broadcast message declaring a new data source).  Our implementation of agent autonomy is well bounded, meaning that we impose very strict constraints on agent behavior, including the simple things (e.g., bandwidth usage, CPU cycles, memory, hard drive space) and the not-so-simple things (e.g., assumptions made on behalf of the end-user, locating new information sources).

What are Web Services?

Web Services are a logical extension of the component-based development (CBD) process that flourished in the 1990’s.  These architectures were designed to provide software developers with the plumbing necessary to integrate programs written in different languages and often running on different machines.  Microsoft introduced the Component Object Model (COM) for their Windows platform, and eventually expanded it to Windows networks with Distributed COM (DCOM), while the Object Management Group (OMG) introduced the Common Object Request Broker Architecture (CORBA) for any platform and network.  These architectures supported a surge in CBD theory and implementation, but their individual flaws prevented them from making as large an impact as originally envisioned.  COM was strictly for Windows, which not only restricted its usage technically, but also fueled the growing anti-Microsoft sentiment within the programming community.  CORBA provided the open architecture desired among programmers, but its complex interface language and implementation has turned off all but the most “hardcore” of developers.  In addition to their individual failings, both COM and CORBA implemented proprietary protocols that are blocked by most Internet firewalls.  This meant they had failed to reach out over the Internet to in-house but off-site locations, as well as important business partners in the emerging e-commerce enterprise market.

In order to address the complexity and networking challenges of these CBD architectures, the major players, including Microsoft and IBM, through the World Wide Web Consortium (W3C), introduced the Simple Object Access Protocol (SOAP).  SOAP is a dialect of the eXtensible Markup Language (XML) that is designed to describe content passed between programs over a network very simply.  Though the technical description of SOAP would allow it be used on any network, the first and most important binding is to the HyperText Transfer Protocol (HTTP) that carries Web packets across the Transmission Control Protocol/Internet Protocol (TCP/IP) network of the Internet.

SOAP itself provides what is called an Envelope, which consists of one or more Headers and a Body.  The Header(s) provide routing information to get the message to the right recipient(s).  The Body contains the XML message content, which may be a remote procedure call (RPC) or a simple message.  The routing instructions in the Header(s), as well as any response to be returned to the original caller, are handled by an HTTP server, commonly called a Web server, that is enabled with SOAP encoding/decoding instructions.  The Body of the SOAP message is passed by the Web server to the program(s) listed in the Header(s) that are responsible for decoding, parsing, processing, and possibly responding to the message.  This SOAP-enabled program, registered with a SOAP-enabled Web server somewhere on the network, is a Web Service.  Figure 1 shows the flow of SOAP messages between a calling program (e.g., an agent) on one machine and a Web Service (e.g., an agent exposing a legacy system) on another machine on the network.

Figure 1.  SOAP Message Flow Between Web Service Integration Agents

It is important to note that SOAP and Web Services are not meant to replace COM and CORBA, but to expose COM, CORBA, and other objects to Internet-based networks.  The jury is still out on SOAP’s performance capabilities since large-scale implementations are just now being attempted (including our current work for MDA).  SOAP’s reliance on XML as a transport language has caused many to believe that it is too bulky and slow to process.  However, new commercial products, such as Sonic Software’s eXtensible Information Server (XIS), are demonstrating the ability to quickly process large numbers of XML messages in real-time.  As research continues and more products emerge, SOAP may replace these older, more complicated protocols, but it may also remain a strictly Internet-based solution that provides a Web wrapper around existing objects.

What are SOAPi Services™?

Based on the enabling technologies of software agents, Web Services, COTS data management tools, and end-user development tools, we have designed an architecture for flexible, extensible, distributed data management services and software integration across any network.  As shown in Figure 2, the SOAPi Services™ architecture consists of 1) specialized schemas, agents and Web Services for data translation, aggregation, fusion, syndication, and visualization, 2) COTS data management tools, including a powerful XML data server, as well as existing database and storage products, 3) high-performance computing (HPC) hardware, if necessary, and 4) end-user tools for the creation of software agents and Web Services from reusable components.  The goal of the architecture is to provide a framework for plug-and-play data management and software integration that is completely appropriate to the scale of the problem.  That is, a customer with a thin data input stream and a few operational requirements would not require an HPC hardware component within their implementation of the architecture.  Depending on the amount of data, they also may not require a COTS XML data server.  Specific customers will require data fusion agents, while others want only translation, aggregation, and syndication components.  Some customers will consist of expert end-users who want to be able to modify and create new agents and Web Services from reusable components (e.g. using the AgentSEA™), while others may purchase maintenance and upgrade licenses for their specialized agents and Web Services.

Figure 2.  SOAPi Services™ Architecture

The SOAPi Services™ architecture will scale to any size, no matter how large or how small, because it is a collection of independent components combined by a single language with many dialects – XML.  Individual components communicate based on domain-specific data models, called schemas, which encapsulate the data types and relationships within highly specialized knowledge domains (e.g., environmental data, missile telemetry, sensor data).  By choosing an open, extensible standard language as the transport protocol between independent components on an open architecture, we will be able to not only provide immediate data management and systems integration solutions to provide the right customer with the right information at the right time, but will also be able to extend those solutions when components, underlying network protocols, and domain-specific schemas change in the future.


 

Home | Contact Us | Site Index | Career Opportunities

Technology | Projects | Products | Locations | Legal Notices | Search

© 2005 Daniel H. Wagner Associates, Inc.  - All rights reserved.