The agent butler is a kernel component that plays a significant role in the whole architecture, especially in the payment transaction process. In the absence of its owner, the agent butler will, depending on the authorization given, make decisions on behalf of the agent owner. When mobile agents are sent out roaming in the network, the butler has the responsibility of keeping track of agent activities and locations by sending and receiving messages with agents. This is especially important when an agent's task is important. The agent butler is necessary in all agent transactions because, in SAFER, mobile agents won't be given the authorization to carry big amount of credits.
Performance is one of the reasons for this design pattern. The agent butler can continue to perform other tasks in parallel with his mobile agents, and the local system will be organized in a clear-cut way. Another reason is that in agentbased applications, the stationary agent butler can provide a GUI for accepting data input and displaying the results of a specific task to the owner instantaneously.
In practice, the agent butler is a static Java class. There is only one object instance of it during program execution and it can be referenced universally from any of its subcomponents. It activates a graphical user interface (GUI) when the program is started. The GUI is the interface by which the user can control the agent butler. The agent butler can dispatch mobile agents to Web hosts to carry out e-/m-commerce activities. The agent dispatch module provides this functionality. The modular structure of the agent butler is shown in Figure 11.
A database object is owned by the agent butler and it stores information for the agent butler. The information includes the IP address of the host, the network port number to connect to, etc. Similar information is provided about the possible CAs that the agent butler can register with. It is assumed that, as part of the SAFER community, agents would be fabricated in a remote agent factory before being sent to the owner. Information about the agents that the agent butler currently owns would be stored in the database too. Another object that also belongs to the agent butler is the archive, which is mainly responsible for recording the past transaction information from the various e-/m-commerce transactions and SET payments.
In this payment architecture, a subsystem called agency is in place. An agency can be considered as a multilayered agent group or a federation of agents with specific goals and functional roles in the architecture. The agent butler is in charge of these subsystems, enabling each with some particular expertise. When a purchase decision is made, the agent butler will activate the financing agency to conduct transactions with the merchant host via certain payment schemes or protocols. In the current system, the financing agency owns two SET transaction objects that can carry out SET registration and purchase, respectively. Both objects ‚ RegistrationSET and PurchaseSET ‚ will be able to carry out the SET operations when they are activated. The necessary information such as the CA or remote host IP address and the payment card/purchase details would have to be passed to these SET objects.
A pair of communication objects handles external socket communications with dispatched agents. ButlerListener waits for messages or return information from agents in remote hosts while ButlerCommunicator is capable of sending messages to these agents.
Before the user or agent butler can proceed with any activities, the CA and payment gateway should be permanently running and waiting for SET transaction requests . The merchant host will carry out merchant registration with the CA as soon as it is set up and running. Only after it has completed registration and obtained SET certification will it be capable of SET purchase transactions.
The authentication module (Figure 13) starts the authentication process when the user (or agent butler) selects an agent and a host (merchant host) destination. Before the agent can be transmitted to the host, there is a prior handshaking process by which the agent butler has to identify itself to the host. The certificate from the CAC is sent along with the request message to ascertain that it is part of a trusted SAFER community. The host verifies the certificate and the digital signature on the message for authenticity and then evaluates the request. If approval is given, the agent butler proceeds to dispatch the agent to the remote host. The GUI of the authentication module is shown in Figure 12.
The mobile agent (Figure 14) that has been implemented is in the form of a Java object that extends the thread class and the serializable interface. It is thus capable of being serialized in a byte stream. This would enable the agent to be transported over existing TCP/IP networks to other machines that are capable of receiving the agent. A host machine can simply activate the agent by running it as a separate process thread. The agent can then operate independent of its originating machine, which is represented by the agent butler. The receiving machine must have special provisions to accept the agent and allow it to carry out its predefined tasks and objectives. The task of the roaming agent would be to assist in the initiation of electronic payment between the agent butler representing the owner and the host site.
Figure 14 shows the class modules that comprise the mobile agent object. In the center is the mobile agent class, which controls the rest of its components . It can be regarded as a coordination center without external functions. It contains details about the agent such as ID, date of creation, information about the originating host, etc. All these identity details arise from the need to be compatible with the SAFER architecture. This means that the agents are not just anonymous byte code flowing around but possess specific capabilities and unique identification to be residents of the SAFER communities.
The TaskList is the foreman of the agent entity, helping an agent to carry out its activities in sequence. It has a list of various objectives that has been given to the agent before dispatching it to a host. When the agent comes alive at the host, it will consult the TaskList to carry out the tasks sequentially in terms of the priority assigned. Such tasks could be as simple as giving an acknowledgement signal across the network back to its owner or as complicated as accessing the host database. If a task fails or cannot be carried out, perhaps because the network was down, the task can be delegated to a later stage and re-invoked when other tasks have been attempted.
The idea of having a TaskList is to simulate certain limited "intelligence" in the agent. Previously, it was mentioned that task orientation was one of the important characteristics of this approach. Further enhancements could be carried out in possible ways like further fine-tuning of the prescribed TaskList through parameters. This would require the parameters given to be quantified so that the TaskList can be adjusted based on the values given. A combination of varying parameters may then be used to achieve a greater degree of change.
The agent has a communications module that allows the agent to communicate with the agent butler or other SAFER community entities. The communication method is through network socket communication based on TCP/IP. The agent communicator object establishes a socket link with an external communication entity and then transmits the information as a message object. The agent listener listens at a specific port for an external connection request to initiate mutual messaging.
When the agent reaches the host, it will be activated by the host who calls the agent's run method. If the host decides to terminate the operations of the agent for any reason, it can call the agent's destroy method. In this way, the host can ensure its own security by having full control over the agent.
The activated agent can carry out a variety of predefined tasks while it is alive. It can communicate with the agent butler, access local product databases, process obtained information, or return to the agent butler according to its TaskList. Every task would have an assigned priority and the required task parameters. For example, if the next task is to contact another agent, the ID and address of the other agent would be available. The TaskList (Figure 14) object is created and input by the agent butler to the agent before dispatch. The agent attempts to fulfil every task in a sequential manner.
The flexibility of such an approach is that different types of tasks can be created by the agent butler. The parameters of a type of task can be varied according to need. The delegation of tasks by the agent butler or the user is currently done manually. This is certainly not practical in a real-world situation. For future work, this process should be automated. A scalable solution would be to define different sets of tasks for different agent types; each task is specified based on some prespecified subtasks in a finer-grain level.
One of the primary possible tasks of an agent within the SAFER framework would be to roam to remote retailer host sites. This would allow the agent to carry out information gathering and processing of this information. For example, an agent that has roamed to a shopping Web site would be able to access the local database using its information processor module. This module uses Java's database interfacing tool JDBC to link and extract data from any database whose database driver is supported. The database used for the demonstration program is Microsoft's Access database and the driver used is the default driver, Sun's ODBC to JDBC bridge driver.
After the information from the local database has been successfully retrieved, the agent can carry out further processing on the data. Assuming, for example, if the data is regarding products and their corresponding prices, the agent can then attempt to match the product (using any obtained descriptions) with a shopping list that has been set by the agent butler. When product matches are obtained, the prices of the matched products could then be analysed to find out if the price range is acceptable to the owner.
The merchant host (Figure 15) represents any retailer or Web site that allows online shopping. A program is needed on the host side that specially receives and then activates an agent thread. It is a Java object called the merchant host that provides the required runtime environment for a Java mobile agent.
Like the agent butler, the host also has a set of SET objects that allow it to carry out SET transactions. The MRegistration object carries out merchant registration with a CA. The MPurchase object receives and processes a purchase request from the agent butler. The MPaymentAuthorization and the MPaymentCapture objects allow the host to do payment authorization and payment capture, respectively, with the payment gateway.
Both the CA (Figure 16) and the payment gateway are Java programs running on different machines separated from the merchant host or the agent butler. They each have server modules containing two server threads listening to different network ports. For the CA, one thread would wait to service a cardholder registration request and the other would wait for a merchant requesting to register. The payment gateway waits for either a payment authorization or a payment capture request from a host. The separate threads allow simultaneous requests to be serviced at the same time and add to the robustness of these two servers.
The cardholder and merchant certificates as well as the CA key-exchange certificate and payment gateway certificate are generated by using Keytool with the RSA public key algorithm. They are then stored into a KeyStore file. The CA upon program execution will load these certificates from a file into a Java KeyStore object. This allows the certificates to be extracted quickly and transmitted during registration. The key-exchange private key will be extracted from the KeyStore object and used for public key cryptography during SET registrations with the agent butler or host. This functionality is included in the certificate management module of the CA.
When the registration commences, the registration module is activated by the agent butler's financing agency (Figure 13). The payment card account details are used to allow the CA to authenticate the cardholder. On successful registration, the cardholder certificates are created by the CA and sent to the agent butler. These certificates are stored for later use. After successful registration, purchase transactions can be carried out by the purchase module (Figure 13). The product information received by the dispatched agents is used to select products. The selected items from different hosts are entered into a combined shopping list.
When a purchase is confirmed, the agent butler analyses the shopping list. It then simultaneously carries out SET purchase requests with all the hosts for items that have been ordered. The host(s) involved in the purchase transactions will invoke a payment authorization request to the payment gateway when payment information is received from the agent butler. It stores the returned payment capture token. The host then proceeds to conclude the purchase request with the agent butler. At a suitable time, the host will then carry out the actual payment capture with the payment gateway using the previously stored capture token.