A Java-based Distributed Network Management Architecture Antonio Pulia to1, Orazio Tomarchio1, Lorenzo Vita2 1
2
Istituto di Informatica, Universita di Catania Viale A. Doria 6, 95025 Catania - Italy E-mail:fap,
[email protected]
Dipartimento di Matematica, Universita di Messina C.da Papardo - 98166 Messina - Italy E-mail:
[email protected]
November 27, 1996
1 Introduction
The current research trend seems to be in the direction of a virtualization of the whole distributed system, which thus acquires the same capabilities as a generic calculation resource providing simple and immediate access by means of high-level system calls. Although we are still far from having powerful mechanisms to make access to the calculation and communication resources in a distributed system completely transparent, new technological tools are now available to allow great steps forward to be made in this direction. The recent development of Java, a new language de ned by Sun Microsystems, has allowed the development of new and powerful network applications [5, 6]. With Java it is possible to write applications (applets) which, once directly inserted onto Web pages, can be sent to the user's browser simply by a click of the mouse and then executed using local calculation resources. This speci c feature of Java has not only made it possible to create Web pages containing animation and sound and other features which were previously impossible, thus making the world of the Web more pleasant; its potential goes far beyond such simple use [8]. Java is, in fact, a complete programming language which oers all the basic mechanisms for communication and synchronization between processes and guarantees the portability of the code generated across multiple architectures and operating systems in a high-performance, secure way. In this paper we will show how it is possible to use this technology to create a network computing platform for the management of applications distributed over a network. We will de ne and implement mechanisms for the execution of applications on any server, wherever the code of interest is physically located. In
The great spread of communication networks and the availability of low-cost calculation resources have contributed to the success of distributed information systems and the introduction of new programming paradigms which exploit the enormous potential these systems oer. As a result, new distributed programming techniques have recently been developed which, together with new allocation and workload distribution strategies, allow optimal exploitation of resources and a consequent increase in both reliability and performance. The approach normally followed in the development of distributed applications is the clientserver one. The principal objective of this powerful paradigm in distributed computing is to make a collection of (possibly replicated) distributed services available on a network of computers or workstations. Although the client-server approach has contributed to revolutionizing the way in which appplications are conceived and calculation resources are exploited, it has a basic limit due to the essentially static interaction between the client and the server. The client, in fact, cannot decide arbitrarily which server to use, but has to choose from a subset of nodes on which the procedures he is interested in are installed. Users want to be able to exploit to the full the services oered by communication networks. Besides the immediate wish to communicate with each other, they want to access the data they need wherever it is and whatever format it is in. Also increasingly evident is the need for simple, safe use of the applications present on the network without having to possess speci c hardware and software architectures. 1
turn, these applications can request the execution of new processes, whose code does not necessarily have to be present locally but can be retrieved from remote servers. The approach proposed is highly exible, not least because, assuming all the network nodes to be capable of executing the Java code, an application code can be executed on any of them, without any limit due to the presence of dierent hardware platforms. As a speci c case, the approach proposed has been used to implement a network management system which, unlike the classical, essentially centralized approach, makes it possible to execute most computation remotely, thus reducing the overhead introduced on the communication system and on the central management station.
If only the name parameter is present, the run primitive executes the name application on the same node, expecting to nd the code locally. If the storage parameter is provided as well as the name, the application will be executed locally but its code will be retrieved from the storage server. Finally, if the execution parameter is given, the application will be executed on the node speci ed. In its most complete form, the run primitive executes the name application, which is physically located on the storage node, on the execution machine, providing the in par input parameters and expecting the out par output values. To make execution of this primitive completely transparent to the user, the whole platform has been developed using the Java language. On each node in the platform, therefore, there has to be a Java Virtual Machine to allow Java applications to be executed without worrying about the underlying architecture. The classes making up the various applications are thus stored and transferred in bytecode.
2 Description of the Network Computing Platform The main reasons which led us to develop the Network Computing Platform can be summarized as follows:
Server of Java Application (SJA) User
Java Node (JN)
Java Server
Java Agent
Java Node (JN) to provide simple access to network computing User User Java Agent resources; Server of Java Application (SJA) to oer the opportunity to instance processes on User Java Server system nodes without having to re-compile the Java Node (JN) User code; Java Agent to simplify procedures for migration of a code Figure 1: System architecture between two nodes; to instance processes on remote nodes in which Fig. 1 illustrates the general architecture of the systhe application code has not been pre-installed. tem proposed, in which the nodes have been classi ed as: The nal aim can therefore be summed up as a total virtualization of network resources, so a user can Java Nodes (JN) activate execution of a code on any node in the platform (even when there are dierent hardware archi- Servers of Java Applications (SJA) tectures), without having to worry about the physical Java Nodes are those on which applications can be location of the code. (execution nodes). Servers of Java ApplicaThe basic concept of the proposed approach can executed tions are nodes which act as servers to store applibe expressed by the run primitive, which accepts the cations (storage nodes). The system therefore comfollowing parameters: prises centres to collect applications (SJA) which play a role equivalent to that of the mass storage sub name: identi er of the application of interest; system in a traditional calculation system. JNs, on the other hand, have the dual role of system access in par: list of input parameters (if any); points and calculation resources on which to execute out par: list of output parameters (if any); applications. In general, however, nothing prevents a execution: identi cation of the server on which generic node from simultaneously having the role of JN and SJA: it can, in fact, both store and execute the application is to be executed; applications. To gain a better understanding of how it is possible storage: identi cation of the server on which the to implement the functions described, the following application code is to be found.
2
is created. If, on the other hand, the storage eld is not given when the run method is called, Run App will make reference to the default ClassLoader and all the class loading requests will be met locally.
sections give a complete description of the software modules to be installed in the JNs and SJAs and the relative forms of interaction.
Java Node
The following software modules have to be present on Server of Java Applications a Java Node: In an SJA the following modules are present: Run App: this is the system access interface Java Server (JS): this is a process always exewhich allows the user to use the services procuted on the node (daemon), which intercepts vided by the platform. Run App de nes the and manages all the requests for class and applirun method which implements the run primication loading from the JNs. tive described above. Thanks to the run method, Run App makes it possible to execute, locally or App DB (DB): this implements the database of applications and classes (stored in the bytecode remotely, an application whose code is on the format). The applications can be launched disame JN or on an SJA. rectly on a JN through Run App. Classes, on the other hand, can only be called inside other Java Agent (JA): this is a process which is alapplications. ways executed on the node. It is a daemon due to whose presence on the node the latter is characterized as belonging to the platform. The JA manages all interaction with JNs and SJAs and is the environment in which the subsequent applications are executed. In this section we will show how the network comThe JA module uses the NetworkClassLoader puting described can be successfully used in class which implements the mechanisms required networkplatform management, some of the limits to load applications and their constituent classes typical of a centralizedovercoming approach. Current network from remote nodes, dynamically instancing them management systems adopt a centralized inside the current application. This class derives according to which a protocol requires theparadigm managefrom the Java default ClassLoader class: it re- ment application to periodically access the data colde nes the loadClass method normally used to lected by a set of software modules located on netload classes. Use of our NetworkClassLoader aldevices. There are, however, a large number lows classes to be loaded from the network in- work of circumstances in which adoption of a distributed stead of from the local le system: it contains paradigm which can part of the control and all the mechanisms needed to transfer the byte- management functionsassign to the code of the classes from the SJA servers and to is more appropriate [2, 4]. various network nodes convert them into objects ready to be executed The basic idea is to reverse the logic according to in the application requesting them. We should which the data produced by the network devices is emphasize that once the main class of an applica- periodically transferred to the central network mantion has been loaded, with explicit reference to agement station. the servers provided by the the NetworkClassLoader, subsequent references network computingUsing platform described in the previto other classes in the application are solved au- ous sections it is possible to port the management aptomatically and are totally transparent to the plications onto the network devices, thus performing programmer. a series of micromanagement operations locally and If the run method is called making explicit ref- reducing the workload on the network management erence to the storage eld, Run App instances station and the overhead on the network as a whole. the NetworkClass Loader with this parameter: In the Internet environment, the Simple Network from now on any request for class loading will Management Protocol (SNMP) [1, 7] has become the automatically be sent to the SJA where the ap- standard protocol for network management. A netplication (and its constituent classes) physically work management protocol has to provide the primiresides. The NetworkClassLoader is provided tives for the exchange of information between agents with a cache mechanism by which memory of and management stations. SNMP agents have a classes already used is available, so as to avoid very simple structure and normally only communiasking the SJA for them whenever an instance cate in response to requests for variables stored in
3 Application to Network Management
3
4 Conclusions
the MIB. They cannot perform any management action on their local data. The centralized paradigm adopted by the SNMP is appropriate in various network management applications, but the rapid increase in the size of networks has posed the question of the scalability of this or any other centralized model. At the same time, the calculation power of network nodes has also increased, making it possible to entrust them with signi cant distributed managament functions [3]. Centralization is generally appropriate for applications where the need for distributed control is low, frequent polling of MIB variables is not required and only a small amount of information is needed. A classical example is monitoring and viewing a few MIB variables. The status of a router interface, for instance, or the status of a link only entails querying and viewing a small number of MIB variables and centralized management is therefore suitable. At the other extreme we have applications which require frequent polling of a large number of MIB variables, which have to perform calculations on a vast amount of information. An example would be calculation of a function indicating the level of functioning of the network, which requires very frequent detection of variations in a large number of MIB variables. In such cases monitoring and control should be performed as close as possible to the device in question. Using our platform we can go beyond this distribution of tasks: the various management functions in our model do not have to reside statically on certain devices, but can be retrieved from servers and dynamically executed on the particular node involved in the operation. The global architecture of the network computing platform adapted to network management requires additional modules. As we are assuming that the platform is to be integrated with current management protocols, each node will have to have a standard SNMP agent to monitor the node. To use the data recorded by this agent, it will be necessary to use a set of classes implementing the SNMP communication protocol. These classes will thus be able to commmunicate with both local and remote SNMP agents. If these classes are present on each node, higher-level management applications can be constructed. It is these applications which will be inserted in the SJA and, when needed, executed by the various clients. The system thus obtained is easy to extend: if the need arises to introduce a new management function speci c to a certain subnetwork, it will be sucient to insert it onto the server and it will automatically be executed on each node requiring it thanks to the dynamic application loading mechanism.
We have described the design and implementation of a network computing platform which provides new mechanisms for distributing and controlling process execution in a network environment. The platform has been entirely developed using the Java language which ensures full portability among dierent hardware and software platforms. The user can select the application of interest from a number of network servers: the application code will migrate to the node chosen for execution and automatically run. Any reference to remote classes is automatically resolved by a network class loader speci cally designed for this purpose. The platform described has been used to implement a distributed network management system, overcoming some of the limits typical of current centralized approaches. Future extension is the use of the platform as an environment to allow migration of software agents among dierent ATM nodes to control the quality of a Video-On-Demand service.
References [1] J. D. Case et al. A Simple Network Management Protocol (SNMP). RFC 1157, 1990. [2] G. Goldszmidt. On Distributed System Management. Proceedings of the IFIP International Symposium on Integrated Network Management, 1993. [3] G. Goldszmidt and Y. Yemini. Distributed Management by Delegation. Proc. of the 15th International Conference on Distributed Computing Systems, 1995. [4] G. Goldszmidt, Y. Yemini, K. Meyer, M. Erlinger, J. Betser, and C. Sunshine. Decentralizing Control and Intelligence in Network Management. Proc. of the 4th International Symposium on Integrated Network Management, May 1995. [5] J. Gosling. The Java Language Environment: a White Paper. Technical report, Sun Microsystems, May 1995. [6] M. A. Hamilton. Java and the Shift to NetCentric Computing. IEEE Computer, 29(8):31{ 39, August 1996. [7] Marshall T. Rose. Network Management is Simple: you just need the Right Framework. Proceedings of the IFIP Second International Symposium on Integrated Network Management, 1991. [8] E. Yourdon. Java, the Web, and Software Development. IEEE Computer, 29(8):25{30, August 1996. 4