CHAPTER 1

INTRODUCTION

The general trend of downsizing that has taken place over the past several years has had a significant impact on the way that how to organize and manipulate the resources. Services, processing and data have moved from the traditional central mainframe of the 1970s into Intranet work of organization-wide workstations and personal computers. Therefore, it can be argued that the concept of distribution has been an inevitable evolution in electronic information development; information and user bases are growing at such a rate that centralized storage and processing is no longer feasible. Computer networks such as Internet, intranet, and extranet are becoming lifeline of business, entertainment, education and government information dissemination.

However, what has taken place is the creation of smaller, centralized islands which provide local services and are connected to other service providers through networks and networking protocols. More and more coordination and cooperation are required among the islands to achieve mutual objectives.

With the development of computer technique, especially after the explosive development of Internet, more and more researches and techniques are done on the Internet. The growth of networks in size, heterogeneity, functionality and the demand for its high availability require an efficient, scalable, dynamic network management model, prevalent centralized network management has failed to meet the challenge of today’s networks for several years. “The flexible, scalable, and dynamic management architecture is inevitable for the next generation of network management”. [15]

The requirements and characteristics of a large-scaled environment can be summed up as:

  1. Simultaneous use of large numbers of resources
  2. Open and flexible system
  3. Providing service to diverse user groups
  4. Dynamic resource requirements
  5. Reliable and secure resource sharing
  6. Use of sharable resources from multiple administrative domains
  7. Complex communication structures
  8. Stringent performance requirements

In this thesis, we are going to provide a mechanism for the distributed resource management based on the software agent technology. We believe that the mechanism can achieve the goals of distributed resource management with an efficient, secure way through the communication, coordination and cooperation of agents. In chapter 2, we are going to introduce the characteristics of distributed resource management, presenting different solutions for the distributed resource management in chapter 3, then we are going to introduce the definition, properties of software agent and JAFMAS, a java-based multiagent system, we will present the distributed architecture, implementation and simulation of the architecture. The last part of the thesis is the future work.

CHAPTER 2

PROBLEM STATEMENT

2.1 Distributed Resources

There are different ways to categorize the distributed resources,

  1. Abstract and specific
  2. Static or dynamic,
  3. Reusable or non-reusable
  4. Combine with each other

In this paper, we categorize the resource as static or dynamic, for the dynamic resource, we don’t want the agent collect information very time, for dynamic resource, before the agent makes decision, it will get the in time information, of course, it will depends on other policy or history information and the future information etc together to make final decision.

  1. Application: There are different kinds of application, from a small program to big VOD eBusiness system, but in this paper, we define the application must have the property: use of the distributed resource, for example, the internet game, VOD in internet, distributed computing etc. Some applications have definite performance requirements. Different applications may share the same object, resource, user.
2.User: The user should be distributed in different place, or might be different OS, and interface, but however, the most important property of the user is collaboration.

2.2 Characteristics of Distributed Resources

In order to understand the distributed resource and provide a mechanism for the management, we are going to study the characteristics of the distributed resource in this chapter. First, let us review the openness.

Openness

Definition of open: a. Allowing unobstructed entrance and exit; not shut or closed. b. Accessible to all; unrestricted. c. Ready to transact business. Openness is very important factor of distributed resource management. “It means that the system can be extended and modified easily. Openness is related with distribution.”[17] The Open System philosophy ensures that the network can easily grow and change to meet the evolving business needs.

Scalability

The Internet resources are extremely huge in their size and complex in their structure. There might be different types of resources including abstract resources and specific resources. There might have different granularity of resource hierarchy and their diverse requirements. Thus, a mapping m different resources into n different users is a challengeable task, and this creates a scalability issue when the resource space is huge and complex. Because global and centralized management is not adequate for the large Internet environment, “Scalability denotes the ability to accommodate a growing load in the future. Scalability requirements often lead to the adoption of distributed system architectures”[17]

Heterogeneity

The Internet and Intra/extranets have a tendency to be managed by organizations that have different management skills and policies. Because of different management systems they use, many problems occurs in their cooperation.

In paper [23], The author gave us a standard Message Block. If the current network use this idea, would it be great? However, not only the message block, the protocol, the platform, the operating system, etc, Due to wide range of underlying network techniques and diverse resource providers/users, Internet becomes more heterogeneous in their structure. Consequently, users on the Internet have different criteria for selecting resources and also resource providers ask different requirements for their resources usage. The usage of resources and services residing on multiple computing environments at different geographical locations requires a robust and flexible framework that supports interoperability between the various resources and users.

Here are some problems that we need to provide in building a distributed resource management environment:

  1. How to define diverse characteristic and requirements of resource users?
  2. How to define diverse characteristic and requirements of resource providers?
  3. How to build a resource management infrastructure that can support for natural mapping between those requirements?

Security

Security is an important issue in designing of distributed resource system. Security in the network should be considered differently from the perspective of a closed or single system. The Internet is really complicated due to their openness, establishing trust relationships. In addition, because of all the necessary information for security management is available in the kernel for a single system, in the Internet, problems such as authentication, authorization or access control is not so easy as is in an operating system.

Resource Sharing

“Resources denote hardware, software and data. Resource sharing is often required in order to render an expensive resource more cost-effective. Resource-sharing also occurs as a consequence of communication and co-operation between users”[17] Resource manager grants access to shared resources, there should be mechanism to provide a secure resource access.

Transparency

The resource is transparent for the users and applications. From different point view, transparency means: Location transparency—the user doesn’t know where is the physical location of the resource, access transparency—the user can call the local or remote resource at the same way, migration transparency—a resource can migrate from one place to another place without users or application noticing it. And replication transparency—for abstract resource, for example, an object or component, the replication is synchronized with it’s original, concurrency transparency—the resource manager should provides a concurrency mechanism so that the users can access the resource parallelly, scalability transparency—the users don’t know the scalability of the distributed resources.

Fault-Tolerance

The system should provide a reliable, fault-tolerance system for the users. Not like the centralized system, one part of the system fails causes the whole system down.

In this chapter, we have introduced the characteristics of the distributed resource; in next chapter, we will introduce different ways for the distributed resource management. Architectures and issues critical to distributed resource management like efficiency, security is given more emphasis.

CHAPTER 3

DIFFERENT WAYS FOR THE DISTRIBUTED RESOURCE MANAGEMENT

In this chapter, we are going to introduce different ways for the distributed resource management. JINI, global event and distributed component. Discussions for each method are provided

3.1 JINI

According to Sun’s definition: “Jini technology delivers access to services over any network for any platform, any operating system, any application. Jini technology consists of infrastructure and programming model that address the fundamental issue of how clients connect with each other to form an impromptu community. Based on Java language, Jini technology uses the methods pioneered by Java Remote Method Invocation(RMI) protocols to move objects, including their behavior, around the network”[44]

[12] provides a web-based integrated framework with Jini---Arcade. Arcade is built to provide support for a team of discipline experts to collaboratively design, execute, and monitor multidisciplinary applications on a distributed heterogeneous network of workstations and parallel machines.

Figure 1. Arcade Architecture

As shown in Figure 1, Arcade consists of three tiers. The front-end is a web based, lightweight client which provides the user interface to the whole system. It consists of applets, which allow users to design an application, monitor and allocate resources, and execute, monitor and steer the application in a collaborative manner. The back-end consists of the distributed resources that are used to actually execute the user modules and application codes. A lightweight controller executes on each resource providing a gateway to the resource.

One of the major components of the middle tier is the Resource Manager(RM), the RM keeps track of the distributed resources which comprise the execution environment and provide information about these resources to the client/user upon request. The resources are varied in nature ranging from compute engines, to data servers, to specialized instruments. The RM has to be flexible enough to not only handle such heterogeneity but also provide information about these systems. The RM should keep track of not only the static information but also the dynamic information.

The whole technology can be segmented into three categories: infrastructure, programming model and services. The infrastructure includes lookup services that serve as a repository of other services that serve as a repository of other services and an extended version of Java based RMI, which defines the mechanism of communication model includes interfaces such as discovery, lookup, leasing, remote events and transactions which ease the task of building distributed systems.

A service is a central concept within Jini. It is essentially an entity that can be used by a person, program or another service to perform a required task. The runtime infrastructure supports the discovery and joins protocol that enables services to discover and register within lookup services. Discovery is the process by which an entity locates lookup services on the network and obtains references to them. Join is the process by which a resource registers the services it offers with lookup services. In particular, the resource may post a service object with the lookup service.

Discussion: In this method, the author provides a 3 –tier architecture. RM(Resource manager) not only keeps track of the distributed resources but also provides information about these resources to the client/user upon request. The system does consider the distribution, heterogeneity and scalability, however, how to provide a secure way, not only to the user, but also to the distributed objects and the distributed resource, further more, if the system is changing larger and larger, how to manage the distributed resources and coordinate them seems need more work.

3.2 Global Event Model

[13] Provides a global event model for distributed resource management proposal. Global events, distributed among multiple virtual machines, can aid in the development of and reasoning about distributed systems of autonomous components interacting through event-based abstractions. Distributed resource management is an archetypal challenge of wide-area coordination that illuminates many of the tradeoffs involved. We model the problem with resource tokens, providers, consuming requestors, and constraints.

Their overall algorithm design is to strike a balance between scalability and availability of the providers, requestors, and resources; to that end, we will employ techniques such as aggregating, hierarchical structuring, and scooping.

Discussion: In this proposal, the author gave us the global event model for the distributed resource management with tokens, providers, requestors and constraints. However, when the system is changing larger and composed of autonomous systems, how to deal with the scalability, the standard event message format and communication mechanism issues should be considered too.

3.3 Component Based Distributed Resource Management

[15] Provides a component-based distributed network management. It

Figure 2. Centralized Network Management

Introduces a component based distributed management paradigm that provides optimal solutions through dynamic plug-and-play of management components.

Conventional network management systems using Simple Network Management Protocol(SNMP) and Common Management Information Protocol(CMIP) consist of management station as Figure above. Agents are located on managed network devices and control the MIB for monitoring and controlling devices. The manager poles the managed devices using protocols such as SNMP, CIMP, or special protocols such as ping. Agents also use trap mechanism to report event occurrence to a network manager. The manager analyzes the collected data and takes appropriate actions to network devices. The centralized network management inherently has several problems: a single point of failure, management communication bottleneck(single point of information sink) communication overhead(end-to-end communication), higher computing requirements of a single system(CPU time), no support of low-speed area(low speed wan or dial-up). In addition, management applications on centralized system are monolithic, hard to tailor and configure, requiring a very powerful and specific platform: the management systems are hard to be flexible, scalable and dynamic. The development of network management systems demands well-established approaches that guarantee robustness of system, dynamic extensibility, expandability, economy of the development process (the above figure)

After discussing the drawbacks of the centralized management, the authors provides component based architecture:

Figure 3. A Component

A component interacts with others in four basic ways. It provides services to other components, gets services from other components, generate events, and observe events. A component is an identifiable piece of software with well-defined boundaries using four elements as show above.

Distributed components must be able to communicate with other components beyond networks. Communications of distributed components can be realized using events or remote method invocations via object middleware such as CORBA. Event models provide advertising and delivering information to other components or applications without prior knowledge of the components or application identity.

This approach exploits the set of interrelated novel techniques such as component architecture, mobile code paradigm, proxy concept, and Internet technology.

Discussion: This paper first describes the drawbacks of the centralized resource management, and then gave a component based distributed resource management. The component can communicate, cooperate with other component to implement the functions. However, how the component makes decisions, how the component coordinate with each other seems needing further discussion.

3.4 JAFMAS

JAFMAS(Java-based Agent Framework for Multi-Agent Systems) is an agent framework for Java, developed by Deepika Chauhan at the University of Cincinati. JAFMAS is designed to provide a generic methodology for developing speech-act based multiagent systems (MAS), an agent architecture, and 16 base java classes to support implementing these agents in Java. The methodology follows five stages: “(i) identifying agent , (ii) identifying the conversations, (iii) identifying the conversations rules, (iv)analyzing the conversation model, and (v) MAS implementation. JAFMAS provides communication, linguistic and coordination support through sixteen Java classes.”[37] Communication support is provided for both directed communication and subject-based broadcast communication. This feature enables the user to develop scalable, fault-tolerant, self-configurable and flexible multiagent systems. Linguistic support is provided through speech-act (e.g. KQML) based communication language which provides an agent independent semantics. Coordination support follows from Searle's thesis (Speech Acts, Cambridge University Press, 1962) that, "speaking a language is engaging in a (highly complex) rule-governed form of behavior." We conceptualize agent plans and their coordination as rule-based conversations represented by automata models. JAFMAS classes support each agent with multiple threads, one for the agent, one for each conversation in which the agent engages, and one for each subject to which the agent subscribes.

Figure 9. JAFMAS Architecture

Once the communication, cooperation and coordination mechanisms between agents have been implemented, we have all the necessary components to develop a multiagent application. A multiagent application developed in JAFMAS is comprised of different classes of agents (instances of the abstract Agent class), each of which is comprised of all the components These different components within each individual agent ensure communication, coordination and cohesive operation between different agents of the system.

Figure 10. JAFMAS Agent Internals

In this paper, we have introduced three ways for the distributed resource management, obviously there are other ways for the distributed resource management. In the next chapter, we will introduce the software agent and the properties and types of agent. The importance of agent in different fields is introduced too. In the last section, we will introduce MAS.