CHAPTER 2

LITERATURE SURVEY

5
2.1 SERVICE ORIENTED ARCHITECTURE

2.1.1 OVERVIEW

Applications that were being used prior to the Internet era were tightly coupled and
they were not designed to be portable or interoperable. It is important for successful e-
commerce ventures that the interacting parties be communicating in a medium that is
understandable to all the partners and collaborators. It is therefore essential for a fruitful
business application to be architected in a way that is interoperable and loosely coupled.
This leads to the concept called Service Oriented Architectures (SOA).
The Service Oriented Architecture (SOA) may be defined as architecture for linking
resources on demand. In an SOA, resources are made available to other participants in the
network as independent services that are accessed in a standardized way. This provide for
more flexible loose coupling of resources than in traditional systems architecture
The Application development for the enterprise will have to be now implemented in
SOA terms. In other words, certain categories of enterprise applications have to be
developed as collection of services. This new architecture will therefore ensure flexible and
simplified delivery of services to clients.

Service
Registry

Find Publish

Service Service
Requestor Provider

Bind

Figure 1:A Service Oriented architecture

6
Any Service Oriented Architecture contains following three roles:
• A Service Provider: is one who is responsible for creating a service description,
publishing that service description to one or more service registries, and receiving
web service invocation messages from one or more service requestors. A service
provider, then, can be any company that hosts a web service made available on
some network. We can say service provider as the “server-side” of a client-server
relationship between the service requestor and the service provider.
• A Service Requestor: is one who is responsible for finding a service description
published to one or more service registries and is responsible for using service
descriptions to bind to or invoke web services hosted by service providers. Any
consumer of a web service can be considered a service requestor. We can say
service requestor as the “client-side” of a client-server relationship between the
service requestor and the service provider.
• A Service Registry: is one who is responsible for advertising web service
descriptions published to it by service providers and for allowing service requestors
to search the collection of service descriptions contained with in the service
registry. The service registry role is simple: be a matchmaker between service
requestor and service provider. Once the service registry makes the match, it is no
longer needed in the picture; the rest of the interaction is directly between the
service requestor and service provider for the web service invocation.
Each of the above mentioned roles can be played by any program or network node. An
SOA also includes following three operations which defines the contracts between the
SOA roles:
• Publish: This operation is an act of service registration or service
advertisement. It acts as the contract between the service registry and the service
provider. When a service provider publishes its Web service description to a
service registry, it is advertising the details of that Web service to a community
of service requestors. The actual details of the publish API depend on how the
service registry is implemented. Some services registry implementations, such
as UDDI, define a very sophisticated implementation of the publish operation

7
 • Find: This operation is the logical dual of the publish operation. The find
operation is the contract between a service requestor and a service registry. With
the find operation, the service requestor states a search criteria, such as type of
service, various other aspects of the service such as quality of service
guarantees, and so on. The service registry matches the find criteria against its
collection of published web service descriptions. The result of find operation is
a list of service description that match the find criteria
• Bind: This operation embodies the client-server relationship between the
service requestor and the service provider. The bind operation can be quite
sophisticated and dynamic, such as on the fly generation of a client-side proxy
based on the service description used to invoke the web service; or it can be a
very static model, where a developer hand-codes the way a client applicationb
invokes a web service.

2.1.2 WHY SOA

There are many reasons for an enterprise application to take an SOA approach, and
more specifically, a web services based SOA approach. Some of the primary reasons are:
• Reusability: What drives the move to SOA is reuse of business services.
Developers within an enterprise and across enterprises can take the code developed
for existing business applications, expose it as web services, and then reuse it to
meet new business requirements. Reusing functionality that already exists outside
or inside an enterprise instead of developing code that reproduces those functions
can result in a huge savings in application development cost and time. The benefit
of reuse grows dramatically as more and more business services get built, and
incorporated into different applications. A major obstacle in taking advantage of
existing code is the uniqueness of specific applications and systems. Typically,
solutions developed in different enterprises, even different departments within the
same enterprise, have unique characteristics. They run in different operating
environments, they're coded in different languages, they use different programming
interfaces and protocols. You need to understand how and where these applications
and systems run to communicate with them. The work involved in doing this

8
 analysis and the development effort in tying these pieces together can be very time
consuming. Witness the pain IT organizations generally encounter when they try to
integrate their applications with systems from business partners. In an SOA, the
only characteristic of a service that a requesting application needs to know about is
the public interface. The functions of an application or system can be dramatically
easier to access as a service in an SOA than in some other architecture. So
integrating applications and systems can be much simpler.
• Interoperability: The SOA vision of interaction between clients and loosely-
coupled services means widespread interoperability. In other words, the objective is
for clients and services to communicate and understand each other no matter what
platform they run on. This objective can be met only if clients and services have a
standard way of communicating with each other -- a way that's consistent across
platforms, systems, and languages. In fact, web services provide exactly that. Web
services comprise a maturing set of protocols and technologies that are widely
accepted and used, and that are platform, system, and language independent. In
addition, these protocols and technologies work across firewalls, making it easier
for business partners to share vital services.
• Scalability: Because services in an SOA are loosely coupled, applications that use
these services tend to scale easily -- certainly more easily than applications in a
more tightly-coupled environment. That's because there are few dependencies
between the requesting application and the services it uses. The dependencies
between client and service in a tightly-coupled environment are compounded (and
the development effort made significantly more complex) as an application that
uses these services scales up to handle more users. Services in a web services-based
SOA tend to be coarse-grained, document-oriented, and asynchronous. coarse-
grained services offer a set of related business functions rather than a single
function. An synchronous service performs its processing without forcing the client
to wait for the processing to finish. A synchronous service forces the client to wait.
The relatively limited interaction required for a client to communicate with a
coarse-grained, asynchronous service, especially a service that handles a document

9
 such as a purchase order, allows applications that use these services to scale without
putting a heavy communication load on the network.

• Flexibility: Loosely-coupled services are typically more flexible than more tightly-
coupled applications. In a tightly-coupled architecture, the different components of
an application are tightly bound to each other, sharing semantics, libraries, and
often sharing state. This makes it difficult to evolve the application to keep up with
changing business requirements. The loosely-coupled, document-based,
asynchronous nature of services in an SOA allows applications to be flexible, and
easy to evolve with changing requirements.

2.1.3 SOA AND WEB SERVICES

Web Services technology constitutes the preferred implementation vehicle for service-
oriented architectures. Web services, and more in general service-oriented architectures
(SOAs), are emerging as the technologies and architectures of choice for implementing
distributed systems and performing application integration within and across companies'
boundaries The ideas behind SOA – modularization, platform independence, etc. – are not
new. Prior technologies have promoted many of the same principles, but failed to achieve
the status of SOA. So why has SOA gained so much traction? The answer is Web services.
In theory, SOA does not require Web services, and simply implementing Web services
does not necessarily result in an SOA. In reality, however, SOA and Web services are
inexorably linked, and it is their synergy that is driving service-orientation into the
mainstream.
On the one hand, Web services – which are simply services that use specific XML-based
protocols and interface descriptions to communicate – provide the standards upon which
today’s SOAs are being built.
On the other hand, SOA principles are directing the maturation of Web services with the
qualities expected of a good architecture – reliability, security, and so on. As a result,
additional standards now exist, or are in the process of being developed, to enable Web
services to fulfill the true promise of SOA.

10
2.2 THE WEB SERVICES

2.2.1 OVERVIEW

A Web Service is programmable application logic accessible using standard Internet

protocols. Web Services combine the best aspects of component-based development and
the Web. Like components, Web Services represent functionality that can be easily reused
without knowing how the service is implemented. Unlike current component technologies,
which are accessed via proprietary protocols, Web Services are accessed via ubiquitous
Web protocols (ex: HTTP) using universally-accepted data formats (ex: XML).
In practical business terms, Web Services have emerged as a powerful mechanism for
integrating disparate IT systems and assets. They work using widely accepted technologies
and are governed by commonly adopted standards. Web Services can be adopted
incrementally with little risk and at low cost. Today, enterprises use Web Services for
point-to-point application integration, to reuse existing IT assets, and to securely connect to
business partners or customers. Independent Software Vendors (ISVs) embed Web
Services functionality in their software products so they are easier to deploy.
From a historical perspective, Web Services represent the convergence between the
service-oriented architecture (SOA) and the Web. SOAs have evolved over the last 10
years to support high performance, scalability, reliability, and availability. To achieve the
best performance, applications are designed as services that run on a cluster of centralized
application servers. A service is an application that can be accessed through a
programmable interface. In the past, clients accessed these services using a tightly coupled,
distributed computing protocol, such as DCOM, CORBA, or RMI. While these protocols
are very effective for building a specific application, they limit the flexibility of the system.
The tight coupling used in this architecture limits the reusability of individual services.
Each of the protocols is constrained by dependencies on vendor implementations,
platforms, languages, or data encoding schemes that severely limit interoperability. And
none of these protocols operates effectively over the Web. The Web Services architecture
takes all the best features of the service oriented architecture and combines it with the Web.

11
2.2.1.1 Definition of Web Services
several major web services infrastructure providers have published their definition for a
web service:
Sun provides the following definition at http://www.sun.com/software/sunone/faq.html#2
“Web services are software components that can be spontaneously discovered combined,
and recombined to provide a solution to the user’s problem/request. The Java language and
XML are the prominent technologies for web services.”
The other definition given by Microsoft is at:
http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28000442:
“A Web service is a unit of application logic providing data and services to other
applications. Applications access Web services via ubiquitous web protocols and data
formats such as HTTP, XML, SOAP, with no need to worry about how each web service is
implemented. Web Services combined the best aspects of component based development
and the web, and are a cornerstone of Microsoft .NET programming model.”

2.2.2 CHARACTERISTICS OF WEB SERVICES

Web Service exhibits the following definitive characteristics:

• A Web Service is accessible over the Web. Web Services communicate using
platform-independent and language-neutral Web protocols. These Web protocols
ensure easy integration of heterogeneous environments.
• A Web Service provides an interface that can be called from another program. This
application-to-application programming interface can be invoked from any type of
application client or service. The Web Service interface acts as a liaison between
the Web and the actual application logic that implements the Service.
• A Web Service is registered and can be located through a Web Service Registry.
The registry enables service consumers to find services that match their needs.
• Web Services support loosely coupled connections between systems. Web Services
communicate by passing messages to each other. The Web Service interface adds a
layer of abstraction to the environment that makes the connections flexible and
adaptable.

12
2.2.3 WEB SERVICES STANDARDS
Web services are built upon open, often already widely adopted standards such as HTTP
and eXtensible Markup Language (XML). Typically, these standards are maintained by
independent, non-profit standards organizations composed of a diverse membership.
Members submit various requirements for the standard and agree to a specification after
many review phases, resulting in a free and open standard upon which any group can build
Web service-compliant applications and tools.
Three popular standards support the implementation of web services:
• SOAP (simple object access protocol) is a general-purpose protocol for sending
XML messages between endpoints, and may be used for remote procedure calls
(RPC) or plain document transfer. SOAP messages can be send over any transport
layer; HTTP is the most common layer, with implementations also available for
Simple Mail Transport Protocol (SMTP) and java Messaging Service (JMS).
• WSDL (web services description language) is XML based language for describing a
Web Service. WSDL describes what a web service can do, where it resides, and
how to invoke it.
• UDDI (universal description, discovery and integration) is a registry for connecting
producers and consumers of web services. A producer can use the UDDI publish
API to register information about a web service, and a consumer can use the UDDI
inquire API to locate one or more web services that satisfies a particular criteria.
2.2.3.1 Anatomy of SOAP-Simple Object Access Protocol
SOAP is an extensible XML messaging protocol that forms the foundation for Web
Services. SOAP provides a simple and consistent mechanism that allows one application to
send an XML message to another application. Fundamentally, SOAP supports peer-to-peer
communications. A SOAP message is a one-way transmission from a SOAP sender to a
SOAP receiver, and any application can participate in an exchange as either a SOAP sender
or a SOAP receiver. SOAP messages may be combined to support many communication
behaviors, including request/response, solicit response, and notification.
SOAP was first developed in late 1999 by Develop Mentor, Microsoft, and
UserLand as a Windows-specific XML-based remote procedure call (RPC) protocol. In
early 2000 Lotus and IBM joined the effort and helped produce an open, extensible version
of the specification that is both platform- and language-neutral. This version of the

13
specification, called SOAP 1.1 (see http://www.w3.org/TR/SOAP/), was submitted to the
World Wide Web Consortium (W3C). W3C subsequently initiated a standardization effort.
SOAP 1.2 is the latest, approved version of the standard and defines following four
conventions:
1.Message Envelop:
It consists of three parts:
• SOAP Envelope: The SOAP envelope provides a mechanism to identify the
contents of a message and to explain how the message should be processed. A
SOAP envelope includes a SOAP header and a SOAP body.
• The SOAP header : provides an extensible mechanism to supply directive or
control information about the message. For example, a SOAP header could be used
to implement among other things: Transactions, Security, for instance, using WS-
Security Reliability, using the upcoming WS-ReliableMessaging standard
Routing Payment mechanisms

• SOAP Body: The SOAP body contains the payload that is being sent in the SOAP
message.

2. Encoding Rules:
These rules provide a convention of mapping the application data to XML based data.
They are based on XML schema and as such closely model many of the standard data types
and constructs that most of the programming languages provide. The encoding rules
enforce strict guidelines while creating and formatting the message
3. RPC Convention:
RPC calls are called request-response oriented calls. Along with the request, data is
serialized and sent to the target application. Likewise, the data received as a response from
the target system is de-serialized. SOAP specification defines rules for carrying out remote
procedure calls. The RPC convention takes care of how data is sent through request call
and receive the result through the response
4. Binding with underlying protocol:
SOAP is designed independent of transport protocol. In principle, it means that
SOAP can be exchanged over many transport protocol. However, the only binding

14
 defined in the SOAP specification is to HTTP. However, by design, it does not prevent
applications from using any other protocol.

2.2.3.2 Anatomy of WSDL-Web Services Description Language

WSDL is an XML format for describing network services as a set of endpoints operating
on messages containing either document-oriented or procedure-oriented information. The
operations and messages are described abstractly, and then bound to a concrete network
protocol and message format to define an endpoint. Most often, these messages are bound
to the SOAP protocol and the HTTP transport, but these are not the only set of bindings
supported. WSDL’s abstract nature for describing services makes it very flexible for
describing complex Web services applications.
WSDL attempts to provide an open, standards-based group of tools that automates
discovery and interaction among web-based services. WSDL describes network services as
endpoints that exchange messages telling what services are available. The language is
limited to message formats or network protocols that conform to SOAP 1.1, HTTP get/post
and MIME (Multipurpose Internet Mail Extensions). The specification leaves open-ended
the other message formats that will be supported. A WSDL XML document is the basis of
this exchange of information. A WSDL document uses the following seven elements in the
definition of network services:
• Type– A container for data type definitions using some type system (such as XML
Schema Definition, XSD).
• Message– An abstract, typed definition of the data being communicated.
• Operation– An abstract description of an action supported by the service.
• Port Type–An abstract set of operations supported by one or more endpoints.
• Binding– A concrete protocol and data format specification for a particular port
type.
• Port– A single endpoint defined as a combination of a binding and a network
address.
• Service– A collection of related endpoints.

15
2.2.3.3 Anatomy of UDDI-Universal Description and Discovery of Information
UDDI represents a set of protocols and a public directory for the registration and real-time
lookup of Web services and other business processes. In many ways, UDDI models a
“White Pages,” providing a listing of services available within a network. The primary
benefit of a UDDI server is to provide a single point of reference to all available services
within an enterprise. The UDDI server allows organizations to:
• Host multiple versions of a service
• Create aliases to services
• Limit access to specific services
While UDDI is a ratified standard, it is still gaining adoption and has been changing
frequently. There are many other commercial products, known as “Web Service
Management” tools, which perform many of the same tasks as UDDI while providing
added benefits such as metering and inspection of the services. UDDI and Web Service
Management tools help keep the connection between services loosely coupled.
UDDI specifies a registry of Web services, similar to numbers in a phone book. Given
a service’s general description, it retrieves a list of matching services. Service providers can
dynamically publish information and services, and service requesters can search through
the registry to find personal information about a service provider as well as technical
information about its services.
The UDDI registry maintains a centralized database of Web services, classified by
geography, service type, provider information, and so on; it also defines a standard API for
requesters to query the database. UDDI’s intelligent searching mechanism is still in the
early stages, much like the intelligent interpretation of WSDL. The ability to parse a human
request for a service and correctly match it to a human description of a service without the
give and take of human conversation is a thorny problem. Researchers and practitioners are
continually refining the interfaces and semantics for creating a utopic UDDI, but work has
yet to reach sufficient stability or maturity for wide deployment. In fact, it might not ever
reach that state. Moreover, without this functionality, public UDDI’s usefulness is low,
relative to the other key technologies described here. However, private UDDI—where the
same organization that produced the service deploys the service —is more useful. In this
context, it offers a layer of abstraction that lets the client forego a hard-coded interface.

16
Instead, the client can use a well-known identifier to search the UDDI registry for the most
up-to-date interface information.
2.3 MOBILE AGENTS

2.3.1 OVERVIEW

Mobile agents have been the focus of much speculation and hype in recent years. The
appeal of mobile agents is quite alluring - mobile agents roaming the Internet could search
for information, find us great deals on goods and services, and interact with other agents
that also roam networks (and meet in a gathering place) or remain bound to a particular
machine. Significant research and development into mobile agency has been conducted in
recent years, and there are many mobile agent architectures available today.
Mobile agents are proven to be useful in the domain of distributed systems. Reasons
are the problems more traditionally designed distributed systems, especially client/server
systems, might have to handle work-load, the trend to open large numbers of customers
direct access to services and goods, and user mobility. Mobile agent technology can help to
design innovative solutions in this domain by complementing other approaches, simply by
adding mobility of code, machine based intelligence, and improved network- and data-
management possibilities [1]
The mobile agent paradigm intends to bring an increased performance and flexibility
to distributed systems by promoting "autonomous code migration" (mobile code moving
between places) instead of traditional RPC (remote procedure call). With code migration,
the actual code or script moves from place to place and executes locally, achieving lower
latency, little need for remote interactions and highly flexible control.

2.3.1.1 Definition of Mobile Agent

Mobile agents refer to self contained and identifiable computer programs, bundled with
their code, data, and execution state, that can move with in a heterogeneous networks of
computer systems. They can suspend their execution on an arbitrary point and transport
themselves to another systems. During this migration the agent is transmitted completely,
that is, as a set of code, data, and execution state. At the destination computer system, an
agent’s execution is resumed at exactly the point where it was suspended before.

17
2.3.1.2 Life Cycle Model of Mobile Agent

The life of a mobile agent is modeled with the stages it goes through called lifecycle
model . The stages of the model are:
Creation of the agent is done only once when new agent is created. Every agent gets its
unique id, initial state and then it is prepared for further instructions.
Starting is done each time when the agent arrives to a new host. The agent has its own
thread of execution and can execute asynchronously. The server initializes the agent and
gives it a thread of execution after which the agent resumes its execution. All the agents are
executed in parallel on the host.
Deactivation, the agent stops all its calculations and stores its state and intermediate results
to a disk. That means, the agent is put to sleep using object serialization, available in
JDK1.1 and later. The states of the agent objects are exported to a byte stream and later,
they are reconstructed from the byte stream .The deactivation method can also be used for
making checkpoints before performing some unsecured operations or moving to unknown
host. The possible difficulty is when the agent is recreated from its checkpoint while it is
still active on the remote host. To prevent confusion or errors, before using the checkpoint
for creation, it must be absolutely certain the original agent is deactivated .
Disposal means the agent terminates all its activity and frees all resources it’s using. After
that, its state is lost forever.
Cloning is process of making multiple clones of an agent using object serialization. New
(cloned) agent is identically same with the original except the id number, if any and it is
sent to the new host. Cloning is used when more than one agent is needed for completing
the task.

Figure 2: Life Cycle Model of Mobile Agent

18
2.3.1.3 Mobile Agents: an alternative to Client/Server

Client / Server Server

1
Query

Reply
Query
Server
3
Reply
Query

User’s Local Machine

Reply Server
2

Mobile Agent Server

Send agent 1 Send agent

Server
3

User’s Local Machine

Send agent Send agent
Server
2

Figure 3: A Client-Sever and Mobile Agent Paradigm

Distributed applications are applications that involve the coordination of two or

more computers, geographically apart and connected by a physical network. Most
distributed applications we see today, such as email, network news, file transfer, and Web
browsing, are deploying the client/server paradigm. In the client/server paradigm, an
application is divided into two processes, a client process running locally that asks for
services and a server process on a remote site that gives services to the client. The client
and server processes must communicate with each other in order to carry out their tasks

19
successfully. Communication is done by means of message exchange. There are at least
two problems with the client/server paradigm:
• It has a high network bandwidth requirement due to the large number of messages
exchanged.
• It usually requires users to response to computation results interactively, under
different situations. Neither the client nor server would make decisions for users
autonomously.
In view of the deficiencies of the client/server paradigm, the mobile agent paradigm has
been developed as an alternative approach for distributed application design. In the
client/server paradigm, programs are geographically stationary, meaning that they do not
move to another machine, and only run on the machines they reside on. (Therefore, the two
processes must communicate continuously.) The mobile agent paradigm, on the other hand,
allows programs to be transferred among and executed on different computers. By allowing
agent to move between hosts, programs can interact on the same computer instead of over
the network. Therefore, communication cost can be reduced.Besides, the mobile programs
can be designed to work on behalf of users autonomously. The autonomy of mobile agents
allows the users to delegate their tasks to the mobile agents, and not to stay continuously in
front of the computer terminal.

2.3.2 CHARACTERISTICS OF MOBILE AGENTS

Mobile agent possess the following four characteristics [2]:

• Mobile agents are used in wide area and heterogeneous networks in which no
assumptions can be made concerning either the reliability of the concerned
computers or the security of the network connections.
• The mobile agents migration is initiated by the agent ( more precisely, its
programmer), in contrast to mobile object systems, in which object migration is
initiated by the underlying operating system or middleware.
• Migration of mobile agents is done to access resources available only at other
servers in the network and not just for load balancing, as in mobile object systems

20
 • Mobile agents are able to migrate more than once-this characteristic is sometimes
called multi-hop ability. After a mobile agent has visited the first server, it might
migrate further to other servers to continue its task
• Once a mobile agent is launched, it should not be reliant on the system that
launched it and should not be affected if that node fails. The concept of an agent
moving between network nodes gives it the ability to `survive' and to reach as many
resources as possible.

2.3.3 WHY ARE MOBILE AGENTS A GOOD IDEA

Although mobile agents provide a new and interesting approach to distributed system,
there must be clear arguments in favor of mobile agents before they are substituted for
more traditional techniques. Following are the four major technical advantages [3]:
• Delegation of task : Because mobile agents are simply a more specific type of
software agent, a user can employ a mobile agent as a representative to which a user
may delegate tasks. Instead of using computer systems as interactive tools that are
able to work only under direct control by a user. As a result, the user can devote
time and attention to other, more important things. Thus mobile software agents are
a good means to cope with the steady information overload.
• Asynchronous processing: Once mobile agents have been initialized and setup for
a specific task, they physically leave their owner’s computer system and from then
on roam freely through the Internet. Only for this first migration must a network
connection be established. This feature makes mobile agents suitable for nomadic
computing , meaning mobile users can start their agents from mobile devices that
offer only limited bandwidth and volatile network links.
• Adaptable service interfaces: Current techniques in distributed system that offer
application service interfaces, usually as a collection of functions, constitute only
the least common denominator of all possible clients. As a consequence, most of the
interface functions are more or less primitive, and clients will probably have to use
a workflow connecting these functions in order to execute a complex, user driven
operation. If the communication overhead for exchanging messages between client
and server is high compared with the execution time of each function, it would

21
 make sense to offer aggregated and more advanced functions as combination of the
primitive ones. Mobile agents can help in this situation by offering a chance to
design a client-driven interface that is optimized for the client but that is adaptable
to different server interfaces.
• Code-shipping versus data-shipping: this is the probably most cited advantage of
mobile agents, and it stands close relationship to adaptable service interfaces
frequently offer only primitive functions to access databases. A single call can
therefore result in a huge amount of data being sent back to the client because of the
lack of precision in the request. Instead of transferring data to the client, where it
will be processed, filtered and probably cause a new request (data-shipping), this
code can be transferred to the location of the data (code-shipping) by means of
mobile agents and sent back only relevant data to the client. this result in saving of
time, network traffic and bandwidth

2.3.4 APPLICATION DOMAINS OF MOBILE AGENTS

Recently many research groups and companies have participated in the advancement
of mobile agent systems. However, because the technology is new and radical in its
concepts, some type of proof is needed that would show that mobile agents as a technology,
are indispensable. It is accepted today that mobile agents will not make any application
possible that would not have possible using other, more traditional techniques. However,
that can be said of other technologies
Thus, when we talk about a new technology today, in most cases we talk about improved
quality and management of complexity, the efficient use of resources in projects, and the
adequacy of concepts and tools. The point is not that something new is possible, but that
there are new methods of achieving what is already possible, which may, in turn, lead to
new possibilities.
Nevertheless, it is possible to identify some application domains where mobile agent have
already proved to be highly valuable and that seem to “asked for” that type of technology.
These domains are:
• Electronic commerce be it business-to-business or business-to-customer, more than
single shopping platform is involved and that will look at a distributed work flow

22
 with transaction qualities that involves physically separated data stores. Although
we need better certification authorities and repudiation techniques, no doubt, the
technological challenge will be to interact with a number of distributed sites and to
integrate a set of possible incomplete results into coherent solutions. Only mobile
agents, with their inherent capability for traveling the network and their fully
distributed paradigm, provide a conceptually sound basis for this application
domain. They do shopping as we like to do it, by visiting the stores, comparing the
different offers and, finally finishing the acquisition. This also includes the
capability to spot a new store and to include it in to the acquisition process. when
equipped with a negotiation strategy, they may even do business transactions on
behalf of their owners.
• Information retrieval is another popular application domain for mobile agents.
Instead of moving large amount of data to a single point where it is searched,
information retrieval moves the data-searching code to the data. A typical
application for mobile agent in this domain is multiple distributed sources.if the
relevant information sources can not be centralized either because of technical
reasons or because of business driven necessities, mobile agent offer the only
chance to develop a flexible solution that accepts the distributed nature of the given
environment and offers a solution that is as distributed and scalable at the problem
itself.
• Monitoring is also a typical application domain where agents can be sent out to
wait for certain events or certain kinds of information to become available and then
react appropriately (e.g., by buying shares on a stock market host). Similarly,
mobile agents may also be used for the automation of many tasks in network
configuration and management e.g., for remote diagnosis). Agents may install
software on remote machines, or they may personalize remote devices and services.
• Entertainment could also be an important application domain of mobile agents
where it can enable distributed multi-user games, they may locate persons with a
similar interest, and they may represent a player on a game host.

23
2.3.5 MOBILE AGENTS FOR E-COMMERCE
In B2C e-commerce arena, which is becoming more widespread as more people come to
recognize its convenience and its ability to offer a quick response to requests and as more
products/services become available. As this adoption spreads, the impetus for employing
software agents increases in order to enhance and improve the trading experience. In order
to systematically analyse the tasks that agents can assist with, we employ the CBB model
perspective[4]:

Figure 4:Consumer Buying Behavior Model

We believe mobile agents can act as mediators in six of the stages[5]:

1. Need Identification: This stage characterizes the buyer becoming aware of some unmet
need. Within this stage, the buyer can be stimulated through product information.
2. Product Brokering: This stage comprises the retrieval of information to help determine
what to buy. This encompasses the evaluation of product alternatives based on buyer-
provided criteria. The result of this stage is the "consideration set" of products.
3. Merchant Brokering: This stage combines the "consideration set" from the previous
stage with merchant-specific information to help determine who to buy from. This includes
the evaluation of merchant alternatives based on buyer-provided criteria (e.g., price,
warranty, availability, delivery time, reputation, etc.).
4. Negotiation: This stage is about how to settle on the terms of the transaction.
Negotiation varies in duration and complexity depending on the market. In traditional retail
markets, prices and other aspects of the transaction are often fixed leaving no room for

24
negotiation. In other markets (e.g., stocks, automobile, fine art, local markets, etc.), the
negotiation of price or other aspects of the deal are integral to the buying process.
5. Purchase and Delivery: The purchase and delivery of a product can either signal the
termination of the negotiation stage or occur sometime afterwards (in either order). In some
cases, the available payment (e.g., cash only) or delivery options can influence product and
merchant brokering.
6. Product Service and Evaluation: This post-purchase stage involves product service,
customer service, and an evaluation of the satisfaction of the overall buying experience
and decision.
As with most models, these stages represent an approximation and simplification of
complex behaviors. The stages listed above often overlap and migration from one to
another can be non-linear and iterative.
Given the above set of stages, we can identify the roles of agents as mediators in
electronic commerce.

In B2B e-commerce arena, B2B deals with transactions among organizations. Generally
speaking, relationships between organizations are more complex than those between
businesses and consumers, since they involve the adoption of similar standards with respect
to communications and collaboration, as well as joint information technology investment.
In particular, one of the main aims of the B2B e-commerce is to significantly improve the
supply chain by facilitating more efficient and agile procurement processes. More over the
exchanges in the B2B domain are increasingly tending to be private. Such exchanges
enable companies to trade with their existing partners in a well-defined environment with
out having to go through some of the early stages of the B2B life cycle. There are various
ways of viewing B2B e-commerce, however here we use a BBT model to explore the roles
of agent[3]:

25
 Figure 5: Business-to-Business lifecycle Model

we believe mobile agents can act as mediators in six of the stages[5]:

1.Patnership formation: the information technology available today makes it possible for a
company to search for its partners world wide. given this fact, partnerships can be much
more agile and fluid. This step may include the forming of new virtual organization as well
as finding the partners that provide products or services in a supply chain
2.Brokering: is the process that matches sellers who supply goods/services to the buyers
who need them. From the seller’s side, it is how they can propagate their products and
locate potential buyers. From the buyer’s side, the problem is how to find the most
appropriate seller to provide the goods/services
3.Negotiation: The negotiation stage is where the traders aim to reach an agreement about
what actions should be performed under what conditions. by establishing contracts on an as
needed, just in time basis, sellers can tailor their offerings both to their individual and
prevailing market situation at any given moment in time. Buyers can reduce their supply
chain cost, benefit from dynamic price mechanism, broaden their supplier database, and
streamline the procurement process
4.Contract formation: involves two or more people meeting face to face. However as e-
commerce systems evolve this situation is started to change that is one agent trying to
contract out some of its tasks to another agent by promising some rewards.Contract
formation is applied in the fields such as electricity markets, bandwidth allocation,
manufacturing planning and scheduling.
5.Contract fulfillment: means the parties carry out the agreed transaction according to the
terms specified in the contract. This stage usually includes a detail description of the goods

26
/ service provided; the means of delivery; how it will be paid for; which law governs the
contract; how to resolve any disputes, how to deal with claims arising, how a contract can
be monitored and so on
6.Service evaluation: This is the post transaction stage, where traders evaluate their
satisfaction with the transaction. Many e-commerce systems allow users to provide
feedback on the transactions experience. This feedback representing the reputation of the
trader, can then be made accessible to subsequent agents that wish to interact with the
trader
we believe agents are most useful in the above mentioned stages because these
stages all involve complex issues related to decision making, searching and matchmaking
that suits to mobile agent paradigm.

2.3.6 MOBILE AGENTS TOOLKITS

Mobile Agent toolkits provides the framework for mobile agents to navigate and
communicate via the network. Toolkits contains all fundamental features to support a
mobile agent and provides flexibility for agent developers to implement different concepts
and add new features. Mobile Agent toolkits provide the infrastructure for Mobile Agents:
• To interact with the underlying computer system-to provide a “Home”, a “Place”, a
“Context”- for agents to reside in and perform their tasks on a given host
• To move from host to host
• To communicate with each other,with users and with host servers
• To maintain privacy and integrity(of Agents as well as hosts)
James white introduced the term mobile agent in 1994 and since then research in this
domain is on. Lots of mobile agent toolkits were developed since then by using various
languages such as Telescript, AgentTcl, Schema etc., however General magic received a
patent for this concept in 1997 .However in recent years most of the toolkits were
developed with Java programming language because of the following reasons:
• A Java program can run on any platform that implements the Java Virtual machine
specification. This enables java mobile agents can run on many different hosts and
move across a heterogeneous network such as Internet.

27
 • The java architecture has a security model built in. the security madel is designed
into the java virtual machine specification. Security is important for mobile agent
systems to prevent mobile agents attacking the host.
• The concepts of Java applets and mobile agents are similar. The name for IBM’s
mobile agent library: “Aglets” is play on words. Applets like mobile agents, migrate
across a network for execution at a foreign host. However an applet can only
migrate from server to a browser. Applets also differ in that they do not carry their
state with them on migration.
However Java has one major disadvantage for being the basis of a mobile agent system: it
is impossible to save the program stack. This means that a mobile agent cannot migrate
from any arbitrary point with in the program and resume execution on the next line upon
arrival at the destination host. Other mobile agent systems such as Telescript and AgenTcl
have this capability. A Java mobile agent must save all relevant information in member
variables of its objects before migration.
In general there are three targets of Mobile Agent toolkit design and Implementation:
using or creating a specialized language, as operating system(OS) services or extensions to
take advantage of existing OS features. Lastly, the third builds mobile agent systems as
specialized application software that runs on top of OS to provide mobile agent
functionality. Several academic and industrial research groups are currently investigating
and building mobile-agent systems. The overview of a representative subset of these
mobile agent system, listed in approximately chronological order of their development are
given below:

• Telescript: Telescript, developed by General Magic in the early 1990s as the first
system designed expressly to support mobile agents in commercial applications,
includes an object-oriented, typesafe language for agent programming. Telescript
servers, which are called places, offer services, usually by installing stationary
agents to interact with visiting agents. Agents use the go primitive for absolute
migration to places, specified using DNS-based hostnames. The system captures
execution state at the thread level, so the agent resumes operation immediately after
the go statement. Relative migration is also possible using the meet primitive.

28
 Collocated agents can invoke each other’s methods for communication. An event
signaling facility is also available.
Telescript extensively supports security and access control. Each agent and
place has an associated authority, which is the principal responsible for it. A place
can query an incoming agent’s authority and potentially deny entry to the agent or
restrict its access rights. The agent receives a permit, which encodes its access
rights and resource-consumption quotas, among other things. The system terminates
agents that exceed their quotas and raises exceptions when they attempt
unauthorized operations. Telescript was not commercially successful, primarily
because it required programmers to learn a completely new language. General
Magic has now shelved the Telescript project and embarked on a similar, Java-
based system called Odyssey that uses the same design framework. In common with
most other Java-based systems, it lacks thread-level state capture.

• Tacoma: Tacoma is a joint project of Norway’s University of Tromsø and Cornell

University. Agents are written in “Tcl”, although they can technically carry scripts
written in other languages, too. An agent’s state must be explicitly stored in folders,
which are aggregated into briefcases. A programmer creates an agent by packing
the program into a distinguished folder called CODE, after which it stores the
agent’s intended host’s name in the HOST folder. Absolute migration to this
destination is requested using the meet primitive. The meet command names among
its parameters an agent on the destination host that can execute the incoming code
(such as the system-supplied ag_tcl, which executes Tcl scripts). The system sends
a briefcase containing the CODE, HOST, and other application-defined folders to
this agent. The system does not capture thread-level state when an agent migrates.
Therefore, the ag_tcl script restarts the agent program at the destination.
Agents can also use to meet primitive to communicate by collocating and
exchanging briefcases. Tacoma supports both synchronous and asynchronous
communication. An alternative communication mechanism is the use of cabinets,
which are immobile repositories for shared state. Agents can store application-
specific data in cabinets, which other agents then can access. No security

29
 mechanisms are implemented. For fault tolerance, Tacoma uses check pointing and
provides rearguard agents for tracking mobile agents as they migrate.
• Agent Tcl: Developed at Dartmouth, Agent Tcl allows Tcl scripts to migrate
between servers that support agent execution, communication, status queries, and
nonvolatile storage. A modified Tcl interpreter executes the scripts, allowing the
capture of execution state at the thread level. When an agent migrates, its entire
source code, data, and execution state dependent name specifying the destination. It
is also possible to clone an agent and dispatch it to the desired server. Agents have
location-dependent identifiers based on DNS hostnames, which therefore change
upon migration. Interagent communication is accomplished either by exchanging
messages or setting up a stream connection. Event-signaling primitives are
available, but events are currently identical to message. Agent Tcl uses the
Safe Tcl execution environment to provide restricted resource access. This
environment ensures that agents cannot execute dangerous operations without the
appropriate security mediation. The system maintains access control lists at a coarse
granularity—all agents arriving from a particular machine are subjected to the same
access rules. Agent Tcl calls upon an external program (PGP) to perform
authentication checks when necessary and for encrypting data in transit. However,
cryptographic primitives are not available to agent programmers.
• Aglets: Aglets is a Java-based system developed by IBM. Agents which are called
aglets in this system—migrate between agent servers (called aglet contexts) on
different network hosts. A distinguishing feature of Aglets is its callback-based
programming model. The system invokes specific methods on the agent when
certain events in its life cycle occur. For example, when an agent arrives at a server,
its onArrival method automatically executes. The programmer implements an agent
class by inheriting default implementations of these callback methods from the
Aglet class and overriding them with application-specific code.
Agent migration is absolute, because it requires specifying location-dependent
URLs for destination servers. Aglets implements mobility using Java’s object
serialization and does not capture thread-level execution state. When an agent is
reactivated at its destination, its run method executes. The programmer must

30
 implement further control flow in this method. Agents are shielded by proxy
objects, which provide language-level protection as well as location transparency.
Message-passing is the only mode of communication supported—aglets cannot
invoke each other’s methods. Messages are tagged objects and can be synchronous,
one-way, or future-reply. While the system provides a retract primitive that recalls
an aglet to the caller’s server, there is no access control on this primitive. Aglets
currently have limited security support; however, a more comprehensive
authorization framework is under development.
• Voyager: This Java-based agent system developed by ObjectSpace features a novel
utility called vcc that takes any Java class and creates a remotely accessible
equivalent, called a virtual class. Voyager can create an instance of a virtual class
on a remote host, resulting in a virtual reference that provides location independent
access to the instance. Programmers use this mechanism for implementing agents.
Voyager assigns an agent a globally unique identifier and an optional symbolic
name during object construction. A name service is available, which can locate the
agent, given its identifier or name. The virtual class provides a moveTo primitive
that lets the agent migrate to the desired location. The destination is specified either
using the server’s DNS hostname and port number or as a virtual reference to
another object with which the agent wishes to be collocated. Execution state is not
captured at the thread level, but the moveTo call specifies a particular method,
which executes when the migration is complete. A forwarder object remains in the
original location and ensures that attempts to contact the agent at that site are
redirected to its new location.
Agent communication is possible via method invocation on virtual references.
Agents can make synchronous, one-way, or future-reply type invocations.
Multicasting is also possible, because agents can be aggregated hierarchically into
groups. A simple check pointing facility has also been implemented.

• Concordia: Developed by Mitsubishi Electric, Concordia supports mobile agents

written in Java. Like most Java-based systems, it provides agent mobility using
Java’s serialization and class-loading mechanisms, and does not capture execution
state at the thread level. Each agent object is associated with a separate itinerary

31
 object, which specifies the agent’s migration path (using DNS hostnames) and the
method to be executed at each host.
Concordia extensively supports agent communication, providing for asynchronous
event signaling as well as a specialized group-collaboration mechanism. It also
addresses fault tolerance requirements via an object-persistence mechanism that is
used for reliable agent transfer and can be used by agents or servers to create
checkpoints for recovery purposes. Concordia protects agent state during transit, as
well as in persistent stores, using encryption protocols. Servers can protect their
resources using statically specified access-control lists based on user identities.
Each agent is associated with a particular user and carries a one-way hash of that
user’s password. It is not clear how this hash is securely bound to a specific agent.
Also, this mechanism only applies to closed systems, because each agent server
must have access to a global password file for verifying the agent’s password.
• Ajanta: This Java-based system developed at the University of Minnesota provides
agent mobility using Java’s serialization for state capture.7 Thus, Ajanta does not
capture thread-level execution state. Agent code is loaded on demand, from an
agent-specified server. Ajanta encrypts and authenticates these transmissions of
agent code and state using public-key protocols. It uniformly supports absolute and
relative migration and uses a name service to translate global location independent
names to network addresses. The name service also supports a public-key
infrastructure.
In Ajanta, an agent executes in an isolated protection domain, to prevent any
interference by other agents. A server protects its resources by encapsulating them
in proxy objects, which are created dynamically and customized for specific client
agents. The same mechanism can allow secure interagent communication via
method invocation. Communication across the network is also possible using
remote-method invocation. Authenticated control functions allow applications to
recall or terminate their remote agents at any time. Ajanta also addresses the
problem of protecting agent state from malicious servers. It provides cryptographic
mechanisms that let an agent’s owner secure parts of the agent’s state and detect
any subsequent tampering. Agents can also keep parts of their state private and
selectively reveal certain objects to specific servers.

32