CHAPTER 3

ANALYSIS

33
3.1 PROBLEM STATEMENT

Fig:6 Shopping Information Agent System Overview

It is a web based mobile agent system that provides users with information of product for
sale in an electronic market place. SIAS implements mobile agents to retrieve product
information in an electronic market for users. An electronic market consists of hosts that sell
products on the network. Each seller maintains a database that stores the prices and the
quantities in the stock of different products available at that store along with their
specifications. Special schemes offered for bulk buyers and discounts offered on each product
etc are also included in the database.
SIAS keeps a list of all stores in the electronic market and a list of all products available in
the market under the distinguish category. It allow users to specify a set of products and the
corresponding quantities they want to buy from the list. An agent is launched for the user who
has specified product list along with their specification and required quantity. The mobile agent
on behalf of the user will retrieve information about availability of product for specified
quantity, their price and discounts offered from various stores in the network. The path of the
agent is determined before the agent is launched, according to list of stores kept by the system.
After the agent visits all the stores specified in its itinerary, it returns to its sender and reports
the retrieved information.

34
3.2 REQUIREMENTS SPECIFICATION

A detailed Analysis has been carried out keeping in mind the certain functionalities and
requirements. These functionalities can be explained by giving the description of the following
terms:
User: is the person on whose behalf the agent would work. User need not be the developer but
will use the agent, which will carry out the task on his/her behalf.
Launch Server: is the machine on which agent resides and returns after performing the
assigned task. The user would use this machine to configure and commence the process of
agent migration to various hosts before agent returns to it.
Merchant Host: is any other machine to which agent would migrate to perform the task
assigned by the user. The user will designate the list of such hosts to which agent should
migrate. The host would also provide the agent an execution environment.
Execution Environment: For an mobile agent to migrate it has to be provided an environment
on Launch server and Merchant host machines. This functionality has to be separate for host
and home and therefore has to be developed and installed on host and home machine
separately.
Following functionality is required to be addressed in the system:
• This software should be one Launch server which is connected with client program and
receive client request for retrieving information of product for sale in electronic market
place, on receiving request it initializes the mobile agent with user specified products
and quantities.
• This software should be one mobile agent when initialized by the Launch server it is
responsible for traveling around the network and collect product information for users
from different hosts. It also keeps an itinerary, and travels through the network
according to the order of hosts in its itinerary.
• This software should have multiple clients who are connected to launch server for
sending the request for retrieval of product information on behalf of client from the
electronic market place

35
 • This software should have multiple merchant host server(for each host) which stores
the information of products available at a particular host and is responsible for
retrieving required information from database for an agent when it arrives at the host. It
can receive incoming agent, and help to agent for migrating to next destination.
• This software should be one database which is connected with merchant host server.
The mobile agents would collect data from a database. A business selling goods or
services online has therefore just to put the available products in the database, like
businesses today put products list on their web pages. Usually all e-businesses have a
database behind their web site. Here, the web site, which bridges the user to the
database, is replaced by a stationary agent. The user request is carried by a mobile
agent, like an HTTP request is carried to a web site. The difference is that the mobile
agent already contains a request when it arrives on the host, whereas with HTTP, a
client has to connect to the web site, make his choice and request the goods.

3. 3.3 FEATURES OF PROPOSED SYSTEM

3.3.1 Service Oriented Architecture
A service-oriented architecture is an information technology approach or strategy in which
applications make use of services available in a network such as the World Wide Web.
Implementing a service-oriented architecture can involve developing applications that use
services, making applications available as services so that other applications can use those
services, or both.
What distinguishes an SOA from other architectures is loose coupling. Loose coupling means
that the client of a service is essentially independent of the service. The way a client (which
can be another service) communicates with the service doesn't depend on the implementation
of the service. Significantly, this means that the client doesn't have to know very much about
the service to use it. For instance, the client doesn't need to know what language the service is
coded in or what platform the service runs on. The client communicates with the service
according to a specified, well-defined interface, and then leaves it up to the service
implementation to perform the necessary processing, If the implementation of the service
changes.

36
3.3.2 Using Web Services as 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. A web service
is a service that communicates with clients through a set of standard protocols and
technologies. These web services standards are implemented in platforms and products from all
the major software vendors, making it possible for clients and services to communicate in a
consistent way across a wide spectrum of platforms and operating environments. This
universality has made web services the most prevalent approach to implementing an SOA.

3.3.4 Interoperability issue: Creation of Web Services from source code implementations can
lead to interoperability issues across platforms. For example, a service that uses Java remote
references is not interoperable with a .NET-based client. .NET simply has no understanding of
what to do with a java remote reference. Using a Web Services design methodology these
interoperability issues can be avoided since both client and server are working from a common
set of XML schema types.
Service producers and consumers can work in parallel. By defining the Service interface as
WSDL, client-side developers can work independently of server-side developers. The client-
side and server-side do not even need to use the same development language thus significantly
increasing the number of developers who can participate in distributed application
development.

37
3.3.3 Suitability for distributed systems: Mobile agent technology makes distributed
application easier to manage and program as the agent environment does things a developer
would have to program with a traditional architecture. While in TCP/IP, the developer has to
deal with OSI layers, from the transport layer when programming sockets to the application
layer, Tracy deals with transport, session and presentation layers, and so the developer only has
to build his application on top of it.

Fig:6 Comparison of Mobile agent system, OSI, TCP/IP

Figure 8 shows how Tracy fits within the OSI model (the Tracy environment is in green) and
shows the details of the Tracy layers themselves in comparison to OSI and TCP/IP. But it
doesn’t mean that the developer cannot interact with Tracy: the developer can make some
choice, such the transmission strategy (net transmission layer), or the migration strategy to use
(package process management layer).

38
3.5 USE CASE DIAGRAMS
3.5.1 Use Case Diagram

Error!

Validate: user
System <<extend>>
name/passwrd
Startup

New User Request price

Registration information

<<extend>>
User New Session
Login
Http server

Product selection

View Price Info

Update Merchant
Administrator Host Info

Update Product
List/Specn.
Launch Server

Process user
<<include>> request/response

Process
Information

<<include>>
Initialize
Mobile Agent

Fig :7 Use Case Diagram of SIRS

39
3.5.2 Use Case Diagram:

The Use Case diagram is used to identify the primary elements and processes that form the
application or a system. The primary elements are termed as "actors" and the processes are
called "use cases." The Use case diagram shows which actors interact with each use case. The
use case diagram for our system is in fig .
Use cases are organized by specifying generalization, include, and extend relationships among
them. Generalization among use cases is means that the child use case inherits the behavior and
meaning of the parent use case. An include relationship between use cases means that the base
use case explicitly incorporates the behavior of another use case at a location specified in the
base. The extend relationship is used to model the part of a use case the user may see as
optional system behavior.

3.5.2.1 Actor

An actor portrays any entity (or entities) that performs certain roles in a given system. The
different roles the actor represents are the actual business roles of users in a given system.
Typically, an actor represents a role that a human, a hardware device or even another system
plays with a system. An actor in a use case diagram interacts with a use case outside a system
boundary.
Actors are further classified as Primary and Secondary actors, for the proposed system
following are identified as Primary and Secondary actors:
Primary Actors: The Actors who are going to use the system directly we call Primary actors.
Following Primary Actors are identified in the system:
• User
• Administrator
Secondary Actors: There are actors supervising and maintaining the functioning of the system.
we call them Secondary Actors. The Secondry Actors exist only so that the primary actors can
use the system. Following secondary actors are identified in the system:
• Http Server
• Launch Server

40
3.5.2.2 Use Cases for SIRS
A use case in a use case diagram is a visual representation of distinct functionality of processes
in a system. These processes are discrete in nature. Each of these distinct functions can be a
potential use case. Following use cases are identified in the system:
• System Startup Use Case : The system is strated by administrator .Once the system is
started any client can access the services of the system through the network.
• New User Registration Use Case: Every new user required to register himself by
entering his/her personnel information along with login and password
• New Session login Use Case: A new session is started when user login and password is
validated by the Http Server. for every new request for information retrieval user need
to start a new session. disconnection with the server leads to end of session and user has
to restart the session.
• Product Selection Use Case: Selection of the product is made by the user by selecting
the category of products from the list of categories, and then selecting the individual
product from the list of available products, each product has its specification and image
to facilitate user to choose right product from the list. Qty required for each item is also
required to be entered by the user. different items belongs to different categories can be
selected in single session. once the selection is made can be deleted before submitting
the request. once the request for price information is submitted, change in the selected
product list is nit permitted. However a separate session can be started for the new
requirement.
• View Price information Use Case: user request along with product list, qty and
specification is forwarded top launch server by the http server and after receiving
respone for the given request, retrievd information is processed by http server for the
product list and displayed in the tabular format to facilitate the user for making
economical shopping decision.
• Merchant host information Updation Use Case: For every product displayed in the
product list of each category a corresponding list of merchant hosts, who sells the
specified product in the electronic market place, is maintained by the http server . This
list required to be updated time to time as and when new potential sellers are located in

41
 the electronic market place .the task of updation of merchant hosts is performed by the
administrator.
• Product List and Specification Updation Use Case: rapid growth of B2C e-
commerce, lots of products and services are added for sale in electronic market place on
day to day basis. Thus to enhance the capability and functionality of the system,
category and corresponding product list is required to be updated time to time. The task
of updation of category and product list is performed by the administrator.
• Process User’s Request/Response Use Case: Once the user has submitted his/her
request for information retrieval of selected product, it is the responsibility of the http
server to process the request .http server attach the list of merchants required to visit by
the mobile agent for individual product selected by the user, and forward the request to
launch server to initialize the mobile agent and launch it to retrieve the desired
information on behalf of client as soon as the retrieve information passed to http server
, the information is processed and convert it to presentable form and display for user’s
view.
• Initialize mobile Agent Use Case: Launch server receives the request from http server
with list of merchant host and user’s provided data that is product list, quantity, and
specification. Launch server initialize the mobile agent with name of the product, qty
and itinerary for visiting merchant host in the network and launch the mobile agent into
the network. Mobile visits all the hosts specified in its itinerary and reach back to home
and deliver the retrieved information. Launch server process the information and
forward it to http server for display it to respective user.

3.5.2.3 System boundary:

stem boundary defines the scope of what a system will be. A system cannot have infinite
unctionality. So, it means that use cases also need to have definitive limits defined. A system
boundary of a use case diagram defines the limits of the system

42