Graphical user interface for monitoring classloading references

A method, apparatus, and system are provided for a Graphical User Interface (GUI) for monitoring classloading references. In an embodiment, the GUI includes a graphical representation of one or more resources of an application server. The one or more resources may be selectable via, for example, a cursor control device. In an embodiment, a graphical representation of a selected class loader and one or more associated classloading references are displayed in the GUI, responsive to receiving a selection input specifying one of the displayed resources.

TECHNICAL FIELD

Embodiments of the invention generally relate to the field of system resource monitoring and more particularly, to a graphical user interface for monitoring classloading references.

BACKGROUND

Many businesses are providing access to their products and services through applications that are delivered over computer networks such as the Internet. These applications typically have a multi-tiered architecture. In those cases where the applications are delivered over the Internet they are commonly referred to as Web-based applications.FIG. 1is a block diagram of a Web-based application100having a multi-tiered architecture.

Web-based application100includes client layer110, application layer120, and database layer130. Client layer110includes user interface112that runs on a client computing device such as a desktop computer, laptop computer, personal digital assistant, telephone, and the like. In a Web-based environment, user interface112is typically a Web browser. User interface112may collect input from a user and provide that input to application layer120for processing.

Database layer130includes data access logic used by business logic144to store and retrieve data in database132. Database132provides non-volatile storage (sometimes referred to as a persistent store) for the data accessed and/or processed by application layer120. Database132may be, for example, a relational database or an object-oriented database.

Application layer120includes application server122to receive and process input from client layer110. Application server122typically includes a number of subcomponents including, for example, connectivity layer140, presentation logic142, business logic144, and database interface146. Connectivity layer140provides connections to client layer110using protocols such as the HyperText Transfer Protocol (HTTP), HTTP secured through the Secure Socket Layer, the Simple Object Access Protocol (SOAP), and the like. Presentation logic142generates a Graphical User Interface (GUI) using, for example, a markup language such as the Hyper Text Markup Language (HTML). Business logic144represents the core of the application, for example, the rules governing the underlying business process (or other functionality) provided by the application. Database interface layer146provides an interface to database layer130. The Java 2 Enterprise Edition Specification v1.3, published on Jul. 27, 2001 (the J2EE Standard) defines an increasingly popular architecture for application layer120.

The popularity of the J2EE Standard is based, in part, on the hardware independent nature of the Java platform. Unlike programs written in C or C++, Java programs are not compiled into machine language for a specific hardware platform. Instead, they are compiled into an intermediate language called bytecode. The bytecode includes a binary representation of data types such as classes and interfaces. The term “class” refers to a data type that defines a collection of objects that share the same characteristics.

The executable portions of a class file are machine code for a special kind of computer called a Java Virtual Machine (JVM). The JVM is a software implementation of an execution engine for the class files. The JVM provides classes to programs as needed during runtime. The term “class loading” refers to the process of bringing a binary representation of a class into the JVM.

One or more class loaders control the loading of classes into the JVM. A “class loader” is an implementation of a class that is responsible for finding and loading class files at runtime. Class loaders are organized into parent/child hierarchies in which each “child” class loader maintains a reference to its “parent” class loader. Typically, a class loader is able to delegate the loading of a class to another class loader. For example, when a child class loader is presented with a class loading request, it checks whether its parent class loader can load the class before trying to load the class itself.

Although the multi-tiered architecture provides a more flexible and scalable architecture than traditional two-tier systems, it also results in significant added complexity. Application servers based on the J2EE Standard use a variety of class loaders to, for example, load J2EE components. In addition, a separate class loader may be used to load the classes for each application deployed to the application server. These class loaders may use a relatively complex set of references to delegate the loading of classes to one another.

SUMMARY OF THE INVENTION

A method, apparatus, and system are provided for a Graphical User Interface (GUI) for monitoring classloading references. In an embodiment, the GUI includes a graphical representation of one or more resources of an application server. The one or more resources may be selectable via, for example, a cursor control device. In an embodiment, a graphical representation of a selected class loader and one or more associated classloading references are displayed in the GUI, responsive to receiving a selection input specifying one of the displayed resources.

DETAILED DESCRIPTION

A method, apparatus, and system are provided for a Graphical User Interface (GUI) for monitoring classloading references. In an embodiment, the GUI includes a graphical representation of one or more resources of an application server. The one or more resources may be selectable via, for example, a cursor control device. In an embodiment, a graphical representation of a selected class loader and one or more associated classloading references are displayed in the GUI, responsive to receiving a selection input specifying one of the displayed resources.

FIG. 2is a block diagram of distributed system200implemented to provide an offline and online graphical user interface for monitoring classloading references according to an embodiment of the invention. In the illustrated embodiment, distributed system200includes class loader monitor210, database220, and file system230. In an alternative embodiment, distributed system200may include more elements, fewer elements, and/or different elements.

Database220is a persistent store for data and programs. In an embodiment, database220includes a Database Management System (DBMS) to control the persistently stored data including the overall organization of the data, retrieval of the data, and integrity of the data. In one embodiment, database220stores configuration data240to define one or more communicatively coupled application servers.

In an embodiment, configuration data240provides configuration data for a “cluster” of application servers. An application server cluster (or simply, cluster) broadly refers to a group of communicatively coupled application servers. The cluster may include one or more application server “instances,” a central database (e.g., database220) and central services. In an embodiment, an application server “instance” includes a group of redundant application servers and a dispatcher (cluster elements). The dispatcher distributes server requests to each of the redundant application servers based on the load of each of the servers. The instances may communicate with each other via a messaging service of the central services. Generally, the cluster elements share a central database. In an embodiment, the cluster may be centrally defined and configured in the central database. In an alternative embodiment, configuration data240may merely provide configuration data for a single application server.

In the illustrated embodiment, configuration data240includes cluster data242and server data244. Cluster data242may include, for example, configuration data that is associated with all servers (e.g., dispatchers and application servers) within the cluster. Server data244provides configuration data for a particular server. In an embodiment, server data244includes services data246and applications data248. The term “service” refers to functionality derived from a particular software program. In one embodiment, an application server may include the services defined by the J2EE Standard and proprietary services defined by the application server vendor. In an embodiment, services data246provides the configuration data for the services available to an application server.

In an embodiment, one or more class loaders load the classes that make up the services defined in services data246. Typically, each of these class loaders attempts to delegate the loading of classes to a number of other class loaders before loading the class itself. Also, any given class loader may have a load operation passed to it by one or more class loaders. The term “classloading references” refers to the various delegation relationships between class loaders. The classloading references may be initially, defined by, for example, a developer and then, in some cases, the references may be modified after the application server is installed. Classloading references data247illustrates data that defines classloading references for one or more services.

One or more applications may be deployed to an application server. The deployed applications may provide the business logic (e.g., business logic144, shown inFIG. 1) in an enterprise network. Applications data248illustrates the configuration data for the applications deployed to an application server. In one embodiment, the application data248may be for example, Enterprise Application Archive files (EARs) or Java archive files (JARs). In one embodiment, each application deployed to an application server has a separate class loader. Classloading references data249illustrates data that defines classloading references for one or more services.

In an embodiment, class loader monitor210provides graphical information about class loaders, class loading hierarchies, and classloading references. As is further described below, class loader monitor210may provide both offline and online monitoring of the class loading system of an application server or a cluster of application servers. The term “offline” refers to, for example, monitoring a class loading system when an application server is not running. In one embodiment, class loader monitor210provides a central management system for class loaders. Centralized management of class loaders and their associated classloading references is especially important for J2EE application servers because these servers use a large number of class loaders each potentially having a number of classloading references.

In an embodiment, class loader monitor210obtains class loader data and classloading references data (e.g., class loader/classloading references data247and249) from database220. For example, scanner250may scan configuration data240to obtain class loader/classloading references data247and249. Scanner250may be a manager or other software entity capable of searching for and retrieving data from database220.

In one embodiment, class loader monitor210may parse the data obtained from database220. For example, a Strongly Connected Components (SCC) algorithm may be used to find the cyclic relationships defined in class loader/classloading references data247,249. Alternatively, class loader monitor210may use different algorithm(s) and/or additional algorithms to parse class loader/classloading references data247,249.

In an embodiment, class loader monitor210provides a graphical user interface (GUI) to monitor the obtained data. The GUI may display a selected class loader and the relationships between the selected class loader and other class loaders (e.g., classloading references) within an application server (or selected cluster node). The GUI provided by class loader monitor210(and its runtime representative) are further discussed below with reference toFIGS. 3-7.

FIG. 3illustrates a Graphical User Interface (GUI)300provided by a class loader monitor, according to an embodiment of the invention. The illustrated embodiment of GUI300includes panels310and320. The term “window” refers to a scrollable viewing area on a screen. The term “panel” broadly refers to a sub-section of a window if, for example, the window is divided into two or more regions. Typically panels and windows are rectangular in shape but they are not required to be rectangular.

In the illustrated embodiment, panel310displays hierarchical tree structure312having one or more tree nodes. Hierarchical tree structure312may be based on the data obtained from a database (e.g., database220, shown inFIG. 2). In one embodiment, each of the one or more tree nodes represents a resource within an application server. In the illustrated embodiment, the displayed portion of hierarchical tree structure312has a number of tree nodes representing services provided by an application server. For example, HTTP node314represents the HyperText Transfer Protocol (HTTP) service provided by an application server.

In an embodiment, each tree node may have a number of depending tree nodes. Each of the depending tree nodes may represent a component or sub-part of the resource represented by the “parent” tree node. For example, in the illustrated embodiment, HTTP node314has, for example, depending tree nodes316representing additional info for the HTTP service.

In an embodiment, a cursor control device (e.g., a pointing device and/or a keyboard) may be used to select one or more of the tree nodes displayed in panel310. In the illustrated embodiment, for example, HTTP node314is selected. In such an embodiment, panel320may display information about a portion of the class loading system associated with the selected tree node. For example, class loader322represents the class loader for the HTTP service. For ease of discussion, the displayed class loader that represents the selected resource is referred to as the selected class loader.

In an embodiment, classloading references are permitted to be circular. That is, even if class loader A delegates (or refers) to class loader B, class loader B may also be allowed to refer to class loader A. In such cases, panel320may display a single class loader to represent one or more components that refer to each other. The term “common class loader” refers to a class loader that represents two or more class loaders having circular references. In the illustrated embodiment, class loader322is a common class loader representing, for example, a class loader for the HTTP service and a class loader for a Java Server Page (JSP) servlet.

As described above, a class loader delegates the loading of classes (or, for ease of discussion, may refer) to its parent class loader. Class loader324represents the parent class loader of common class loader322. In an embodiment, the complete “ancestry” of a class loader may be displayed. For example, boot class loader326represents the primogenitor class loader of common class loader322.

In an embodiment, the conventional delegate-to-parent delegation model is extended. In other words, common class loader322first attempts to delegate a load operation to parent class loader324. If parent class loader324is unable to load the class, common class loader322may then attempt to load the class through any number of referenced class loaders. The classloading references may be defined by, for example, a developer and/or an administrator. Classloading references328illustrate the delegation references defined for common class loader322.

In an embodiment, each classloading reference328includes a reference type indicator (e.g., reference type indicator330) and a representation of a class loader (e.g., class loader332). In an embodiment, each of the class loaders represented by classloading references328may become the selected class loader by selecting it with, for example, a cursor control device. For example, class loader332may take the place of common class loader322, if it is selected via a cursor control device. Reference type indicator330provides a mechanism for illustrating the degree to which one class loader may depend on another class loader. In one embodiment, there are four types of references: parent, notify, hard, and soft. The parent type reference is described above.

In an embodiment, the hard and soft reference types may determine, for example, the “start-up” order of the class loaders. For example, in one embodiment, a hard reference type indicates that the referenced class loader is to be automatically loaded when the referring class loader is loaded. The soft reference type may indicate that the referenced class loader need not be automatically loaded when the referenced class loader is loaded. The notify reference type may indicate that the referenced class loader (and/or its associated service or application) is to be notified when the referring class loader is loaded. In an alternative embodiment, more reference types, fewer reference types, and/or different reference types may be used.

In an embodiment, the color of reference type indicator330indicates the reference type. For example, if reference type indicator330is green, then the reference type is soft. Similarly, the color brown may indicate a hard reference type and the color blue may indicate a parent reference type. In an alternative embodiment, a different scheme may be used to distinguish one reference type from another. For example, a selection of line weights, line patterns, symbols, etc. may be used to distinguish one reference type from another.

In one embodiment, panel320displays a graphical representation of one or more class loaders that delegate (or refer) to common class loader322. These class loaders may be referred to as “referencing” class loaders since they refer to the selected class loader (e.g., common class loader322). Classloading references334illustrate a number of class loaders (e.g., referencing class loaders) referring to selected class loader332. In an embodiment, each classloading reference334includes a reference type indicator (e.g., reference type indicator336) and a representation of a class loader (e.g., class loader338). In an embodiment, each of the class loaders represented by classloading references334may become the selected class loader by selecting it with, for example, a cursor control device.

In an embodiment, class loaders may be organized into the following groups: interfaces, libraries, services, and applications. The name of each displayed class loader may include the name of its parent group (e.g., service: HTTP). In one embodiment, there is a separate class loader for each application deployed to an application server.

FIG. 4illustrates a Graphical User Interface (GUI)400to monitor application class loaders, according to an embodiment of the invention. The illustrated embodiment of GUI400includes panels410and420. In the illustrated embodiment, panel410displays hierarchical tree structure412having one or more tree nodes. In an embodiment in which an application server is part of a cluster of application servers, each of the one or more tree nodes represents a resource within the cluster of application servers. For example, in the illustrated embodiment, cluster node414is a tree node that represents the entire cluster of application servers. Similarly, server node416represents an application server within the cluster.

In the illustrated embodiment, applications node418contains data about one or more applications deployed to the server represented by server node416. In one embodiment, each application deployed to the server is represented by a depending tree node. For example, Web services node422represents a Web services tool deployed to the server.

In an embodiment, a cursor control device may be used to select one of the application tree nodes depending from applications node418. In the illustrated embodiment, for example, Web services tool node422is selected (e.g., as shown by the highlighting). In such an embodiment, panel420may display class loading system data associated with the selected application. For example, class loader424is a graphical illustration of the selected application's class loader. For ease of discussion, the displayed class loader that represents the selected resource is hereinafter referred to as the selected class loader.

In an embodiment, panel420displays classloading references for selected class loader424. For example, class loader426is the parent class loader for selected class loader424. In an embodiment, classloading references428represent a number of referencing class loaders. That is, classloading references428represent a number of class loaders that delegate (or refer) to selected class loader424. In an embodiment, each classloading reference428includes a reference type indicator (e.g., reference type indicator430) and a representation of a class loader (e.g., class loader432). In an embodiment, each of the class loaders represented by classloading references428may become the selected class loader by selecting it with, for example, a cursor control device.

As described above with reference toFIG. 2, a class loader monitor may obtain configuration data that describes an application server (or a cluster of application servers) from a database (e.g., database220, shown inFIG. 2). The obtained data may include class loader data (e.g., which class loader loads a given class) and classloading references data (e.g., to which class loader(s) does a given class loader delegate load operations). Collectively this data may be referred to as “class loader resource data.”

In an embodiment, applications that are deployed to a server have a number of components (e.g., Web components, Enterprise Java Bean components, etc.) that are packaged together in an Enterprise Application Archive (EAR) file. The EAR file also typically includes a number of deployment descriptors that describe how the components interrelate both with each other and with the environment in which they will be deployed. In one embodiment, the class loader resource data for a given application may be obtained from one or more of the deployments descriptors for the application.

FIG. 5illustrates a logical view of selected elements of configuration data for an application server, according to an embodiment of the invention. In the illustrated embodiment, the configuration data may include application data510. Application data510may include, for example, one or more EAR files (e.g., EAR file520). EAR file520includes deployment descriptor530to describe the relationships between the components of EAR file520. In one embodiment, a class loader monitor may obtain class loader resource data from, for example, deployment descriptor530and provide that data in a graphical user interface (e.g., GUI400).

An application server may provide a number of interfaces, services, etc. that may, collectively, be called application server components. The application server components may be specified, at least in part, by a standard (e.g., the J2EE Standard) or they may be proprietary. These application server components may be defined in configuration data that is stored on a database (e.g., database220, shown inFIG. 2). For example, in one embodiment, the application server components are described in a number of mark-up language files called provider Extensible Markup Language (XML) files. In one embodiment, the class loader monitor obtains class loader resource data for a given application server component from the provider XML files for the component.

FIG. 6illustrates a logical view of selected elements of configuration data for an application server, according to an embodiment of the invention. In the illustrated embodiment, the configuration data includes application server component data610. Application server component data610includes a number of provider XML files to describe the component (e.g., provider XML file620). In one embodiment, a class loader monitor may obtain class loader resource data from, for example, provider XML file620and provide that data in a graphical user interface (e.g., GUI400).

In one embodiment, a file editor having write access to the database may be used to modify a file containing class loader resource data. For example, in the illustrated embodiment, editor630displays the contents of provider XML620. An end-user may alter the data displayed in editor630and upload it to the database.

FIG. 7illustrates a Graphical User Interface (GUI)700to monitor class loaders during runtime, according to an embodiment of the invention. GUI700may be provided, at least in part, by a service running an application server called a class loader viewer service. In one embodiment, the class loader viewer service provides runtime control for monitoring classloading references of an application server (or a cluster node).

The illustrated embodiment of GUI700includes panels710,720, and730. In the illustrated embodiment, panel710displays hierarchical tree structure702having one or more tree nodes. In an embodiment in which an application server is part of a cluster of application servers, each of the one or more tree nodes represents a resource within the cluster of application servers. For example, in the illustrated embodiment, cluster node712is a tree node that represents the entire cluster of application servers. Similarly, server node714is a server node that represents an application server within the cluster.

Services node716represents the services provided by a cluster node. In one embodiment, each node depending from services node716represents a particular service. For example, class loader viewer node718represents the class loader viewer service. In an embodiment, runtime class loading system data for server714may be viewed by selecting class loader viewer service718.

In an embodiment, runtime tab722provides access to panels720and730. Panel720may display a hierarchical tree structure of a number of components registered on server node714. In one embodiment, the class loaders are organized into the following groups: interfaces, libraries, services, and applications. For example, services node724represents the class loaders for the services of server node714. In one embodiment, the class loaders displayed in panel720are selectable via, for example, a cursor control device. In response to selecting one of the displayed class loaders, a graphical representation of the selected class loader and its classloading references is displayed in panel730.

For example, in the illustrated embodiment, monitor class loader726is selected in panel720. Class loader732, shown in panel730, is a graphical representation of monitor class loader726. Panel730also displays a number of classloading references associated with class loader732. For example, class loader732references parent class loader734as well as referenced class loaders736. In one embodiment, referenced class loaders736are displayed in the order in which they were configured into the configuration data stored on a database. In an embodiment, any of the referenced class loaders may become the “selected” class loader (e.g., displayed in the middle and surrounded by its associated references) by being selected with a cursor control device.

Turning now toFIG. 8, the particular methods associated with embodiments of the invention are described in terms of computer software and hardware with reference to a flowchart. The methods to be performed by a visual administrator for specifying service references to support a service may constitute state machines or computer programs made up of computer-executable instructions. The computer-executable instructions may be written in a computer programming language or may be embodied in firmware logic. If written in a programming language conforming to a recognized standard, such instructions can be executed on a variety of hardware platforms and for interface to a variety of operating systems. In addition, embodiments of the invention are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement embodiments of the invention as described herein. Furthermore, it is common in the art to speak of software, in one form or another (e.g., program, procedure, process, application, etc.), as taking an action or causing a result. Such expressions are merely a shorthand way of saying that execution of the software by a computing device causes the device to perform an action or produce a result.

FIG. 8is a flow diagram illustrating certain aspects of a method for monitoring classloading references, according to an embodiment of the invention. Referring to process block810component resource data is accessed from a database. In one embodiment, an application server (or a cluster of application servers) is defined by configuration data stored on a database. The configuration data may include data indicating which class loader(s) is to load a given resource. In addition, the configuration data may indicate to which class loader(s), if any, a given class loader is to delegate a load operation. In an embodiment, the term class loader resource data refers to the class loader data and the classloading references data. The data may be obtained by, for example, scanning the database (e.g., with scanner250, shown inFIG. 2).

Referring to process block820, a graphical representation of the obtained component resource data is displayed in a Graphical User Interface (GUI). In an embodiment, the GUI displays, for example, a hierarchical tree structure of an application server's resources such as services and/or deployed applications. In addition, the GUI may display one or more class loaders and associated classloading references.

Referring to process block830, a class loader monitor receives selection input from, for example, an end-user who is monitoring a class loading system. The received selection input may be an indication from a cursor control device, keyboard, touch-screen display, voice activated peripheral, etc. In an embodiment, the selection input may specify a displayed resource (e.g., HTTP service314, shown inFIG. 3) or a displayed class loader (e.g., displayed class loader332, shown inFIG. 3).

Referring to process block840, a graphical representation of a selected class loader is displayed (e.g., common class loader322). In war embodiment, the selected class loader may be a class loader that loads classes for a resource selected in process block830. Alternatively, the selected class loader may be a class loader that is initially displayed as a referenced class loader and is then selected via, for example, a cursor control device to become the selected class loader.

Referring to process block850, a graphical representation of one or more classloading references that are associated with the selected class loader are displayed in the GUI. Examples of classloading references may include: a reference to a parent class loader; a reference to a class loader to which the selected class loader is to delegate a load; and/or a reference from a class loader that is to delegate a load to the selected class loader (e.g., a referencing class loader). In one embodiment, each classloading reference includes a reference type indicator and a class loader (e.g., either referenced or referencing).

FIG. 9is a block diagram of computing device900implemented according to an embodiment of the invention. Computing device900may include: processor(s)910, memory920, one or more Input/Output interfaces930, network interface(s)940, and class loader monitor950. The illustrated elements may be connected together through system interconnection970. Processor(s)910may include a microprocessor, microcontroller, field programmable gate array (FPGA), application specific integrated circuit (ASIC), central processing unit (CPU), programmable logic device (PLD), and similar devices that access instructions from system storage (e.g., memory920), decode them, and execute those instructions by performing arithmetic and logical operations.

Class loader monitor950enables computing device900to provide a GUI for monitoring a class loading system. Class loader monitor950may be executable content, control logic (e.g., ASIC, PLD, FPGA, etc.), firmware, or some combination thereof, in an embodiment of the invention. In embodiments of the invention in which class loader monitor950is executable content, it may be stored in memory920and executed by processor(s)910.

Memory920may encompass a wide variety of memory devices including read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), non-volatile random access memory (NVRAM), cache memory, flash memory, and other memory devices. Memory920may also include one or more hard disks, floppy disks, ZIP disks, compact disks (e.g., CD-ROM), digital versatile/video disks (DVD), magnetic random access memory (MRAM) devices, and other system-readable media that store instructions and/or data. Memory920may store program modules such as routines, programs, objects, images, data structures, program data, and other program modules that perform particular tasks or implement particular abstract data types that facilitate system use.

One or more I/O interfaces930may include a hard disk drive interface, a magnetic disk drive interface, an optical drive interface, a parallel port, serial controller or super I/O controller, serial port, universal serial bus (USB) port, a display device interface (e.g., video adapter), a network interface card (NIC), a sound card, modem, and the like. System interconnection970permits communication between the various elements of computing device900. System interconnection970may include a wide variety of signal lines including one or more of a memory bus, peripheral bus, local bus, host bus, bridge, optical, electrical, acoustical, and other propagated signal lines.

Elements of embodiments of the present invention may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards or other type of machine-readable media suitable for storing electronic instructions.