Software Installation on a Network using Mobile Agents
Chapter 1
INTRODUCTION
This chapter introduces the mobile agents and a brief explanation to why this project is carried out and the disadvantages of traditional approaches for software installation.
1.1 Introduction to Mobile Agents
Mobile agents emerged in the mid-1990s, and have raised considerable interest in the research community. The proponents associate several benefits with their use. However there are very few quantitative measurements to back the claimed benefits.
Dictionary meaning: An agent is a person who acts for, or who manages the business affairs of another, for example, travel agents (road, air), house broker agents, etc.
Software Agents are the autonomous programs (piece of code) situated within an environment (machine, network devices), which sense the environment, and acts upon it using its knowledge base to achieve their goals.
A Stationary Agent is one that executes only on the system where it begins execution. If it needs information that is not on that system or needs to interact with an agent on a different system, it typically uses a communication mechanism such as remote procedure calling (RPC).
A Mobile Agent is a specific form of mobile code that consists of the program code and the program execution state (the current values of variables, next instruction to be executed, etc.) with the unique ability of transporting themselves (state and code) from ones system in a network to another. A mobile agent is not bound to the system where it begins execution.
The agents have certain attributes associated with them that distinguish them from the standard programs. They are categorized into two types:
➢ Mandatory properties and
➢ Orthogonal (optional) properties.
A. Mandatory Properties
The mandatory properties provide weak notion of agents. The mandatory properties of an agent are as follows:
Autonomy: agents operate without the direct intervention of humans or others, and have some kind of control over their actions and internal state.
Reactivity: agents perceive their environment, and respond in a timely fashion to changes that occur in it.
Proactive: agents exhibit goal-directed behavior by taking the initiative.
Adaptive: agent is capable of adjusting itself to user/environment using either rules or some form of preferences.
Temporal continuity: agents are continuously running processes (either running active in the foreground or sleeping/passive in the background).
Goal oriented: an agent is capable of handling a task to meet its desired goal.
Believable: the created/dispatched agent should be trust worthy.
B. Orthogonal Properties
The orthogonal properties provide strong notion of the agents. The orthogonal properties of agents are as follows:
Mobility: agents are capable of roaming around in an electronic network.
Collaborative: an agent should be capable of computing the desired tasks of the user/process by cooperating with other agents, sometimes it may refuse to execute certain tasks.
Learning: agents can learn the environment factors, user preferences, etc., and develop certain degree of reasoning to take intelligent decisions/actions. Learning mechanisms could be: reinforcement learning; neural networks; user training by examples.
Communicative: agents interact with other agents and (possibly) humans via some kind of agent communication language.
Inferential capability: agents are able to share a set of knowledge in order achieve a specific goal.
Rationality: agents embody (give visible form to idea) the capacity to analyze and solve a problem in a rational (ability to think logically) manner.
1.2 Generic Mobile Agent Architecture
The generic mobile agent architecture is shown in the Figure 1.1. The following components provide a framework for operating and managing agents:
Agent manager: it sends and receives the agents, reconstructs the received agent and creates its execution context, allows received agent to migrate whenever they want using agent transport protocols (either through TCP/IP or E-mail).
Agent execution environment: facilitates agent to execute its code
Security manager: protects host from unauthorized access from mobile agents, authenticates between mobile agent systems through exchange of certificates and firewalls, and encrypts mobile agents.
Reliability manager: it shields agent from system and server crashes using some fault tolerance techniques like storing the agent on secondary disk (guarantees persistence). Inter-agent communication manager: facilitates communication among agents.
Application gateway: provides secure entry point through which agent can interact with application servers.
Directory manager: facilitates agents to identify the location of an intended application server and then migrate to that host on which server is located.
[pic]
Figure 1.1. Generic Mobile Agent Architecture.
1.3 Agent Platforms
The following are some of the platforms for developing and managing agents:
1.3.1 TACOMA (Tux)
Supports coding of agents in C, Tcl/Tk, and Scheme. It supports coding of stationary and mobile agents, agent transport mechanisms, interagent communication, and agent security.
1.3.2 Agent TCL
Agents are written in the Tool Command Language (Tcl), Supports coding of stationary and mobile agents (stationary agents can be coded in C/C++), agent migration, message passing, and direct connection to agents, agent creation, agent cloning, and agent security.
1.3.3 Mole
Agents are coded by using Java objects. It supports agent migration, interagent communication by using messages and remote procedure calls, and directory services.
1.3.4 Grasshopper
Allows agents to be coded in Java. It provides communication infrastructure through Java-RMI (Remote Method Invocation) and also CORBA ORB protocol, agent migration, persistence to agents, security to agents through X.509 certificates and digital signatures, directory services and agent tracking.
1.3.5 Voyager
The Voyager agent platform is based on the concept of a collection of Java objects. It supports agent migration, interagent communication by using RMI, configurable security mechanisms, directory services, agent tracking, and dynamic proxy generation.
1.3.6 Concordia
The platform uses Java based agents. It supports agent mobility, persistence, security, event based communication, controlled resource access, directory services, encryption of agent during transit, compression of agent during transit, and graphical agent debugger.
1.3.7 Odyssey
The agents are coded as Java objects in this agent platform. It supports interagent communication either by using RMI or CORBA ORB or DCOM (Distributed Component Object Model), and agent migration.
1.3.8 IBM Aglets Work Bench (AWB) - “agent + applet”
Written in Java, Supports persistence of agents, agent migration, security, communication messaging either by using proxy or by direct messages, collaboration and web enabled agents, directory services and agent tracking.
1.4 Mobile Agents for Software Installation
While mobile agents have generated considerable excitement in the research community, they have not translated into significant number of real world applications. One of the main reasons for this is the lack of work that quantitatively evaluates (1) The effectiveness of mobile agent framework and (2) The effectiveness of mobile agents versus traditional approaches. This project aims at contributing towards such an evaluation.
Personal computers now run a wide range of applications each serving one or more users. Each application to get executed on the system requires it to be installed; that involves writing the necessary data on system drive for running the program. Installing the required application using traditional software installation on a single node or on few is not a difficult task but when required to install on several node’s (e.g. Networked computers in Educational institutions, Organizations etc) is boring and time consuming job. In the domains such as telecommunications, where systems are spread over the wide area of networks, it is very complicated to perform software installation by visiting each and every node.
The following are the disadvantages of traditional approaches for software installation
← It requires lot of human intervention,
← It is time consuming process,
← It requires additional physical media like CD-ROM, Flash drive etc and
← It is difficult to manage software applications over multiple PC’s.
The proposed architecture makes use of Aglets Software Development Kit (ASDK) 2.0.2 which is a Java based framework and environment for researching and developing mobile agents in JAVA in developing this system. Tools like “EMCO Microsoft Installer (MSI) Package Builder” can be used to create software images.
1.5 Summary
This chapter provided a brief introduction to Mobile Agents, its properties, architecture, and various platforms for developing mobile agents. To overcome the disadvantages of traditional approaches for software installation the proposed system makes use of mobile agent paradigm to automate software installation over a network.
Chapter 2
LITERATURE SURVEY
This chapter will discuss the related work done by some of the researchers on software deployment process using different technologies. During the last decade enhancement in Mobile Agent Systems (MAS) makes this field very pertinent to the research community. Each year the agent platforms are getting robust and reliable due to increased demand in this technology.
2.1 Related Work
The software deployment is a complex procedure that involves the release, installation, adaptation, reconfiguration, update, activation, deactivation, retirement and removal of software. The following are some of the existing technologies [1] that support various aspects and activities of the software deployment process.
A. Installation Tools
Generate a set of executable and artifact files that must be downloaded or provided via a distribution media like a CD, or via Internet. These files can be compressed in a single installation executable file. In order to install the system, the installation software needs to be executed in the customer site. One example of these tools is the InstallShield installation tool that generates a self-extractor file that manages the installation and de-installation procedures of an application. This InstallShield is for software developer to build reliable Windows Installer (MSI) and InstallScript installations for desktop, server, Web, mobile applications [2] and not to install a software program on computers.
Drawbacks: These tools are usually platform specific, and allow a minimal degree of configuration on what components to install.
B. Package Managers
These installation tools use the concept of packages. A package is an archive that contains the files that constitute a system together with some meta-data describing the system. The packages have to be copied to the customer site in order to be installed. Some package managers provide file transfer capabilities. Once in the system, the package is installed by the package manager. An example of a package tool is the Red Hat RPM.
Drawbacks: These tools usually do not provide activation and deactivation capabilities and some of them allow a primitive policy specification.
C. Application Management Systems
These kinds of systems generally support all of the life cycle activities except the producer-side release activity. Their architecture is generally centralized. These systems were designed to manage the software deployment in large or medium organizations that both produce and consume software. In these systems, a central server typically controls all management and deployment activities. An example of such application is the System View from IBM.
Drawbacks: These technologies don’t allow both the transportation and execution of the installation software in a more customizable way.
In this paper, although no implementation is provided some ideas concerning the use of mobile agents in software deployment process, issues and requirements, benefits and drawbacks are discussed. Programming Mobile agents to request the installation files according to current configuration of system instead of getting all installation files at once is perhaps basic idea to our work. The paper also advocates the use of interpreted languages like java to achieve platform independence. The author suggests a Hybrid policy to overcome lower internet speeds.
The reference [3] discusses some previous works that focus to deal software deployment problems in clusters.
I. Disk image-based deployment
Disk image-based deployment approach was designed for deploying operating system. SystemImager provide tools for acquirement, management and deployment of system images. The deployment of image is centralized and all node’s obtain image from the image server by using the remote replication tool rsync. OSCAR (Open Source Cluster Application Resource) composed of Software Suite which can be easily integrated and installed, provides a set of construction, management, maintenance and high-performance cluster tools.
Drawbacks: Poor Flexibility
II. Behavior-based deployment
The basic idea is to record all of the disk operations during the software deployment and the software installation process can be replayed. It is required to trace the kernel operation of installation process. ZSDT (Zju Software Delivery Toolkit) can automate software deployment in all aspects, including planning, implementation, reporting.
Drawbacks: Tracing the kernel operation of installation Process is difficult to realize.
III. Package-based deployments
XcelleNety use Prism Deploy for Software distribution. Prism Deploy create packages which contain State information including file system, registry settings, and other information. Prism Deploy also supports the distribution of Microsoft installer (Msi) package format. This uses the idea of batch process. It writes all the commands that are implemented during the installation process in a batch file. When deploying software on the target node, we should send the installation package and batch file to the target, and then execute the batch commands. This method is flexible.
Drawbacks: Hard to solve the interactive installation, because some software needs to interact with the administrator/user during installation process.
In paper [3], the method “NOVEL SOFTWARE DEPLOYMENT SYSTEM” focuses on how to deal with deploying software automatically in large scale Linux based clusters. The author feels that his method improves Package Based Deployment methods which are highly flexible. Phases included in deployment process are clearly discussed. The Linux installation processes are identified and handled accordingly. Interactive installation procedure which is a complex task is achieved through Script and Expect tools. This proposed method for Linux based systems is closest to our work. The author also mentions his method lacks stability and there are some random factors, so when deploying software by using the automatic deployment system, there may be individual failure.
The reference [4], describes a system that performs software installation on a heterogeneous network using mobile agents which is closest to our own work. This system is suited only for installation of mandatory software: which means only similar software can be installed on entire network. Individual node’s over LAN cannot be handled. Two separate Mobile agents AgentController and Agent are used for software installation. Creating N clones of AgentController for N entries in Inter tablets and M Agents for M entries in Intra table increases network traffic and gets worse if the installation software or node’s in network is large also the setup files has to be carried to the destination host.
In paper [5], the authors propose a system that makes use of Remote Maintenance Shell (RMS) framework for the maintenance of the operating or newly installed software in the remote system by using mobile agents. Software operations and all maintenance actions are performed by mobile agents in the RMS management station. Installation Dock unit in the system supports software installation by receiving and storing installation files which are brought by Installation Agent. Remotely operated/installed softwares must be designed in compliance with RMS specification and delivered to the target system enveloped with Application Testbed serving as an interface between software and Maintenance Environment which makes this system complicated.
2.2 Summary
This chapter provided the related work done by some of the researchers on the software deployment process using different technologies and their drawbacks. The proposed system will be feasible approach for installing required software on windows based node’s over network using mobile agents.
Chapter 3
MOTIVATION AND PROBLEM DEFINITION
This chapter discusses the motivation to carry on with the work in this area, and problem definition followed by the chosen approach and scope of the project.
3.1 Motivation
The disadvantages of existing systems mentioned in the above two chapters and the advantages of Mobile Agents [6] discussed below has motivated to carry on with this work. The reason for using mobile agents in software installation comes from the following aspects:
First, mobile agents reduce the need for bandwidth. Installing softwares over distributed systems often rely on communication protocols involving multiple interactions to accomplish a given task. The result is a lot of network traffic. Mobile agents allow users to package a conversation and dispatch it to a destination host where interactions take place locally.
Second, mobile agents are asynchronous. Therefore when a mobile agent is dispatched there is no need to wait for it to return. Indeed the server and clients does not even need to remain connected all the time to the network while the mobile agents are out. Thus the dispatched mobile agent operates asynchronously, finishes its task and informs the server agent while disposing.
Third, mobile agents are autonomous. Software Installation tasks can be embedded into mobile agents, which can then be dispatched into the network. After being dispatched, the agents become independent of the process that created them and operates autonomously.
Fourth mobile agents can adapt dynamically. Mobile agents can sense their execution environment and react autonomously to changes. When multiple mobile agents are created to install softwares over multiple hosts, they have the unique ability of distributing themselves among the hosts in the network to maintain the optimal configuration for solving a particular problem.
Fifth, multiple mobile agents may easily be created and dispatched in different directions. This allows them to function in parallel. Although this causes more mobile agents to be active on the network, it does ensure that the network resource discovery is completed sooner, and therefore the mobile agents spend less time on the network.
Sixth, mobile agents are robust and fault-tolerant. Even if some of the mobile agents are destroyed, all surviving ones will have no negative impact.
Finally, a mobile agent based software distribution/installation system can be feasible solution over other software distribution/installation systems.
3.2 Problem Definition
The proposed effort investigates the feasibility of applying agent technology to Software Deployment process. The goal of this work is to automate software installation on windows based node’s in the network. InstallAgents are created and configured by Software Installation on a network Using Mobile Agents (SIUMA) Server that dispatch to their destination and perform software installation. InstallAgent after successful completion reports to SIUMA Server and disposes at destination.
3.2.1 Project Approach
SIUMA System was developed using JDK-1.5.0 update 22 and ASDK 2.0.2. This framework is used to perform Software Installation which is an activity of Software deployment process on windows based node’s in the network. Modular approach is used for developing this system and is organized into five modules as mentioned below:
A. Administrator Module,
B. SIUMA Server Module,
C. SIUMA Client Module,
D. SoftwaresOnDestination Module and
E. InstallAgent Module.
Administrator is responsible for selecting remote node’s and softwares to install. Administrator can make use of Msi package builders to record software installation process and create setup images.
SIUMA Server is responsible for creating and configuring SoftwaresOnDestination agent, InstallAgent with destination node’s addresses, server address, and list of softwares to install. Multiple InstallAgents are created when Administrator chooses to install softwares on multiple systems at a time.
SIUMA Client is installed on all remote node’s which is responsible for accepting the SoftwaresOnDestination agents, InstallAgents and allocate resources for them to perform their task.
SoftwaresOnDestination is an agent created and configured by SIUMA Server when Administrator needs to obtain remote node’s system details, list of software and drivers installed on it. SoftwaresOnDestination agent dispatches to the specified remote node, retrieves the System information, list of softwares and drivers installed, reports to Administrator and disposes.
InstallAgent is an agent created and configured by SIUMA Server when administrator needs to perform Software Installation. InstallAgent dispatches to specified node, adds server to destinations Trusted Sites Zone, establishes connection to server, and performs Software Installation. Status of installation is reported to Administrator and after completion of its task server is removed from destinations Trusted Sites Zone, disconnects destination from server and disposes on destination.
3.2.2 Scope of SIUMA System
SIUMA System is developed to perform software installation which is an activity of software deployment process, retrieve remote node’s system details and list of softwares and drivers installed on remote node’s using a mobile agent which is an activity of software systems management. SIUMA System is developed for Microsoft Windows operating systems (Windows XP, Windows 7).
3.3 Summary
This chapter discussed the advantages of mobile agents that motivated to work in this area. Modular approach has been chosen to develop the proposed system by making use of JDK-1.5.0 Update 22 and ASDK-2.0.2. The proposed system must be able to automate the software installation process, retrieve remote node’s system details and list of softwares and drivers installed on remote node.
Chapter 4
REQUIREMENT SPECIFICATION
This chapter specifies the Software Requirement Specification (SRS) for the proposed SIUMA System. SRS is the way to represent requirements in a consistent format which is very important activity after the requirements elicitation/gathering and analysis. The SRS document contains the following aspects of the system:
➢ Functional Requirements.
➢ Non-Functional Requirements.
4.1 Functional Requirements
Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. SIUMA System is organized into five modules. The following is the list of SIUMA System modules:
A. Administrator Module,
B. SIUMA Server Module,
C. SIUMA Client Module,
D. SoftwaresOnDestination Module and
E. InstallAgent Module
The Figure 4.1 depicts the functional overview of SIUMA System.
A. Administrator Module
The operations carried out by the Administrator are as follows:
➢ Create Software Images,
• Run EMCO Msi package builder
• Select the software setup file
• Create the Software Image
➢ Initiate Software Installation,
➢ Run SIUMA Server,
➢ Provide destination addresses,
➢ Provide SIUMA Client port address,
➢ Retrieve destination system details, list of softwares and drivers installed,
➢ Select the softwares to install,
➢ Administrator can now choose to perform software installation on a single system or multiple systems or on selected systems, and
➢ Obtain installation reports.
Software images are created by Administrator using EMCO Msi package builder to eliminate human intervention at the remote node during the process of software installation.
[pic]
Figure 4.1. Functional overview of SIUMA System.
B. SIUMA Server Module
SIUMA Server must be installed on home machine and Administrator makes use of SIUMA Server to perform software installation. SIUMA Server on the home machine starts Engine usually Java Virtual Machine when Administrator executes SIUMA Server which in turn runs Tahiti aglet which is a java application that allows Administrator to receive, manage send the agents to remote node’s that are running SIUMA Client by allocating resources like databases, processors, other services provided by the home machine. The Engine provides a context in which agents can execute. Tahiti aglet on its startup creates SIUMAServer aglet which provides an interface between Administrator and SIUMA System. The framework of SIUMA Server is shown in the Figure 4.2.
The operations carried out by the SIUMA Server are as follows:
➢ Obtain destination address,
➢ Obtain SIUMA Client port address,
➢ Creates SoftwaresOnDestinationAgent agent if Administrator wants to retrieve system details, list of softwares and drivers installed on the remote node,
➢ Configures the selected software files to be available for agents that dispatch to remote node’s,
➢ Creates InstallAgents if Administrator wants to perform software installation,
➢ Collects the installation status, error messages, if any, and
➢ Reports to the Administrator
Depending on the number of remote node’s the Administrator selects, SIUMA Server creates equivalent number of InstallAgents to perform software installation one for each remote node.
C. SIUMA Client Module
SIUMA Client must be installed on all remote node’s in the network. SIUMA Client on the remote node starts Engine usually Java Virtual Machine at the system startup which in turn runs Tahiti aglet which is a java application that manages the agents coming from the SIUMA Server by allocating resources like databases, processors, other services provided by the remote node. The Engine provides a context in which agents can execute. The framework of SIUMA Client is shown in the Figure 4.3.
The operations carried out by the SIUMA Client are as follows:
➢ Accepts the agents from SIUMA Server,
➢ Provides a context in which agents can execute,
➢ Allocates the resources, and
➢ Allow agents to perform its tasks.
[pic]
Figure 4.2. Framework of SIUMA Server.
D. SoftwaresOnDestinationAgent Module
SoftwaresOnDestinationAgent is an agent created and configured by SIUMA Server when Administrator needs to obtain remote node’s system details, list of software and drivers installed on it. SoftwaresOnDestinationAgent agent dispatches to the specified remote node, retrieves the System information, list of softwares and drivers installed, reports to Administrator and disposes at destination.
The operations carried out by the SoftwaresOnDestinationAgent are as follows:
➢ Obtain destination node address,
➢ Obtain SIUMA Client port address,
➢ Dispatch to destination Retrieves system information and list of softwares and drivers installed on remote node,
➢ Report to SIUMA Server, and
➢ Dispose at remote node.
[pic]
Figure 4.3. Framework of SIUMA Client.
E. InstallAgent Module
InstallAgent is an agent created and configured by SIUMA Server when administrator needs to perform Software Installation. InstallAgent dispatches to specified node, adds server to destinations Trusted Sites Zone, establishes connection to server, and performs Software Installation. Status of installation is reported to Administrator and after completion of its task server is removed from destinations Trusted Sites Zone, disconnects destination from server and disposes at destination.
The operations carried out by the InstallAgent are as follows:
➢ Obtain destination node’s address,
➢ Obtain SIUMA Client port address,
➢ Obtain server system address,
➢ Obtain list of softwares to be installed at remote node,
➢ Dispatches to destination,
➢ Adds SIUMA Server system to remote node’s Trusted Sites Zone,
➢ Establishes connection to SIUMA Server system,
➢ Perform software installation,
➢ Report installation status to SIUMA Server,
➢ After completion of its task InstallAgent removes SIUMA Server system from remote node’s Trusted Site Zone,
➢ Disconnects from SIUMA Server, and
➢ Dispose at remote node.
The functionalities of each module of SIUMA System are mentioned above and a graphical representation of functional requirements of SIUMA System is shown in the Figure 4.4.
4.2 Graphical representation of Functional requirements of SIUMA System
[pic]
Figure 4.4. Graphical representation of Functional requirements of SIUMA System.
3. Non-Functional Requirements
A non-functional requirement is a statement of how a system must behave; it is a constraint upon the systems behavior. Non-functional requirements specify all the remaining requirements not covered by the functional requirements. They specify criteria that judge the operation of a system, rather than specific behaviors and the system’s ‘quality characteristics’ or ‘quality attributes.
The following are the non-functional requirements of SIUMA System.
▪ User-friendly nature of the System: The developed application should be easy to understand and use. Even people who are using the system for the first can easily master the usage of the system.
▪ Flexibility: The system should be flexible to accommodate future changes. This is best possible because the various functions of the system are modular.
▪ Performance: The time taken to return a list of results during its execution should be as low as possible. The user should not have to wait for long to get the output.
▪ Extensibility: The system should allow changes to be made, so as to bring in new features in the future.
▪ Maintainability: The System should be easily modified to correct faults and improve its performance with its error reporting mechanism.
▪ Reliability: The system should have high probability to deliver required functionalities available in the application.
▪ Security at Home Machine: This system should provide security for the contents at the Home Machine by configuring file permissions. Thus preventing Home Machine from being misused.
4.4 Summary
This chapter provided the SRS documentation that described the behavior (functional requirements) of the system and how a system must behave (non-functional requirements). The proposed system is divided into Administrator module, SIUMA Server module, SIUMA Client module, Softwares on Destination Agent module and Install Agent module and functionalities of each of these modules are discussed in detail.
Chapter 5
DESIGN AND ARCHITECTURE
This chapter discusses the design, architecture overview and the different hardware and software the SIUMA System will require, and the activities involved in specifying how the system will actually work.
5.1 Design
The design phase specifies how the systems components are arranged and their features. The system components are delivered from Requirement Specifications phase. The design phase frequently described as being divided into two main phases, which might be described as follows:
♣ High Level Design and
♣ Low Level Design
1. High Level Design
High level design specifies the abstract view of the system through the following techniques:
➢ Data Flow Diagrams (DFD) and
➢ Flowcharts.
5.1.1.1 Data Flow Diagrams
The DFD (also called as the bubble chart) is a simple graphical formalism that can be used to represent a system in terms of the input data to the system, various processing carried out on these data, and the output data generated by the system. The main reason why the DFD technique is so popular is probably because of the fact that DFD is a very simple formalism-it is simple to understand and use. A DFD model uses a very limited number of primitive symbols shown in the Figure 5.1.
[pic]
Figure 5.1. Primitive symbols used in Data Flow Diagrams.
A. Level 0 DFD for SIUMA System
The Level 0 DFD diagram is the most abstract data flow representation of the system. It represents the entire system as a single bubble. This bubble is labeled according to the main function of the system. The various external entities with which the system interacts and the data flows occurring between the system and the external entities are also represented. The data input to the system and the data output from the system are represented as incoming and outgoing arrows. These data flow arrows should be annotated with the corresponding data names. The name context diagram is well justified because it represents the context in which the system is to exist i.e. the external entities (users) who would interact with the system and the specific data items they would be supplying to the system and the data items they would be receiving from the system. The level 0 DFD is also called as Context diagram. The Figure 5.2 depicts the Level 0 DFD for the SIUMA System.
[pic]
Figure 5.2. Level 0 DFD for SIUMA System.
B. Level 1 DFD for SIUMA System
Level 1 DFD are used to represent high level functional requirements. We can examine the input data to these functions and the output data by these functions and represent them appropriately in the diagram. The Figure 5.3 depicts the Level 1 DFD for the SIUMA System.
[pic]
Figure 5.3. Level 1 DFD for SIUMA System.
5.1.1.2 Flowcharts
Flowchart is a technique used to show how the project was planned, show the correct sequence of events of a particular operation and provides documentation of design decisions before building the application. Each stage of the project is set out as a sequence of events. The following flowcharts show the sequence of events for the respective modules.
A. Flowchart for Administrator
A flowchart is shown in the Figure 5.4 for the Administrator of SIUMA System.
[pic]
Figure 5.4. Flowchart for Administrator Module.
B. Flowchart for SIUMA Server
A flowchart is shown in the Figure 5.5 for the SIUMA Server of SIUMA System.
[pic]
Figure 5.5. Flowchart for SIUMA Server Module.
C. Flowchart for SIUMA Client
A flowchart is shown in the Figure 5.6 for the SIUMA Client of SIUMA System. SIUMA Client is installed on remote node’s over the network and is configured to be running at the startup of the remote system. SIUMA Client accepts the agents from SIUMA Server and allocates context/place, resources and allows the agents to perform their tasks.
[pic]
Figure 5.6. Flowchart for SIUMA Client Module.
D. Flowchart for SoftwaresOnDestinationAgent
A flowchart is shown in the Figure 5.7 for the SoftwaresOnDestinationAgent of SIUMA System.
[pic]
Figure 5.7. Flowchart for SoftwareOnDestinationAgent Module.
E. Flowchart for InstallAgent
A flowchart is shown in the Figure 5.8 for the InstallAgent of SIUMA System.
[pic]
Figure 5.8. Flowchart for InstallAgent Module.
2. Low Level Design
Low level design specifies the detailed view of a system. Object-oriented approach is used in modeling a system because it has proven to be of value in building systems in all sorts of problem domains and encompassing all degrees of size and complexity. Also object-oriented development provides the conceptual foundation for assembling systems out of components. Unified Modeling Language (UML) is used in modeling the low level design of SIUMA System. The following are UML diagrams that visualize the SIUMA System from different perspectives.
A. Class Diagram
A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. Graphically class is rendered as a rectangle usually including its name, attributes, and operations. A class diagram shows a set of classes, interfaces, and collaborations and their relationships addressing the static design view of a system. The Figure 5.9 depicts the class diagram of SIUMA System.
[pic]
Figure 5.9. SIUMA System class diagram.
B. Object Diagram
Objects are essentially reusable software components that model pieces of software in terms of properties (such as name, color and size) and behaviors (such as calculating, moving, and communicating). An object diagram shows a set of objects and their relationships that represent static snapshots of instances found in class diagram. These diagrams address the static design view or static process view of a system as do class diagrams, but from the perspective of real or prototypical cases. An object diagram consists of objects that collaborate, but without any of the messages passed among them. The Figure 5.10 depicts the object diagram that freezes a moment in time of SIUMA System.
[pic]
Figure 5.10. SIUMA System object diagram.
C. Use Case Diagram
Use Case is a description of set of sequence of actions that a system performs yielding an observable result of value to a particular actor. A use case is realized by a collaboration and is used to structure the behavioral things in a model. Use case diagram shows a set of use cases and actors (a special kind of class) and their relationships. Use case diagrams address the static use case view of a system and are especially important in organizing and modeling the behaviors of a system. The Figure 5.11 depicts the use case diagram of SIUMA System.
[pic]
Figure 5.11.1. Use Case diagram for SIUMA Server of SIUMA System.
[pic]
Figure 5.11.2. Use Case diagram for SIUMA Client of SIUMA System.
D. Sequence Diagram
A Sequence diagram emphasizes the time ordering of messages. A Message is a specification of a communication between objects that conveys information with the expectation that the activity will ensue. The Figure 5.12 depicts the Sequence diagram of SIUMA System.
[pic]
Figure 5.12. Sequence diagram for SIUMA System.
5.2 Architecture overview
SIUMA System consists of Home Machine that contains setups of the softwares to be installed and several hosts connected to LAN. SIUMA System requires onetime installation of the SIUMA Server at Home machine and SIUMA Client at each node in the network and network connection, at least during the time necessary for the agent migrate to the node and collect all artifacts for the installation. After that, the dispatched mobile agent can perform the installation process without the network connection presence. Agents are created and configured at the home machine by SIUMA Server which on creation dispatches to specified node running SIUMA Client and on its arrival to the destination node will start execution. The time required by a single agent to install the required software on all the node’s over the network is very high. The alternative is to create multiple agents (N agents for N node’s) to perform the task. The security is provided by configuring java.Policy file. The dispatched agent reports to administrator after successful completion of its task. A log history is maintained by SIUMA Server which records all the activities right from the start of installation till the end. The Figure 5.13 depicts the architecture overview of the proposed SIUMA System.
[pic]
Figure 5.13. Architecture overview of SIUMA System.
5.3 Implementation and Deployment Requirements
Hardware Requirements (Minimal)
Processor: Pentium 2.4 GHz
Disk space: 200 MB
RAM: 1 GB
Monitor: Standard Color
Key board: Standard
Software Requirements
Programming Language: Java 1.5
Modeling Language: UML
Specifications: IBM Aglets 2.0.2, J2SE (Java2 Standard Edition)
Tools: NetBeansIDE 6.8.1, Rational Rose 98, EMCO 4.4.5
Operating System: Windows XP or Windows 7
Other Requirements
• Network connectivity for home machine and remote node’s.
• Tahiti Client to be running on the remote node’s.
5.4 Summary
This chapter provided the design for the proposed system specifying the arrangement of the system components and their features. High level design (includes DFD and Flowcharts) and Low level design (includes UML Diagrams) are used for better viewing the system components. The architecture of the proposed system, the implementation and deployment requirements are also discussed.
Chapter 6
IMPLEMENTATION
This chapter discusses the implementation technologies including, programming languages, platforms and programming environments used in converting the design of SIUMA System to code and its implementation details.
6.1 Implementation Technologies
The following are the technologies used in implementing the SIUMA System.
6.1.1 Rational Rose
Rational Rose is an object-oriented Unified Modeling Language (UML) software design tool intended for visual modeling and component construction of enterprise-level software applications. Computer programmers, business analysts, a software designer uses Rational Rose to visually create (model) the framework for an application by blocking out classes with actors (stick figures), use case elements (ovals), objects (rectangles) and messages/relationships (arrows) in a sequence diagram using drag-and-drop symbols. Rational Rose documents the diagram as it is being constructed and then generates code in the designer's choice of C++, Visual Basic, Java, Oracle8, Corba or Data Definition Language.
Two popular features of Rational Rose are its ability to provide iterative development and round-trip engineering. Rational Rose allows designers to take advantage of iterative development (sometimes called evolutionary development) because the new application can be created in stages with the output of one iteration becoming the input to the next. (This is in contrast to waterfall development where the whole project is completed from start to finish before a user gets to try it out.) Then, as the developer begins to understand how the components interact and makes modifications in the design, Rational Rose can perform what is called "round-trip engineering" by going back and updating the rest of the model to ensure the code remains consistent [7]. Class, Object, Use case and Sequence diagrams for SIUMA System have been produced using Rational Rose98.
6.1.2 EMCO Microsoft Installer (MSI) Package Builder
EMCO MSI Package Builder is an innovative instrument for generation of Windows Installer packages ready for silent unattended installation, which can be installed manually on a local PC. EMCO MSI Package Builder uses ‘Live Monitoring’ technology that enables capturing of file system and registry changes caused by any application. The collected data is used for creation of MSI package [8]. SIUMA System makes use of this instrument for creation of MSI files and configures these files to be available for the Agents that dispatch over the network thus automating the software installation process at the remote node’s.
6.1.3 NetBeans
The NetBeans project consists of an open-source IDE and an application platform. The NetBeans IDE enable developers to rapidly create web, enterprise, desktop, and mobile applications using the Java platform, as well as JavaFX, PHP, JavaScript and Ajax, Ruby and Ruby on Rails, Groovy and Grails, and C/C++. The NetBeans Platform is a reusable framework for simplifying the development of Java Swing desktop applications.
NetBeans IDE 6.8 is used in developing this project which is the first IDE to offer complete support for the entire Java EE 6 spec with improved support for JSF 2.0/Facelets, Java Persistence 2.0, EJB 5.1 including using EJBs in web applications, RESTful web services, and GlassFish v5. NetBeans IDE 6.8 requires Java SE Development Kit (JDK) 5.0 or JDK 6 Update 14 or newer to be installed [9]. JDK 5.0 Update 22 is used for developing this project.
6.1.4 Java Technology
Java is a programming language originally developed by Sun Microsystems and released in 1995 as a core component of Sun Microsystems' Java platform. The language derives much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities. Java applications are typically compiled to byte-code that can run on any Java virtual machine (JVM) regardless of computer architecture [10]. Java components used in the development of the proposed system are as follows [11]:
a) JButton: A button is a component the user clicks to trigger a specific action.
b) JComboBox: A component that combines a button or editable field and a drop-down list. The user can select a value from the drop-down list, which appears at the user's request. If you make the combo box editable, then the combo box includes an editable field into which the user can type a value.
c) JLabel: A display area for a short text string or an image, or both. A label does not react to input events. As a result, it cannot get the keyboard focus. A label can, however, display a keyboard alternative as a convenience for a nearby component that has a keyboard alternative but can't display it. A JLabel object can display either a text, an image, or both.
d) JFrame: JFrame is a Window with border, title and buttons. When JFrame is set visible, an event dispatching thread is started. JFrame objects store several objects including a Container object known as the content pane. To add a component to a JFrame, add it to the content pane. The components added to the frame are referred to as its contents; these are managed by the ContentPane. To add a component to a JFrame, we must use its ContentPane instead.
e) JPanel: JPanel is a generic lightweight container. To make Applet or application layout easier, you break a frame up into regions and compose each of them separately. Each region is called a JPanel. Each can have its own different LayoutManager.
f) JScrollBar: An implementation of a scrollbar. The user positions the knob in the scrollbar to determine the contents of the viewing area. The program typically adjusts the display so that the end of the scrollbar represents the end of the displayable contents, or 100% of the contents. The start of the scrollbar is the beginning of the displayable contents, or 0%. The position of the knob within those bounds then translates to the corresponding percentage of the displayable contents.
g) JTextArea: A JTextArea is a multi-line area that displays plain text. It is intended to be a lightweight component that provides source compatibility with the java.awt.TextArea class where it can reasonably do so.
h) JTextField: JTextField is a lightweight component that allows the editing of a single line of text
i) JFileChooser: File chooser dialog box is used for navigating the file system. With file chooser one can choose either file or directory from file or directory list. In order to display file chooser JFileChooser API is used. In addition, one can also display file chooser by adding JFileChoose instance to a container.
6.1.5 IBM’s Aglet Model
IBM's Aglets Workbench (Aglets) mirrors the applet model in Java. The term aglet is indeed a portmanteau word combining agent and applet. An aglet is a java mobile agent which can autonomously and spontaneously move from a system to another. An aglet is simply an object on which a thread executes on. This approach is very similar to the applets or servlets. Aglet Software Development Kit (ASDK) is used in the proposed SIUMA System for creating and maintaining agents as it is open source and well documented [12].
6.1.5.1 Basic Elements
The model was designed to benefit from the agent characteristics of Java, most notably, the model defines a set of abstractions and the behavior needed to leverage mobile agent technology in Internet-like open wide-area networks. The key abstractions are aglet, proxy, context, message, future reply, and identifier:
Aglet: An aglet is a mobile Java object that visits aglet-enabled hosts in a computer network. It is autonomous, since it runs in its own thread of execution after arriving at a host, and reactive, because of its ability to respond to incoming messages.
Proxy: A proxy is a representative of an aglet. It serves as a shield for the aglet that protects the aglet from direct access to its public methods. The proxy also provides location transparency for the aglet; that is, it can hide the aglet’s real location of the aglet.
Context: A context is an aglet's workplace. It is a stationary object that provides a means for maintaining and managing running aglets in a uniform execution environment where the host system is secured against malicious aglets.
Message: A message is an object exchanged between aglets. It allows for synchronous as well as asynchronous message passing between aglets. Message passing can be used by aglets to collaborate and exchange information in a loosely coupled fashion.
Future reply: A future reply is used in asynchronous message-sending as a handler to receive a result later asynchronously.
Identifier: An identifier is bound to each aglet. This identifier is globally unique and immutable throughout the lifetime of the aglet.
6.1.5.2 Aglet Life Cycle
Behavior supported by the aglet object model is based on a careful analysis of the "life and death" of mobile agents. There are basically only two ways to bring an aglet to life:
Either it is instantiated from scratch (creation) or it is copied from an existing aglet (cloning). The Figure 6.1 depicts the Aglet Life Cycle model.
[pic]
Figure 6.1 Aglet Life Cycle Model.
6.1.5.3 Operations on Aglet
The following are the fundamental operations on Aglet
- Creation. The creation of an aglet takes place in a context. The new aglet is assigned an identifier, inserted into the context, and initialized. The aglet starts executing as soon as it has been successfully initialized.
- Cloning. The cloning of an aglet produces an almost identical copy of the original aglet in the same context. The only differences are the assigned identifier and the fact that execution restarts in the new aglet.
- Dispatching. Dispatching an aglet from one context to another will remove it from its current context and insert it into the destination context, where it will restart execution (execution threads do not migrate). We say that the aglet has been “pushed” to its new context.
- Retraction. The retraction of an aglet will pull (remove) it from its current context and insert it into the context from which the retraction was requested.
- Activation and deactivation. The deactivation of an aglet is the ability to temporarily halt its execution and store its state in secondary storage. Activation of an aglet will restore it in a context.
- Disposal. The disposal of an aglet will halt its current execution and remove it from its current context.
- Messaging. Messaging between aglets involves sending, receiving, and handling messages synchronously as well as asynchronously.
6.1.5.4 The Aglet Event Model
The Aglet programming model is event-based. The model allows the programmer to "plug in" customized listeners into an aglet. Listeners will catch particular events in the lifecycle of an aglet and allow the programmer to take action when the aglet is being dispatched. The Figure 6.2 shows aglet event model
[pic]
Figure 6.2 Aglet Event Model.
Three kinds of listener exist:
▪ Clone Listener: Listens for cloning events. One can customize this listener to take specific actions when an aglet is about to be cloned, when the clone is actually created, and after the cloning has taken place.
▪ Mobility Listener: Listens for mobility events. One can use this listener to take action when an aglet is about to be dispatched to another context, when it is about to be retracted from a context, and when it actually arrives in a new context.
▪ Persistence Listener: Listens for persistent events. This listener allows the programmer to take action when an aglet is about to be deactivated and after it has been activated.
6.1.5.5 Agent Transfer Protocol (ATP)
ATP is a simple application-level protocol designed to transmit an agent in an agent- system-independent manner. An ATP request consists of a request line, header fields, and content. The request line specifies the method of the request, while the header fields contain the parameters of the request. ATP defines four standard request methods as shown in the Figure 6.3.
[pic]
Figure 6.3 ATP request methods.
Dispatch: The dispatch method requests a destination agent system to reconstruct an agent from the content of a request and to start executing the agent. If the request is successful, the sender must terminate the agent and release any resources consumed by it.
Retract: The retract method requests a destination agent system to send a specified agent back to the sender. The receiver is responsible for reconstructing and resuming the agent. If the agent is successfully transferred, the receiver must terminate the agent and release any resources consumed by it.
Fetch: The fetch method is similar to the GET method in HTTP; it requests a receiver to retrieve and send any identified information (normally class files).
Message: The message method is used to pass a message to an agent identified by a agent-id and to return a reply value in the response. Although the protocol adopts a request/reply form, it does not lay down any rules for a scheme of communication between agents.
6.2 Implementation details of SIUMA System
In this section, the implementation details of the proposed system involving different modules is discussed.
A. SIUMA Server Module
SIUMA Server is developed using batch scripts that automatically installs J2SE 1.5.0 Update 22 and IBM Aglets Work Bench 2.0.2 to the system drive (drive in which Operating System is present). The following are the instructions in the SIUMAServerAutoInstallation.bat file:
//Installing J2SE 1.5.0 Update 22 by copying necessary files
Start /B /HIGH /WAIT xcopy /y "SIUMAServer" "%SystemDrive%\SIUMAServer" /e /v /c /i /q
// Java Path settings
SET JAVA_HOME=%SystemDrive%\SIUMAServer\Java\jdk1.5.0_22
SET JAVA_PATH=%JAVA_HOME%
//Aglet path settings
SET AGLETS_HOME=%SystemDrive%\SIUMAServer\aglets-2.0.2
SET AGLETS_PATH=%AGLETS_HOME%
//Extracting Aglets-2.0.2.jar file
call jar xvf aglets-2.0.2.jar
//Executing Aglets ant
call ant
call ant install-home
//Copying the necessary files to SystemDrive
xcopy /y "aglets.policy" "%SystemDrive%\%HOMEPATH%\.aglets\security" /i
xcopy /y "java.policy" "%JAVA_HOME%\jre\lib\security" /i
//Configuring Tahiti to run from Windows Start Menu-All Programs-SIUMA Server
Xcopy /y "SIUMAServer.vbs" "%SystemDrive%\%HOMEPATH%\STARTM~1\Programs\SIUMAServer" /v /i /q
xcopy /y "Application Packages" "%AGLETS_HOME%\public" /s /e /v /c /i /q
This instruction finishes SIUMAServer installation and once SIUMAServer is started it is configured to create SIUMAServer Aglet which provides the GUI for the Administrator to perform the required tasks.
SIUMAServer.java
class SIUMAServer extends Aglet implements WindowListener
JFrame frame=new JFrame();
siumaServerContext.setProperty("siumaServerProxy",GlobalVariables.siumaServerProxy );
SIUMAServerWindow siumaServerwindow=new SIUMAServerWindow();
//SIUMAServerWindow initializing the panels
//Declare java GIU components
DestinationInfoPanel panel1Ref=new DestinationInfoPanel
//Declare java GIU components
InstallPanel panel2Ref=new InstallPanel();
//Event Handler
EventHandler eventHandler=new EventHandler(siumaServer);
Depending on the type of action performed by Administrator the SIUMAServer creates the necessary Agents.
Action:
Get Remote node System details and list of Softwares installed:
Agent Created: SoftwaresOnDestination.java
When Administrator clicks on Softwares button, the EventHandler in SIUMAServer performs the following actions:
B. SoftwaresOnDestinationAgent Module
//Pseudo code of SoftwaresOnDestination.java
//Create SoftwaresOnDestination Agent
createAglet(siumaServer.getCodeBase(),"SIUMAServerCode.SoftwaresAndDriversOnDestination",softwaresAndDriversParameters);
//get SIUMAServer Proxy and Destination Address
siumaServerProxy=(AgletProxy)getAgletContext().getProperty("siumaServerProxy",args[0]);
myDestination=(String)args[1];
//onArrival of agent to remote node
void onArrival(MobilityEvent me)
{
//”systeminfo” Displays detailed configuration information about a computer and its operating system, including operating system configuration, security information, product ID, and hardware properties, such as RAM, disk space, and network cards [13].
exec("cmd /c start /b /high systeminfo");
//capture the output
//report to SIUMAServer
siumaServerProxy.sendOnewayMessage(systemDetailsandListofSoftwaresInstalled);
dispose();
}
Action:
Select Softwares to install:
When Administrator selects softwares to install, the EventHandler in SIUMAServer performs the following actions:
//get the files in the selected directory and display to Administrator so that Administrator can select the required softwares to install
filesInDirectory=directoryPath.listFiles();
//Configuring the file permissions to be accessible for agents
//cacls command Displays or modifies discretionary access control list (DACL) files [14].
exec("cmd.exe /c cacls \"" + directoryPath + "\" /E /T /G EVERYONE:R 1>nul");
//Configuring the selected directory to be available for the agent when it gets dispatched over the network
//net share manages the shared resources and used to display information about all of the resources that are shared on the local computer [15].
exec("cmd.exe /c net share \"" + shareName + "\"=\"" + directoryPath + "\"" );
After selecting the softwares the Administrator can initiate Software Installation by clicking on Install button.
C. InstallAgent Module
Action:
Install Softwares:
When Administrator clicks install button, the EventHandler in SIUMAServer performs the following actions:
//Validate remote node address
ipRangeValid=true;
//get list of softwares to install
softwaresToInstall[i]=softwaresToInstallListModel.get(i).toString();
//get server IpAddress
inetAddress=InetAddress.getLocalHost();
serverIpAddress=inetAddress.getHostAddress();
//get server system password
WindowsGuestUserPassword=new String(WindowsGuestUserPasswordField.getPassword() );
//create InstallAgent
createAglet(siumaServer.getCodeBase(),"SIUMAServerCode.Install",installAgentParameters);
//Agent after dispatching to remote node
//Add server to remote node’s Trusted Sizes Zone
exec("cmd.exe /c start /b /high REG ADD \"HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\Ranges\\siumaServer\" /v :Range /t REG_SZ /d " + myServerIpAddress + " /f ");
exec("cmd.exe /c start /b /high REG ADD \"HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\Ranges\\siumaServer\" /v file /t REG_DWORD /d 1 /f ");
//Establish connection to Server
exec("cmd.exe /c start /b /high net use \\\\" + myServerIpAddress + " /USER:SIUMAClient " + myServerWindowsGuestUserPassword + " /PERSISTENT:NO ");
//configure remote node for capturing exceptions so that InstallAgent can report to Administrator at server
exec("cmd.exe /c start /b /high REG ADD \"HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Windows\" /v ErrorMode /t REG_DWORD /d 2 /f ");
//Install Softwares one after another
exec("cmd.exe /c \\\\"+ myServerIpAddress + "\\\"" + shareNameAtSIUMAServer + "\"\\\"" + softwares[i] + "\" /qn 2>&1");
//Report to SiumaServer that installation has finished
siumaServerProxy.sendOnewayMessage(finished);
//disconnect remote node from server
exec("cmd.exe /c start /b net use \\\\" + myServerIpAddress + "\\\"" + shareNameAtSIUMAServer + "\" /DELETE");
exec("cmd.exe /c start /b net use \\\\" + myServerIpAddress + "\\IPC$ /DELETE");
//removing server from Trusted Sites Zone
exec("cmd.exe /c start /b REG DELETE \"HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\Ranges\\range3\" /f ");
//InstallAgent disposes at destination
Dispose();
D. SIUMA Client Module
SIUMA Client is developed using the similar scripts written for SUMA Server with little modifications that allows remote node to run SIUMA Client’s Tahiti at its STARTUP.
//configuring Tahiti to be running at the system startup
xcopy /y "SIUMAClient.vbs" "%SystemDrive%\%HOMEPATH%\STARTM~1\Programs\Startup" /i
6.3 Possible Error Messages in SIUMA System
The Table 6.1 lists the possible error messages/alerts that a SIUMA System displays to Administrator when respective exceptions are handled.
Table 6.1. List of Error messages
|Sr. No |Error Messages/Alerts |
|1 |Interrupted while setting File, Folder & Share Permissions for selected Folder/ Directory |
|2 |Problem while fetching SERVER(This System) IpAddress |
|3 |Enter SERVER Systems Password for Admin/ WindowsGuest User Account. Else system at Destination Prompts for the same. To Avoid |
| |this Enter Password if any Click Ok to Continue if No Password is set Click Cancel to Enter password |
|4 |Agent could not be Created |
|5 |Destination Address Or Tahiti Client Port Fields above are Empty |
|6 |Enter Tahiti Client Port |
|7 |Agent at host: myDestination failed to Establish Connection with SERVER |
|8 |fileNotAvailable: Agent was interrupted while running at host: myDestination Possible Reasons: |
| |1. software might not be Available at Server |
| |2. Windows Firewall or AntiVirus Programs at Server are blocking SIUMAAgent requests from Destination |
| |3. This system (System running SIUMAServer) may not have network connectivity |
| |4. In worst case SIUMA Server could not set File & Folder Permissions for Selected Folder. This possibility may be only when |
| |running multiple agents multiple times. If this is the case Right Click on the Drive: containing softwares and select Sharing |
| |and Security And click on If you understand the risk but still want to share the root of the drive, click here. |
|9 |Agent was interrupted during Installation at host: myDestination |
|10 |Agent failed to Install Softwares at host: myDestination |
|11 |Problem with Agent that was Created for Destination: myDestination Possible Reasons: |
| |1. Invalid Destination/Port Number |
| |2. AntiVirus programs at Destination: myDestination must be Blocking the Agent |
| |3. Windows FireWall Exceptions are Enabled at Destination: myDestination |
| |4. Taking too long to reach Destination: myDestination |
|12 |Agent failed to perform necessary Operations at: myDestination |
|13 |Byte value in IPAddress is InValid. Enter IPAddress in Decimal Format between (0 to 255) |
|14 |InValid IPAddress(IPV4) Maximum Byte size is 3 eg: 250.250.250.250 |
|15 |From Range And To Range are not in Order |
|16 |No IPAddresses in specified Range |
|17 |InValid IpAddress Range.. |
|18 |InSufficient Memory to Store all IpAddress. Java: ArrayIndexOutOfBoundsException |
6.4 Summary
This chapter discussed the implementation technologies used to convert the design of the proposed system to code to view the systems actual behavior and the implementation details.
Chapter 7
RESULTS AND DISCUSSION
This chapter presents the results obtained from the developed system and discusses the same. The SIUMA Server is running on a system containing software setup files and remote nodes were selected by their IP Addresses connected to in a network.
7.1 Results
[pic]
Figure 7.1. Graphical User Interface (GUI) for Administrator.
The snapshot shown in the Figure 7.1 is the GUI the SIUMAServer creates for the Administrator. Administrator can specify the remote node address and SIUMAClient port address to retrieve remote node’s system details, list of softwares installed and installs the selected softwares.
[pic]
Figure 7.2. Remote node details and list of softwares installed
The snapshot shown in the Figure 7.2 depicts the system details and list of softwares installed on remote node ‘RajeshDontham’ running SIUMAClient at port 4434.
[pic]
Figure 7.3. Selecting Directory/Folder containing softwares
The snapshot shown in the Figure 7.3 depicts the SIUMAServer Directory/folder selection option. Administrator can choose the directory containing softwares to be installed on remote nodes.
[pic]
Figure 7.4. Selected sofwares to install.
The snapshot shown in the Figure 7.4 depicts that a list of softwares were added to ‘Softwares to Install’ list from ‘Softwares Available’ list. The Administrator can now install the selected softwares by clicking Install\Run button to install on selected remote system or click on Quick Install\Run button to install on multiple remote systems which prompts the Administrator to specify the IPRange as shown in the Figure 7.5. The Administrator can also install the selected softwares on selected systems (Maximum six) at a time by entering the remote node addresses in ‘Install on Selected Node’s’ fields as shown in the Figure 7.6. Administrator can obtain the installation status at ‘Installation Status Screen’ and Agents status in ‘Agent Status Screen’.
[pic]
Figure 7.5. Quick Install: Specify IpRange.
[pic]
Figure 7.6. Selective Install: Specify addresses of selected remote systems.
7.2 Summary
This chapter provided the results that were obtained during the execution of the proposed system. The results were shown in the form of screenshots and a brief description for each of the screenshot is also provided in this chapter.
Chapter 8
CONCLUSION AND FUTURE WORK
8.1 Conclusion
In this project a System was developed that automates software installation on a network using mobile agent’s paradigm. The system has been implemented using the Java Aglets framework and hence all the advantages of the Java Programming language accrue. As in the case with any mobile agent system, one time installation of SIUMA Client is to be installed at each node in the network.
The software has been successfully tested with all types of softwares setups on the university network and found to be very useful in reducing the installation time, risks involved in managing software systems individually at every node.
This system can be very useful to organizations who wish to install software on their huge networks in minimum time.
8.2 Future work
The future work for this system will include extending the system to provide more Network Management functionalities like monitoring, software deployment activities like uninstalling and updating the softwares at remote node. The future work also envisages to develop SIUMA System to be able to run on different operating systems.
Chapter 9
PUBLICATIONS ARISING OUT OF THE WORK
1. Title: “Software Installation on a Network Using Mobile Agents”
Presented at: “Conference on Evolutionary Trends in Information Technology (CETIT) 2011” held at Visvesvaraya Technological University, Jnana Sangama, Belgaum.
Date: From 20th May 2011 to 22nd May 2011.
2. “Efficacy of mobile agent technology in distributed computing domain”. Communicated to Journal of Advances in Information Technology - Special Issue on Advanced Algorithm.
Software Installation on a Network Using Mobile Agents
D Rajesh S.R.Mangalwede
M.Tech (CNE) Professor
Dept. of PG Studies Dept. of CSE
VTU Jain College of Engineering
Belgaum, India . Belgaum, India.
Email: rajeshdontham@ Email: mangalwede@
Abstract
Software Installation (or software setup) is the process of restoring software from external media and putting the program onto a computer system that writes the necessary data on to local file system (hard drive) so that it can be executed. Typically, software installation is done at each node manually either by running the setup from a removable media (CD-ROM, flash drive etc.) or through a client–server model in a network wherein the client requests and downloads the setup file from the server (or by simply sharing the files in a network and directly executing at remote node). Consequently, traditional approach of software installation cannot scale well because of its time-consumption properties. In order to solve this problem and provide an efficient solution, this work proposes a system that makes use of Mobile Agent paradigm to perform software installation automatically thus eliminating human intervention at node’s on the network.
Keywords: Software Deployment, Software Installation, Mobile Agents, Security.
1. Introduction
Personal computers now run a wide range of applications each serving one or more users. Each application to get executed on the system requires it to be installed; that involves writing the necessary data on system drive for running the program. Installing the required application using traditional software installation on a single node or on few is not a difficult task but when required to install on several node’s (e.g. Networked computers in Educational Institutions, Organizations etc) is boring and time consuming job.
The following are the disadvantages of traditional approaches
▪ It requires lot of human intervention.
▪ It is time consuming process.
▪ It requires additional physical media resources like CD-ROM, Flash drive etc and
▪ It is difficult to manage Applications over PC’s.
This paper is organized as follows: Section 2 discusses the related works, and technologies in software deployment process. Section 3 provides an introduction to mobile agents and methodology for the proposed system. Section 4 presents the system requirements. Section 5 concludes and presents the future work.
2. Literature Survey
The software deployment is a complex procedure that involves the release, installation, adaptation, reconfiguration, update, activation, deactivation, retirement and removal of software.
The following are some of the existing technologies [1] that support various aspects and activities of the software deployment process.
A. Installation Tools
Generate a set of executable and artifact files that must be downloaded or provided via a distribution media like a CD, or via Internet. These files can be compressed in a single installation executable file. In order to install the system, the installation software needs to be executed in the customer site. One example of these tools is the InstallShield installation tool that generates a self-extractor file that manages the installation and de-installation procedures of an application. This InstallShield is for software developer to build reliable Windows Installer (MSI) and InstallScript installations for desktop, server, Web, mobile applications [2] and not to install a software program on computers.
Disadvantages: These tools are usually platform specific, and allow a minimal degree of configuration on what components to install.
B. Package Managers
These installation tools use the concept of packages. A package is an archive that contains the files that constitute a system together with some meta-data describing the system. The packages have to be copied to the customer site in order to be installed. Some package managers provide file transfer capabilities. Once in the system, the package is installed by the package manager. An example of a package tool is the Red Hat RPM.
Disadvantages: These tools usually do not provide activation and deactivation capabilities and some of them allow a primitive policy specification.
C. Application Management Systems
These kinds of systems generally support all of the life cycle activities except the producer-side release activity. Their architecture is generally centralized. These systems were designed to manage the software deployment in large or medium organizations that both produce and consume software. In these systems, a central server typically controls all management and deployment activities. An example of such application is the System View from IBM.
Disadvantages: These technologies don’t allow both the transportation and execution of the installation software in a more customizable way.
In reference [1], although no implementation is provided in this paper some ideas concerning the use of mobile agents in software deployment process, issues and requirements, benefits and drawbacks are discussed. Programming Mobile agents to request the installation files according to current configuration of system instead of getting all installation files at once is one idea and the workflow management using mobile agent paradigm is perhaps basic idea to our work. The paper also advocates the use of interpreted languages like java to achieve platform independence. The author suggests a Hybrid policy to overcome lower internet speeds. In our system node’s are over LAN and hence one time transfer of payload is required.
The reference [3] discusses some previous works that focus to deal software deployment problems in clusters.
I. Disk image-based deployment
Disk image-based deployment approach was designed for deploying operating system. SystemImager provide tools for acquirement, management and deployment of system images. The deployment of image is centralized and all node’s obtain image from the image server by using the remote replication tool rsync. OSCAR (Open Source Cluster Application Resource) composed of Software Suite which can be easily integrated and installed, provides a set of construction, management, maintenance and high-performance cluster tools.
Disadvantages: Poor Flexibility
II. Behavior-based deployment
The basic idea is to record all of the disk operations during the software deployment and the software installation process can be replayed. It is required to trace the kernel operation of installation process. ZSDT (Zju Software Delivery Toolkit) can automate software deployment in all aspects, including planning, implementation, reporting.
Disadvantages: Tracing the kernel operation of installation Process is difficult to realize.
III. Package-based deployments
XcelleNety use Prism Deploy for Software distribution. Prism Deploy create packages which contain State information including file system, registry settings, and other information. Prism Deploy also supports the distribution of Msi package format. This uses the idea of batch process. It writes all the commands that are implemented during the installation process in a batch file. When deploying software on the target node, we should send the installation package and batch file to the target, and then execute the batch commands. This method is flexible.
Disadvantages: Hard to solve the interactive installation, because some software needs to interact with the administrator/user during installation process.
In paper [3], the method “NOVEL SOFTWARE DEPLOYMENT SYSTEM” focuses on how to deal with deploying software automatically in large scale Linux based clusters. The author feels that his method improves Package Based Deployment methods which are highly flexible. Phases included in deployment process are clearly discussed. The Linux installation processes are identified and handled accordingly. Interactive installation procedure which is a complex task is achieved through Script and Expect tools. This proposed method for Linux based systems is closest to our work. The author also mentions his method lacks stability and there are some random factors, so when deploying software by using the automatic deployment system, there may be individual failure.
The reference [4], describes a system that performs software installation on a heterogeneous network using mobile agents which is closest to our own work. This system is suited only for installation of mandatory software: which means only similar software can be installed on entire network. Individual node’s over LAN cannot be handled. Two separate Mobile agents AgentController and Agent are used for software installation. Creating N clones of AgentController for N entries in Inter tablets and M Agents for M entries in Intra table increases network traffic and gets worse if the installation software or node’s in network is large. We believe our proposed system will be feasible approach for installing required software on windows based node or network.
3. Proposed Architecture
3.1 Motivation
The disadvantages of existing systems and the advantages of Mobile Agents [5] motivated us to carry on with this work. The proposed architecture develops a system that performs the required Software installation on a windows based node or network which is an activity of Software Deployment that makes software systems available for use.
3.2 Mobile Agent
Mobile agents refer to programs that perform certain tasks on behalf of the user and migrate from one computer to another in the network and execute on several machines. A mobile agent is a specific form of mobile code that consists of the program code and the program execution state (the current values of variables, next instruction to be executed, etc.)
Initially a mobile agent resides on a computer called the home machine. The agent is then dispatched to execute on a remote computer called a mobile agent host (a mobile agent host is also called mobile agent platform or mobile agent server). When a mobile agent is dispatched the entire code of the mobile agent and the execution state of the mobile agent is transferred to the host. The host provides a suitable execution environment for the mobile agent to execute. The mobile agent uses resources (CPU, memory, etc.) of the host to perform its task. After completing its task on the host, the mobile agent migrates to another computer. Since the state information is also transferred to the host, mobile agents can resume the execution of the code from where they left off in the previous host instead of having to restart execution from the beginning. This continues until the mobile agent returns to its home machine after completing execution on the last machine in its itinerary.
The life cycle of a mobile agent:-
1. The mobile agent is created in the Home Machine.
2. The mobile agent is dispatched to the Host Machine A for execution.
3. The agent executes on Host Machine A.
4. After execution the agent is cloned to create two copies. One copy is dispatched to Host Machine B and the other is dispatched to Host Machine C.
5. The cloned copies execute on their respective hosts.
6. After execution, Host Machine B and C send the mobile agent received by them back to the Home Machine.
7. The Home Machine retracts the agents and the data brought by the agents is analyzed. The agents are then disposed.
[pic]
Figure 1.The life cycle of a mobile agent.
From the Figure 1 .We observe that a mobile agent experiences the following events in its life cycle:
Creation: a brand new agent is born and its state is initialized.
Dispatch: an agent travels to a new host.
Cloning: a twin agent is born and the current state of the original is duplicated in the clone.
Deactivation: an agent is put to sleep and its state is stored on a disk of the host.
Activation: a deactivated agent is brought back to life and its state is restored from disk.
Retraction: an agent is brought back from a remote host along with its state to the home machine.
Disposal: an agent is terminated and its state is lost forever.
3.3 Methodology
The proposed architecture makes use of Aglets Software Development Kit (ASDK) 2.0.2 which is a Java based framework and environment for researching and developing mobile agents in JAVA to develop this system. We do require a one time installation of the ASDK at each node in the network and network connection, at least during the time necessary to the agent migrate to the node and collect all artifacts for the installation. After that, the mobile agent can be configured to perform the installation process without the network connection presence.
The system consists of a Home Machine that contains setups of the softwares to be installed on the network. The mobile agent is created in the Home Machine and is dispatched to specific node which on its arrival on to the destination node will start execution. Tools like EMCO Msi Package Builder can be used to create software Images. A log history is maintained by the system which records all the activities right from the start of the process till the end.
Before Installation, the node is checked for the presence of available applications on it. This can be done by creating an agent that dispatches to specified node, collects the necessary information and reports to administrator. In case if the required application is not present, an agent is created by the administrator and dispatched, that performs necessary operations on its arrival at the destination node. The time required by a single agent to install the required software on all the node’s over the network is very high. The alternative is to create multiple agents (N agents for N node’s) to perform the task. The security is provided by configuring java.policy file. The dispatched agent reports to administrator after successful execution and disposes at destination itself.
4. System Requirements
Hardware Requirements (Minimal)
Processor: Pentium 2.4 GHz
Hard Disk: 40 GB
Ram: 1 GB
Monitor: Standard Color
Key board: Standard
Software Requirements
Platform: Windows XP
Backend: Aglets-2.0.2 (Aglets Software Development Kit)
Language: Java (JDK-1.5.0 Update 22)
Tools: Web Ping Tester, NetBeans6.8.1
Other Requirements
• Network connection for host machine and remote node’s.
• Tahiti server to be running on the remote node’s.
5. Conclusion
This paper presented a possible approach for software installation on a windows based node or network. We believe this proposed system is best suited for software management of individual node’s over a network.
As future work, we plan to implement the proposed system using ASDK and verify the efficiency of proposed approach.
References:
[1] Roberto Silveira Silva Filho, “Mobile Agents and Software Deployment”, Roberto Silveira Silva Filho, ICS -Information and Computer Science, UCI - University of California Irvine 444 Computer Science Building, University of California Irvine, CA 92697-3425, USA.
[2] InstallShield:
[3] Hongbo Tian, Xiaoyi Zhao, Zhixing Gao, Taiqiang Lv, Xiaoshe Dong, “A Novel Software Deployment Method based on Installation Packages”, The Fifth Annual ChinaGrid Conference.
[4] B.Srikanth, D.Kirubakaran, N.Siddharth, Sudip Sanyal, “Software Installation on a Huge Heterogeneous Network using Mobile Agents”, 6th IEEE/ACIS International Conference on Computer and Information Science.
[5] Lange, D., and Oshima, M, “Seven Good Reasons For Mobile Agents”, Programming and Deploying Java Mobile Agents with Aglets. Addison-Wesley Longman, Reading, Mass., 1998.
REFERENCES
[1] Roberto Silveira Silva Filho, “Mobile Agents and Software Deployment”, Roberto Silveira Silva Filho, ICS -Information and Computer Science, UCI - University of California Irvine 444 Computer Science Building, University of California Irvine, CA 92697-3425, USA.
[2] InstallShield:
[3] Hongbo Tian, Xiaoyi Zhao, Zhixing Gao, Taiqiang Lv, Xiaoshe Dong, “A Novel Software Deployment Method based on Installation Packages”, The Fifth Annual ChinaGrid Conference.
[4] B.Srikanth, D.Kirubakaran, N.Siddharth, Sudip Sanyal, “Software Installation on a Huge Heterogeneous Network using Mobile Agents”, 6th IEEE/ACIS International Conference on Computer and Information Science.
[5] Mario Kusek, Gordan Jezic, lgor Ljubi, Kresimir Mlinaric, Ignac Lovrek, Sasa Desic, Ozren Labor, Antun Caric, Darko Huljenic, “Mobile Agent Based Software Operation and Maintenance”, 7th International Conference on Telecommunications - ConTEL 2003 ISBN: 953-184-052-0J,u ne 11-13, 2003,Z agreb, Croatia.
[6] Lange, D., and Oshima, M, “Seven Good Reasons For Mobile Agents”, Programming and Deploying Java Mobile Agents with Aglets. Addison-Wesley Longman, Reading, Mass., 1998.
[7]
[8]
[9]
[10] (programming_language)
[11]
[12]
[13]
[14]
[15]
-----------------------
MobilityListener
PersistenceListener
CloneListener
AGENT
Persistence Event
Mobility Event
Clone Event
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- start a network marketing company
- how to start a network marketing business
- software installation qualification
- components of a network infrastructure
- starting a network marketing company
- changing a network name
- access pc on home network windows 10
- what is a network port
- create a network between two computers
- jupiter installation on windows
- find network credentials on a computer
- advantages of a network switch