 |
 |
 |
 |
| |
|||||
|
|
 |
Many MITRE sponsors are migrating various legacy applications to a Web-centric architecture, a design in widespread commercial use today. This type of architecture involves a multi-tier server system. Software that encapsulates the business logic resides on a server tier. Clients can be Web browsers or specialty applications, such as a map client. Enterprise Application Integration products, application servers, and portal products typically have this type of architecture. An alternative architecture, the software agent framework, has emerged from laboratories and into the commercial domain. The software agent architecture arose out of advances in several technology areas, including distributed artificial intelligence, software component technologies, and human-computer interaction. With all of these contributing areas, it is understandable that multiple definitions for “software agent” arose. A core set of attributes that compose a software agent is now accepted, with different software agent types having additional attributes. Agent types include the personal assistant agent, the human avatar agent, and the mobile agent. Due to emphasis on attributes of asynchronous communications, cooperation, and coordination, agents bring flexibility to system design and offer loose coupling alternatives for system interoperation. In the future, we expect applications to be developed to work with agent systems or to be developed in an agent framework. If this occurs, most organizations that have already ported selected applications to the Web-centric architecture face another round of decisions about migration, this time to software agent frameworks. Will they find that the latest commercial software they would like to incorporate into their Web-architecture system is agent-based? How will they use this new software efficiently? To answer these questions, a MITRE project is examining potential interoperabilities, synergies, and conflicts between applications in the Web-centric architecture and software agent systems. Initially, we focused on the role that messaging-a key element of distributed computing-plays in promoting interoperability between the two frameworks. We did so by developing a multi-agent system to address one aspect of the interoperability problem: that of a Web client receiving information produced in the software agent framework. In our demonstration system, the product is a Weather Note; it is offered to clients of the Web-based architecture via enterprise-level asynchronous messaging. We are using the Java 2 Enterprise Edition (J2EE(tm)) platform as the Web-centric architecture exemplar and the Foundation for Intelligent Physical Agents Open Source (FIPA-OS) agent development environment as the representative software agent framework. Open source versions of both platforms are available. The J2EE is based on open specifications, whereas the FIPA-OS platform is based on standards set by FIPA. Open standards enabled us to compare relevant specifications across frameworks and make initial assessments prior to starting development. They also allow users to avoid vendor lock-in. Open source code permits code inspection for purposes of assessment and modification. J2EE PlatformIn the J2EE architecture the bulk of computations is done on the server rather than on the user’s computer. The multiple layers, or tiers, of the architecture promote flexibility and reusability because developers need only modify or add a particular layer, rather than rewrite an entire application if the underlying technology changes. The J2EE platform comprises several technologies as well as the application client and applets in the client tier. It includes container technology-essentially middleware that provides system-level services to the components in a container. The J2EE platform also includes application programmer interfaces. One of these, the Java Message Service (JMS), supports asynchronous messaging. Our project made use of JMS to facilitate interoperability. Software Agent Systems
As the illustration above shows, our demonstration system incorporates four software agents. There isno fixed client-server arrangement, nor does one agent direct the actions of all other agents. The Weather Service Agent “wraps” the weather feed, which contains two reports important to aviation: meteorological aviation reports and terminal aerodrome forecasts. From this raw weather information it creates an intermediate product, the Aviation Weather Report, which it then stores internally. The Weather Watcher Agent organizes Aviation Weather Reports along a geographical and time-ordered scheme and provides quick retrieval of these reports for agents that ask for them. The Weather Reasoner Agent must decide if a Weather Note-such as “Fog at Airport XYZ”-is warranted. It uses the Aviation Weather Reports as input to its decision-making process. Once the Weather Reasoner Agent has issued a Weather Note, it needs to communicate it to clients. However, the clients are outside of the multi-agent system; they are actually clients of the J2EE system, residing in its client tier, who would like to receive the Weather Note product. The Weather Reasoner Agent uses the JMS Comms Agent to send the Weather Notes to them. Communication among agents does not simply involve message passing, but is instead a conversation, made up of a series of messages. For example, if the Weather Watcher Agent is to organize the Aviation Weather Reports, it must first request them from the Weather Service Agent. This request conversation involves a minimum of three messages. Message MappingIf the demonstration system were a robust commercial product, one goal would be to provide the Weather Note to as many clients as possible. How- ever, many J2EE clients would encounter a semantic mismatch with the software agents, and would be unable to communicate. Moreover, the client base would be limited if all clients were required to speak “agent-language” and participate in conversations. If the JMS Comms Agent could take the conversational messages from the Weather Reasoner Agent, extract the Weather Note information, and then construct and forward a message that could be used in an enterprise messaging system, clients of the enterprise messaging system could receive the product. Our prototype system demonstrated how to achieve this. We created mappings between FIPA messages and JMS messages (as shown below), and then instantiated the mappings in software as the JMS Comms Agent. This agent serves as the bridge between the FIPA-compliant multi-agent system and clients of the J2EE/JMS platform.
Our particular client, a map display client, subscribes to a “fipa-weather” channel using JMS. The Weather Notes appear whenever a user drills down on an airport location. Currently, the notes can be read in text form, easily displayed as map pop-ups. It would be straightforward, however, to put them in XML format, which would facilitate having software programs process the information. We are now investigating how software agents work in the Web services realm. For more information, please contact Margaret Lyell using the employee directory. |
Solutions That Make a Difference.® |
|
|
