DISCUSSION AND EVALUATION

Discussion on Design Issues

The payment module has a clearly defined interface with the agent butler through the interface module, as seen in Figure 17. This enables the payment module to be independent of the agent butler . The current SET payment module can be easily substituted for another payment module. Such a need may arise when the parties involved in a transaction opt for a different payment scheme. Major modifications or disruptions to the system can thus be avoided.

Figure 17: Payment modules in the agent butler

In addition, different payment schemes such as digital cash can easily be added into the framework as shown in Figure 18. This increases the versatility of the system.

Figure 18: Addition of another e-payment module

The implemented agent does not have functionality or authority to carry out electronic payment transactions on its own. At this stage, it is still difficult to safeguard agents dispatched to external entities. Vital payment information is thus retained in the agent butler, where it can be easily secured. All transactions are tightly controlled by the agent butler. If, in the future, a certain level of integrity and secrecy can be achieved for mobile agents, payment functions would then be incorporated into the mobile agents.

In a mature e-/m-commerce environment, users may not have the time to negotiate with individual retailers or surf the Web to locate individuals' products. Agents dispatched by the agent butler will return information about the products available online. This information will be consolidated and presented to the user , who then can interact with a single interface for all his possible shopping needs.

There may be a problem with the possible compatibility and integration of these e-/m-commerce Web sites when using agents. It is suggested that the use of an agent-based virtual marketplace could be a stopgap solution before certain protocol standards could be imposed. The virtual marketplace , also under research and considered to be an integral part of the SAFER application, would also bring with it enhanced security features.

Application to Real-World Situation

The current agent butler is implemented as an application program that provides an interface to the user. This is different from the original concept of the agent butler being a semiautonomous entity helping the agent owner to administer the agents. This is caused by the limitations in current software technology. Further development of the agent butler in future should concentrate on giving it enhanced decision-making capabilities.

The payment module uses the SET protocol for electronic payment. However, the implementation used Java socket-based object communication while SET actually requires the use of HTTP protocol for messaging. Due to the great complexity in implementing this protocol strictly to specifications, a third-party SET software solution should be used. Such solutions are available from commercial software companies such as Globeset.

The transport of the agent classed in the project implementation used the Java serializable interface. It enables the conversion of Java objects into a byte stream and automatically reconstructs the objects at the recipient end. However, the receiving host requires a template of the agent object. This complicates matters because the host needs to be specially configured to receive agents. The concept of agents moving freely cannot be achieved within the current framework. It is hoped that other transport solutions can be implemented in future to overcome this situation.

Virtual Marketplace for Agent-Based E-Commerce

The secure e-payment system has been applied in the virtual marketplace, shown in Figure 19. A marketplace is a place where buying and selling agents meet to negotiate transactions. It is important, therefore, that the architecture of the virtual marketplace is designed to facilitate interactions between agents by providing a secure and reliable environment for the conduct of electronic commerce. A business-to-consumer model has been adopted for implementation in the virtual marketplace. The architecture of the virtual marketplace can be divided into three separate elements. These are the control center, business center, and financial center. Specialist agents reside in each module and work independently as well as collaboratively with the other agents in the virtual marketplace to achieve their goals and objectives.

Figure 19: Virtual market architecture overview