Agent Based Computing

Introduction

Computer Software is a huge field and a big part of todays life. Right now there are millions of different applications available, each one providing a service and information. Even if there is sometimes good to have the applications in isolation, there is also an emerging aneed for interoperability between such applications - to exchange information or provide the service.
The main problem is heterogenity: huge number of different applications developed by different people in different technologies at different time providing different interfaces, sometimes without taking care of standards.


The other consideration is to give a direct internal or external access to the application. This can be not always secure, flexible and practical enough (for example firewalls restrictions).



In this document 2 solutions will be proposed for these problems and a comparison of them, ie.:

• Agents
• Web Services

Agent-based software engineering can be used to overcome the problem of interoperability. In such a scenario application is written as software agents that communicate between each others (exchanging messages) in an expressive agent communication lanugage (ACL)

We can incorporate Web-Service as a wrapper for given application for external exposing and taking an advanteg of making standarized SOAP calls over HTTP.




Coming back to all the programs that have already been written (legacy software).
Let's see the techniques for converting such applications into software agents.



One approach is to implement a "transducer" that is a mediator between an existing program and other agents. The transducer accepts messages from other agents, translates them into the program's native communication protocol, and passes those messages to the program. It accepts the program's responses, translates into ACL, and sends the resulting messages on to other agents.
This approach has the advantage that it requires no knowledge of the program other than its communication behavior. It is, therefore, especially useful for situations in which the code for the program is unavailable or too delicate to modify.
This approach also works for other types of resources, such as files and people. It is a simple matter to write a program to read or modify an existing file with a specialized format and thereby provide access to that file via ACL. Similarly, it is possible to provide a graphical user interface for a person that allows that person to interact with the system in a specialized graphical language, which is then converted into ACL, and vice versa.

A second approach to dealing with legacy software is to implement a wrapper, i.e. inject code into a program to allow it to communicate in ACL. The wrapper can directly examine the data structures of the program and can modify those data structures. Furthermore, it may be possible to inject calls out of the program so that it can take advantage of externally available information and services. This approach has the advantage of greater efficiency than the transduction approach, since there is less serial communication. It also works for cases where there is no interprocess communication ability in the original program. However, it requires that the code for the program be available.

The third and most drastic approach to dealing with legacy software is to rewrite the original program. The advantage of this approach is that it may be possible to enhance its efficiency or capability beyond what would be possible in either the transduction or wrapping approaches. The best examples of this approach come from the engineering domain. Many automated design programs work to completion before communicating with other programs. For example, the output of a logic synthesis program is passed as input to a printed circuit board layout and routing program; its output is passed to an assembly planning program; and so forth. Recent work in concurrent engineering suggests that there is much advantage to be gained by writing programs that communicate partial results in the course of their activity and that accept partial results and feedback from other programs. By communicating a partial result and getting early feedback, a program can save work on what may turn out to be an unworkable alternative.

In this project we will consider wrapper approach. And compare two solutions - Agents vs. Web Service wrappers for SMTP Server.

Results of the project

WebService / Agent wrappers can bring a lot of benefits to current SMTP Server.
Security improvement is huge comparing to the current SMTP communication. WebService / Agent using SSL guarantees the security of authentication infromation as well as the message content which cannot be intercepted nor manipulated like in case of current SMTP communication.

The other huge improvement with respect to performance and network communication is the extended functionality of MailTemplate messaging that wrappers can expose from the current simple SMTP protocol.

More detailed results descriptions one can find in the Research Paper in download section.