Analysis Chapter 3

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 clientside 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! <<extend>>

System Startup

New User Registration

Validate: user name/passwrd

Request price information <<extend>>

User

New Session Login Http server Product selection

View Price Info

Administrator

Update Merchant Host Info

Update Product List/Specn. Launch Server Process user request/response

<>

Process Information

<> 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 ecommerce, 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