|
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.
|
