CHAPTER 4

DESIGN & IMPLEMENTATION

43
4.1 DESIGN
SIRS is designed using the object-oriented paradigm because the concept of objects is useful to
describe agents. There are five main types of objects in the system, namely MobileAgents,
Http Server, Launch Server, Merchant Host Servers as well as the client program. We
describe the object details and control flow of the system in this subsection.
4.1.1. Object Description
I, The MobileAgent object: it keeps a list of products and a list of corresponding quantities
specified by users. It is responsible for traveling around the network and collect product
information for users from different hosts. It also keeps an itinerary; it travels through the
network according to the order of hosts in its itinerary. Whenever an mobile agent arrives at a
host, it retrieves data from it and appends the retrieved data to a list of product entries. It is also
responsible for calculating the purchasing combination that is lowest in price.
II, The Http Server object: it is responsible for maintaining user’s personal details, login and
passwords to validate the user and to collect user’s requests for information retrieval of
selected products along with their quantities. It maintains the list of merchant hosts for each of
the product specified under individual category. It forward the user’s request by concateing the
list of merchant hosts required to visit by mobile agent for information retrieval with list of
selected products, to Launch server, for initializing mobile agents and later to receive the
retrieved information from Launch server to display the results for user.
III, The Launch Server object: it is responsible for creating mobile agents for users, sending
the mobile agents to the network, and receiving the mobile agents when they finish visiting all
the hosts specified in their itineraries. It provides a gateway between client programs and the
agent environment.
IV, The Merchant Host Server object: it stores the information of products available at a
particular host (each host has its own instance of this object), and is responsible for retrieving
required information for the mobile agent when it arrives at the host. It can receive incoming
mobile agents, and executes the codes of the received agents. After executed the request of an
incoming mobile agent, it sends the agent to the next host.
V, The Client Program: it is a Java Applet. It lets users to choose the products and the
corresponding quantities. Each instance of the client program can communicate with the Http
server in order to retrieve product price and availability information from electronic market

44
place and receive results reported by mobile agents. It is a multi-threaded application, therefore
it enables users to send out several queries at simultaneously.
4.1.2. Mobile Agent Migration in SIAS: The typical behavior of a mobile agent is to migrate
from one agency to another. During the process of migration, the current agency is called
sender agency and the other agency is called the receiver agency. During the migration process
the sender and the receiver must communicate over the network and exchange the data about
the agent that wants to migrate. Thus we can say some kind of communication protocol is
driven, and we call this the migration protocol.

Sender Receiver

Transfer the agent Start agent execution

Capture Data and State Deserialize the agent

Initialize Migration Process Receive the agent

Network

Fig:9 The mobile agent migration process

The whole migration process contains six steps, which are executed in sequence. The first three
steps are executed on sender agency and last three steps are executed on receiver agency:
Initialize the migration process and suspend the thread: The process of migration typically
starts with a special command, the migration command, by which agent announces its intention
to migrate to another agency, whose name is given as parameter of the migration command.
The first task for the agency is now to suspend the execution thread of the agent and to
guarantee that no other child thread is still alive. This requirement is important for the next
step, for which it is imperative that data and state be frozen and unable to be modified later on.
Capture the agent’s data and execution state: The current state of all variables of the agent is
serialized; that is, their current values are written to an external persistent representation, for

45
example, a memory block or a file. The agent’s state is also stored there so that the point of
suspension is known. The result of the serialization process is the serialized agent, which is a
flat byte stream that consists of the agent’s data and state information.
Transfer the agent: The serialized agent is transferred to the receiver agency using a migration
protocol. Whether any code is sent to the receiver agency depends on different parameters and
will be discussed later
Receive the agent: The serialized agent is received using the migration protocol. The receiver
agency checks whether the agent can be accepted based on information about the agent’s
owner and the sender agency. The receiver agency may filter out agents that come from
agencies that are unknown or not trusted.
Deserialize the agent: The serialized agent is deserialized; that is, the variables and execution
state are restored from the serialized agent. The result of this step should be an exact copy of
the agent that existed on the sender agency just before reaching the migration command.
Start agent execution in a new thread: The receiver agency resumes the agent execution by
starting a new thread of control. When resuming execution, the agent code is needed which is
transferred to the receiver agency by sender agency.
4.1.3. Security design in SIAS:
SIAS is a web-based system, attacks from the Web to the system are likely, and security is an
important issue of the system design. Moreover, system security is of crucial importance to
applications in an electronic marketplace, where money transaction is concerned. This
subsection describes the security challenges of SIAS, and presents a simple but original
approach to solve the problems.
4.1.3.1 Security Requirements/Solutions in SIAS:
SIAS is a mobile agent system, due to the autonomy of agents is subject to all kinds of attacks.
Mobile agent security is usually divided into two aspects: host security and agent security. Host
security deals with the protection of hosts against malicious agents or other hosts; while agent
security deals with the protection of agents against malicious hosts or other agents.
Both host security and agent security would be issues of SIAS. However, since we have built
SIAS using the Java programming language, which provides strong security mechanisms to
protect hosts against malicious programs or agents through the use of Java Virtual Machine
(JVM), host security problem is very much simplified and solved.

46
In order to protect the agent server and the underlying host from malicious agents, we have
activated the sandbox security model of Java . With that we can guarantee (as long as Java can
guarantee it), that no mobile agent has the permission to read or write to the local file system,
open insecure network connections, etc. The Tracy security models is built upon the concept of
a home platform. Mobile agent servers can grant specific permissions to agents only to the
home platform they were created. It is not possible to grant permissions to a specific agent
only.
4.1.4. Service Oriented Architecture in SIAS: SIAS is a modular, component-oriented, and
extendable software system. It provides the flexibility for developer to implement different
concepts and add new features. The whole application is divided in to five modules and each
module is developed as an individual application. For maintaining loose coupling between the
applications, the interoperability issue arises at the time of integration of these modules. This
pattern is called as ‘Service Oriented Architecture’(SOA). The concept of an SOA is not new.
Service-oriented architectures have been used for years. Examples of earlier SOA systems are:
Java RMI : Java Remote Method Invocation, CORBA : Common Object Request Broker
Architecture, DCE : The Open Group Distributed Computing Environment, DCOM:
Microsoft Distributed Component Object Model. However what is relatively new is the
emergence of web services-based SOAs.
4.1.4.1 Web Services in SIAS: A definition of a web service provided by W3C working
group is “ A web service is a software system designed to support interoperable machine to
machine interaction over a network it has a interface described in a machine processable
format ( specially WSDL) other system interact with the web service in a manner prescribed by
its description using SOAP messages, typically conveyed using HTTP with an XML
serialization in conjunction with other web related standards”
Simple Object Access Protocol is a XML standard for use in invoking remote methods
exposed by web service on web server. SOAP is message format passed between web service
and its consumers. In typical scenario client send XML formatted message to server to obtain
service and in response it gets XML formatted response message. This means that any client
capable of parsing XML message can be web service consumer. SOAP specifications describes
how these XML formatted request-response must look like.Messages sent by SOAP have a
better structure than other internet protocols and can encapsulate very complex information.

47
SOAP messages are well defined XML messages. SOAP standard prescripts only how clients
will communicate with services not how methods them self should be implemented. SOAP acts
as neutral protocol for clients and servers written in different languages and on different
systems.SOAP messages can be one of three types:1.Method call 2.Response message 3. Fault
message
All SOAP messages are encapsulated with in an ENVELOPE element and follow the same
format. Inside this element, there will be always a single body element. Optionally Envelope
can have a single header element, but if so, it has to be first element in envelop. There can be
additional user defined elements in SOAP message must be qualified by a namespace
4.1.4.2 Web service Architecture: XML is a key technology used in a web services in
addition with SOAP protocols. A web service to be viable has to satisfy some other standards
which are:
• Web Service Description: Service description is key with in a service oriented
architecture. A service description is involved in each of three operations of SOA:
publish, find and bind. The service provider uses a service description to tell the service
requestor everything it needs to know in order to properly understand how to invoke the
web service. Every web service has a description of method calls, message formats,
data types, transport protocols etc. This description is usually written in web service
description language (WSDL). This specification is formatted so it can be read and
understand by a computer so in the future so in the future it could be possible to write
application that will be able to find a web service autonomous, to read WSD document,
and implement web service methods. All description are done in XML.All WSDL
constructs are children of <definitions> element. With in this element are embedded
all information that provide description of web service:
- <types> definition of data types used
- <messages> abstract type definition of data being exchanged
- <operation>abstract description of an action supported by the service
- <porttype> abstract set of operations supported
- <binding> concrete protocol and data format specification for a particular port
type
- <service> a collection of network end points-ports.

48
 - <port> describes the protocol and data format to be used as well the network of
where clients can bind to the service.
• Web Service Discovery: In order to be used a web service has to be found.This can be
done manually at the design time of a client that uses a web service by simply
specifying the web address of a service. A scenario in which client wishes to connect
and to interact with a service and does not know what services it wishes to engage it is
necessary for that client to “discover” a suitable candidate.
Discovery is the act of locating a machine processable description of a web service that
may have been previously unknown and that meets certain functional criteria.
There are three views on how the discovery service should be considered:
I. Registry is considered an authoritative, centrally controlled store of information. In
this approach a web service provider must place the information to registry before
making it available to others. Registry owner makes decisions about informations that
are placed on the registry.
UDDI ( universal description, Discovery and Integration) is often seen as an example of
this approach. UDDI acts as a central repository of available web services. Applications
and developers can access the UDDI registry to learn what web services are available
on internet (http://www.uddi.org/)
II. Index is considered a guide to information that exits elsewhere. It is not
authoritative. Anyone can create their own indexes. An example of this is DISCO
(Discovery Protocol)
This acts as a pointer to all web services located on a particular website, and any web
site( web site administrator) creates its own DISCO.
III. Peer to peer system enables services to discover each other dynamically without
use of a registry or index. A web service is a node in a network of peers which may or
may not be web services. A client in discovery times queries these nodes in search for a
suitable web service. If one of them matches the request, it replies, otherwise each
query propagates through the network.

49
4.1.5 SIAS Architecture

Fig:8 Architecture of Shopping Information Retrieval System

Explanation of Steps:
1.Client program launches a request for information retrieval of selected products from
merchant hosts in the network to the Http server object
2.Http server locates the desired service interface of Launch server from the network and
launches a request to Launch server
3. Launch server creates an agent object and initializes the agent with client specified products
and corresponding quantities, as well as the itinerary and sends the mobile agent to the network
4. Mobile agent visit the Merchant host #1 as specified in its itinerary and interact with the
underlying database for retrieving required information for the client specified product list and
migrate for next merchant host

50
5. Mobile agent visit the next Merchant host #2 as specified in its itinerary and interact with the
underlying database for retrieving required information for the client specified product list and
migrate for next merchant host
6.Mobile agent reaches at the last Merchant host #N as specified in its itinerary and interact
with the underlying database for retrieving required information for the client specified product
list and migrate to Launch server
7.Launch server receives the returning mobile agent and collect the retrieved information from
mobile agent and pass it on to the http server through its service interface
8.http server receive the retrieved information and calculates the cheapest price and reports the
result to the client program
9.Client program display the search result for the user.

4.1.6. Tracy Mobile Agent Middleware: Tracy Mobile Agent System provides the
framework for mobile agents to navigate and communicate via the network, Tracy is a
modular, component-oriented, and extendable software system that executes mobile and
stationery software agents written in the Java programming language . It contains all
fundamental features to support a mobile agent and provides the flexibility for agent
developers to implement different concepts and add new features. Tracy as middleware
architecture supports the migration of mobile agent’s code, data and execution state between
hosts in heterogeneous networks with the aim to complement more traditional distributed
architectures. Tracy supports a weak form of (optimized) agent migration in a network of agent
servers and implements local message passing between agents. Derived from a concise
evaluation of requirements, mostly targeted towards e-commerce and intranet applications.
4.1.6.1 Overview: Tracy is a powerful platform for implementing agent based solutions. It
was developed at the Friedrich Schiller University of Jena by P. Braun, J. Eismann and C.
Erfurth. It distinguishes between trusted stationary agents that have permission to access the
local file system or open network connections, and untrusted mobile agents, which do not have
these rights. One of the main issues Tracy’s developers were faced with is the research and
evaluation of general agent mobility and the various possible migration strategies. An agent
server is a host environment agents can live in. Typically, talking of a mobile agent system, we
understand a whole framework of distinct agent servers mutually knowing about and somehow

51
connected with each other. Thereby, it is possible for mobile agents to jump from one server to
another familiar one, and, after completing their job, to turn back to their home platform.
From a Tracy-based agent server’s view, there are two types of agents:
AGENTS

STATIONERY MOBILE

SYSTEM GATEWAY

Fig:11 Types of Agents

· System Agent: a stationary agent eternally bound to a particular agent server. It is capable of
accessing the host’s file and operating systems. Its main purpose is to welcome mobile agents,
which enter the server, and offer its service(s). For instance, in the shopping situation described
in section 4, a System Agent would have been used to implement access to the vendor’s
product database.
· Gateway Agent: also a stationary agent, used for communication with custom applications
located outside the Tracy server
· Mobile Agent: this agent type has the ability to move between different agent servers,
but, in contrast to the other two types, it does not have any rights to access neither the host
operation and file systems (except on his home platform) nor any external legacy applications.
This is a security consideration: mobile agents are assumed to be untrusted peace of software
because of their ability to migrate.
4.1.6.2 Tracy Infrastructure: The Tracy infrastructure consists of several platforms, on each
running one or more Tracy agent servers, which create the environment for running several
kinds of agents and offer services for receiving and sending mobile agents over the network.
Each agent server is independent from the other, even though they are able to communicate
with each other as in a peer-to-peer network. The architecture of the Tracy system is, therefore,
the many times repeated architecture of the agent server that consists of Kernel, agency and
plugins

52
 Fig:12 Architecture of Tracy Agent Server

The agent server sits on top of a Java Virtual Machine, which is itself based on top of an
operating system. On top of a Tracy agent server there can be one or many applications that
use it to host application-specific agents. It is not necessary that there is a permanent
connection between application and agent server. An application can start an agent server
temporarily to launch agents that immediately migrate to another server. In the same way, it is
possible that an application only connects occasionally to a running agent server, e. g. to check
whether new agents have arrived. If there is no application connected to the agent server, then
the agent server must be able to offer services on its own. An agent server has a unique name,
which is the concatenation of the host name and the logical agent server name.
The Tracy Kernel:The kernel of Tracy is further distinguished into a micro kernel and the
agent and service management component (ASM) and consists in total only of about 1500 lines
of code. The micro kernel mainly consists of an implementation of a thread pool. The ASM
component is responsible to maintain a directory of all agents and service components. It
communicates with the micro kernel in order to execute agents and is also responsible to
initiate the start of service components, which are named plugins in Tracy as they can be
started and stopped dynamically during runtime.

53
Plugins: A plugin is a software component that provides a high level service that is not
mandatory to run an agency, but extends its functionality .Plugins can be added dynamically to
a running agency, they can be stopped and restarted later. In fact the basic version of tracy only
consists of the microkernel and the agency. All other services, such as inter agent
communication, migration, partial solutions of mobile agent security challenges are all
implemented as plugins. if we do not need a specific plugin as part of application domain, one
can just remove it and , thereby reduce the memory footprints of an agency .the main
advantage of this type of architecture is that the user can extend and improve tracy simply by
developing its own plugins .Tracy comes with the following plugins :place, migration,
communication, domain service, naming, logger
4.1.7. Glue Internet Middleware
4.1.7.1 Overview :
GLUE is an easy-to-use, fast, comprehensive platform for creating and deploying applications
with web services, JSPs and servlets. It is the result of uncompromising desire for simplicity,
and allows industrial-strength web services applications to be built in the true spirit of Java.
There are three editions of Glue, and all but the Standard edition are available for mainframes.
• Standard: unsupported and free for most academic and commercial uses, intended for
prototyping and low budget projects
• Professional: business-class platform, intended for serious, high-performance
deployment
• Enterprise: adds clustering of servlets, JSPs and plain Java objects, avoiding the
complexity of EJB
We are using Glue instead of an open source alternative like Apache Axis because Glue is one
of the most respected, solid and easy to use SOAP frameworks, and considering there is a free
version, we think it is a viable option for serious SOAP development. It is very easy to
integrate Glue services with the any servlet engine and component-based applications, and the
Glue SOAP implementation is quite capable of supporting application's most used data objects,
like the disconnected Record set, in fact this class can be used as a return type or as an
argument type for a published web service, as long as the framework JAR is present on the
client side as well as on the server side.

54
4.1.7.2 GLUE Architecture:

UDDI
UDDI

Glue
XML/SOAP/WSDL
XML/SOAP/WSDL
Any JAVA Object
Any JAVA Object

Servlets/JSP Servlets/JSP

App. Server
Security Security

Web Server Web Server

Glue Standalone Glue: Hosted in Application Server

Fig:14 Glue Architecture

GLUE reduces the need for third party integration and provides a small footprint; Glue can be
used in one of two modes. In standalone mode, Glue is essentially a lightweight, high
performance application server without the complexity of EJB and includes its own web
server, servlet engine, JSP engine, and high-speed XML parser. In hosted mode, Glue plugs
into any 3rd party application server or servlet engine and provides it with advanced, high
performance web services capabilities. Glue also includes a powerful, high performance web
services client library.
GLUE can parse Java byte codes at runtime to figure out variable names from embedded debug
information, and generate dynamic proxies even with JDK 1.2. These capabilities only exist
because GLUE contains sophisticated code for reading and writing Java byte codes at runtime.
GLUE has been designed for 3rd party extensibility, so it is possible to add new transport
layers, protocols, service types, security integrations, registries and WSDL bindings without
modifying the core code. For example, GLUE could be extended to simultaneously support
CORBA, DCOM and SOAP.

55
The main capabilities and advantages of GLUE are:
• lightweight , high performance
• 100% standards compliant
• language and platform neutral
• non-intrusive, zero-install option
• runs on all computers from PDAs to mainframes
• P2P architecture for scalability and reliability
• runs natively on J2EE and .NET

56
4.2 IMPLEMENTATION

4.2.1 Software platforms used:

• Core JAVA (J2SDK1.4.6) is used for implementing the Mobile Agent and Http Server
• JAVA Swing API is used for developing the GUI for the client application. Swings are
chosen over AWT for its impressive and platform independent appearance.
• Java Server Pages is used for developing the GUI for the product selection and Tomcat
4.1.24 is used as Web Server.
• SQL Server 7.0 is used as the back-end for storing the data and user information .
Connectivity is provided between JAVA and SQL Server 7.0 through JDBC-ODBC
Driver.
• Windows 2000 systems are used, while developing the application. As JAVA is
platform independent the same implementation will also work under Linux
environment.

57
4.2.2 Implementation level details:

4.2.2.1 Database component and access:

One of the advantages of the Tracy environment is that it is platform independent. Agents are
supposed to be able to travel around a heterogeneous environment, and everything has been
done to keep this real for the database connection.
First of all, the language used to query the database is the SQL language. It is the language
supported by all databases. The tests were performed with a Microsoft Access database, mobile
agent uses an ODBC driver, so any ODBC compliant database would do the job. Moreover, the
Java database connectivity is done with JDBC, and many drivers are available for non ODBC
compliant database on the Java web site . A simple update of the driver would allow any
specific database to be accessed by the mobile agent. Mobile agents are not concerned by the
database type or platform operating system.
The data extracted from the database is stored in a QueryDataSet component. This component
has many advantages, and makes data manipulation easier. The problem of this object is that its
content is not serializable, only its structure is. When a mobile agent migrates, its objects are
serialized, and if the mobile agent contain a QueryDataSet, the references to the local host will
not be found on the host it is migrating to, and content will be lost.
To overcome this problem, the server saves the QueryDataSet to a text file. This operation
generates two files: a file with the raw data, and a file specifying the structure of the dataset.
These files are stored as an array of bytes, which is serializable. The mobile agent stores the
files as an array of bytes in two distinct Java Vectors. At each node, an element is added to
each Vector. When the mobile agent is back on its home platform, it posts the Vector
themselves to the infoboard of the agent server, and the client side gateway agent is in charge
of the reconstitution of the files: files are saved to the local host, then they are reconverted back
to QueryDataSets (the ones from the servers), and then all QueryDataSets are concatenated to
form only one QueryDataSet which is displayed to the GUI as the result of the request over the
distributed system.
The end-user cannot see in the result table which information comes from each host: it appears
like if information was coming from only one host.

58
 4.2.2.2 Database design:
We create a schema named mydsn for the sample application, which consists of
four tables
Category
PK ITEM Item
CATEGORY PRODUCT
DESCRIPTION QUANTITY
HOSTIP PRICE
IMAGENAME SCHEME
DESCRIPTION

Registration
PK USERNAME
PASSWORD
AGE
SEX
ADDRESS User info
PHONE USERNAME
EMAIL PASSWORD

Fig:15 Database Tables

Database tables that are created for storing the data and user information into it are:
• Category (CATEGORY, ITEM, DESCRIPTION, HOSTIP, IMAGENAME)
CATEGORY is the classification of the products for easy identification . ITEM is the
name of the product, It is primary key of this table. DESCRIPTION is brief detail about the
product which distinguish it from all other products in the same category. HOSTIP is the
merchant host address who is offering product for sale in electronic market. IMAGENAME
is the name of image stored.
• Registration (USERNAME, PASSWORD, AGE, SEX, ADDRESS, PHONE, EMAIL)
USERNAME, PASSWORD is for login, all other fields for the user personnel information
• Item (PRODUCT, QTY, PRICE, SCHEME, DESCRIPTION)
PRODUCT is the foreign key references to Category table. This table is for storing the
information of the merchant host. QTY is qty available at the store, PRICE is the offered
basic price exclusive of taxes by the store, SCHEME is the special buying offer made by
the store, DESCRIPTION is the product brief description as per availability at that store.

59
 • Userinfo (USERNAME, PASSWORD)
USERNAME,PASSWORD is the foreign key references to Registration table
4.2.3 Page Flow Diagram

Normal User
New User
Registration

Home Login Error

View Price
Product Information
Selection

Login Browse

Modify
Modify
Add User Password Delete User
Password

Add Merchant Add Product

Information Information
Administrator

Fig:16 Page Flow Diagram of SIAS

60
61