The Management of a BAN using JMX 1.2.1

Document Sample
The Management of a BAN using JMX 1.2.1 Powered By Docstoc
					The Management of a BAN using JMX 1.2.1
                 a case study




                                        Bachelor Thesis for Telematics
                                        by R J van den Berg
                                        from the University of Twente,
                                        Enschede, The Netherlands


                                        Committee:
                                        Dr.ir. B.J.F. van Beijnum
                                        Dr.ir. A.T. van Halteren


           Enschede, The Netherlands,
                 Januari, 2006
R J van den Berg   The management of a BAN using JMX 1.2.1, a case study




                                                                       i
R J van den Berg                                 The management of a BAN using JMX 1.2.1, a case study




Abstract
Mobile devices become more advanced every day, and, with their advancement so are their purposes.
The development of software and hardware, which assist us in our every day lives, becomes more and
more complicated and our expectations rise. One major focus of this case study is on the health of
such a device, i.e. a BANs MBU.


To ensure the health of a mobile device, it needs to be managed. In this case study a first step is
done to create a management environment capable of managing a mobile device. The case study
answers the question whether or not it is feasible to remotely monitor resources on a BANs MBU with
SUNs JMX technology. By proofing this concept a new area of research is opened which ultimately has
the goal to ensure the health of the mobile device. The result is achieved on a J2ME-PP platform and
in a JMX 1.2.1 environment, running an HTML-adaptor and Standard MBeans.




                                                                                                    ii
R J van den Berg                                                               The management of a BAN using JMX 1.2.1, a case study




Table of Contents
Abstract ......................................................................................................... ii

Table of Contents ......................................................................................... iii

Preface ..........................................................................................................vi

List of figures ..............................................................................................viii

1.       Introduction ......................................................................................... 1
  1.1.     Motivation ............................................................................................................................................ 1

  1.2.     Goal & approach ................................................................................................................................. 2

  1.3.     Report structure .................................................................................................................................. 3

2.       Background .......................................................................................... 5
  2.1.     Body Area Network – Architecture ................................................................................................... 5
     2.1.1.        BAN physical architecture ............................................................................................................ 5
     2.1.2.        BAN services ................................................................................................................................ 6
     2.1.3.        BAN service platform ................................................................................................................... 6

  2.2.     BAN implementation technology........................................................................................................ 7

  2.3.     BAN management................................................................................................................................ 9
     2.3.1.        BAN Management Agent and Management Resources................................................................ 9
     2.3.2.        BAN Management Applications ................................................................................................... 9
     2.3.3.        JMX as an implementation technology....................................................................................... 10
     2.3.4.        The JMX architecture ................................................................................................................. 10

3.       Manageable BAN resources................................................................ 13
  3.1.     Extracting contents for manageable BAN resources ...................................................................... 13

  3.2.     Host Resources for a Management Agent ....................................................................................... 14
     3.2.1.        BAN Software Process Model .................................................................................................... 14
     3.2.2.        BAN Resource Instrumentation .................................................................................................. 15




                                                                                                                                                                 iii
R J van den Berg                                                          The management of a BAN using JMX 1.2.1, a case study



4.       Design of the BAN management agent.............................................. 17
  4.1.     Structure of the Performance Agent Design ................................................................................... 17

  4.2.     Behavior of the Performance Agent design ..................................................................................... 20
     4.2.1.       Phase 1: jmxAgent set-up ........................................................................................................... 21
     4.2.2.       Phase 2: banSystem set-up.......................................................................................................... 21
     4.2.3.       Phase 3: Remote updateRunningSoftware .................................................................................. 22

  4.3.     The Performance Agent prototype................................................................................................... 23
     4.3.1.       Phase 1: Agent and adaptor initialization.................................................................................... 23
     4.3.2.       Phase 2: BANSystem initialization............................................................................................. 23
     4.3.3.       Phase 3: Process contents and remote updateRunningSoftware ................................................. 23

5.       Conclusion & Recommendations ....................................................... 31

Reference .................................................................................................... 33

List of Abbreviations ................................................................................... 35

Appendix A .................................................................................................. 37




                                                                                                                                                      iv
R J van den Berg   The management of a BAN using JMX 1.2.1, a case study




                                                                      v
R J van den Berg                                     The management of a BAN using JMX 1.2.1, a case study




Preface
This report forms the completion of my bachelor education, which was a very instructive and
challenging time for me. Over the last few years I have come to realize that it is not only “what you
do”, but maybe even more important “how you get there”. I’m blessed with many friends who were
always more than ready to assist me.


When I reflecting upon the last few years I always remember a good friend of mine asking when I
thought it was time to slow down a bit. And when I come to think about it I only barely made it to the
next level every time. In the end nature slowed me done, and I learned my lesson. The completion of
this thesis could not have been accomplished with out me learning to look back at what I am doing.


I like to thank my supervisors, Bert-Jan van Beijnum and Aart van Halteren, for whom it could not
have been easy to keep my mind in focus of the task ahead. In the end I think they succeeded in
teaching me to focus and the results from different projects are already coming in. I specifically like to
thank two of my fellow students for the glorious time we spent working on our bachelor assignments
and the priceless feedback and fun they provided.


The current result of my study could not have been accomplished without the inexhaustible love and
attention from my mother and sister. In difficult times family is priceless and I hope my father is
proud to see this next step in my life.


Finally I would like to thank my girlfriend Berit, who entered my life as if she has always been here
and from whom I since have been inseparable.


Enschede, 18 januari 2006
Ruben van den Berg




                                                                                                        vi
R J van den Berg   The management of a BAN using JMX 1.2.1, a case study




                                                                     vii
R J van den Berg                                                     The management of a BAN using JMX 1.2.1, a case study




List of figures
Figure 1 BAN abstract overview...................................................................................................... 5
Figure 2 BAN service platform ........................................................................................................ 7
Figure 3 Java 2 Platform overview .................................................................................................. 8
Figure 4 J2ME-PP API .................................................................................................................... 8
Figure 5 The JMX architecture .......................................................................................................12
Figure 6 Result from a ps-command ..............................................................................................14
Figure7 Entity Relationship Diagram ..............................................................................................15
Figure 8 BAN Resources JMX Instrumentation-level ........................................................................15
Figure 9 Performance Agent JMX architecture ................................................................................18
Figure 10 Performance Agent design Class diagram........................................................................20
Figure 11 Sequence diagram HTML adaptor initialization.................................................................21
Figuur 12 Sequence diagram banSystem initialization .....................................................................22
Figuur 13 Sequence diagram remote updaterRunningSoftware........................................................22
Figure 14 JMXAgent initialization ...................................................................................................24
Figuur 15 JMXAgent initialization web-interface ..............................................................................24
Figure 16 BANSystem initialization: updateRunningSoftware ...........................................................25
Figure 17 JMXAgent initialization of the BANSystemMBean..............................................................26
Figure 18 JMXAgent initialization of BANSystemMBean web-interface ..............................................27
Figure 19 JMXAgent RunningSoftwareMBean..................................................................................28
Figure 20 JMXAgent BANSystem updateRunningSoftware operation ................................................29




                                                                                                                                       viii
R J van den Berg   The management of a BAN using JMX 1.2.1, a case study




                                                                      ix
R J van den Berg                                     The management of a BAN using JMX 1.2.1, a case study




                    1.           Introduction



1.1.         Motivation

Information Technology has become more accustomed among different sectors in our society. For
example the use of the personal computer with Internet in Dutch households has increased from 14%
in 1998 to 64% in 2004 [1]. Similar explosions of ICT use can be seen around the world. In the
healthcare sector the use of ICT has become a lifesaver by, for example, reducing the time needed to
determine a patients prognoses by transmitting valuable information from an ambulance to the
hospital. However, the same ICT can also cause problems when a doctor isn’t able to acquire the
patient’s information due to bureaucracy or other limitations [2]. In other sectors people are getting
more used to the fact that we have certain luxury technology, for example the mobile phone.


One of the latest upcoming devices is the Personal Digital Assistant (or PDA). A PDA is a small
handheld computer capable of executing light applications, such as mobile versions of Microsoft
Office, to assist the user. One of the main benefits of the PDA is that the user can carry it around.
Current models are featured with wireless networks (like Bluetooth or WiFi) GPS and strong CPU’s.
The PDA’s of the (near) future will evolve into more capable processing machines, comparable with
current desktop pc’s. This development will allow applications to be developed on a light and wearable
device, which assist us in our every day life. Examples are booking a flight or hotel while sitting in the
garden, or the use of a route planner that thinks further than planning a route from A to B.


Another sector where the PDA is used is the healthcare industry. Through wired or wireless (i.e.
Bluetooth) communication, sensors and actuators are controlled by the PDA. The sensors function to
monitor a patient’s condition and the actuators are also capable of performing functions, e.g. the
administering of medicine, in specific scenarios. An example of such a scenario is an epileptic patient
who is about to have a seizure. The monitoring part of the system notices hart fluctuations indicating
a seizure is most probably to occur within the next 5 minutes. The PDA, functioning as a central
computer in a web of small devices, receives the sensor-data and warns a hospital system through the
Internet in case of an emergency. The hospital system is then able to send assistance to the patient,
i.e. an ambulance is dispatched and a neighbor is alarmed [3]. The combination of different devices
linked together around a person is called a Body Area Network (BAN). More on BANs can be found in
chapters 2.1 and 2.3. Throughout this report we will make use of this healthcare scenario to illustrate
the use of a BAN.




                                                                                                        1
R J van den Berg                                   The management of a BAN using JMX 1.2.1, a case study


The advantage of this application is that the patient is allowed to walk freely and continue a normal
day life as much as possible, in contrast to feeling more insecure and probably be in need of constant
medical attention. With other illnesses this might even reduce the number of, otherwise, used hospital
beds and even significantly reduce the recovery time. A major disadvantage could be the false feeling
of being safe, while in fact the wireless connection to the medical centre is down. To make sure the
system is always able to provide the patient and the medical centre system with valuable information,
the system itself needs to be monitored and managed to ensure its own health.



1.2.           Goal & approach

To be able to manage a system, the first thing you need is information about this system. This
information includes static data, like available hardware, and dynamic data, like system or network
performance, which represents the health of the system.


Monitoring a BAN is one of the main issues discussed in this report. The first question one needs to
ask when one wants to monitor a system is: What needs to be monitored? The second question: How
do I monitor this resource? The object to be monitored is referred to as a resource, e.g. remaining
battery lifetime, available network bandwidth, or available CPU-time.


One of the key issues concerning a PDA application, are the constraints of a PDA. A PDA has fewer
capabilities compared to a modern day desktop or server PC. One of the practical constraints of the
PDA is that we need to work with a simplified version of Java. The PDA in our project runs on a Linux
version 0.7-rc23 with a 2.4.19-rmxk6-pxa1-hh1 kernel or Windows CE platform with a Java 2 Micro
Edition Personal Profile (J2ME-PP) Java platform by SUN (See Chapter 2.3 for a detailed introduction
to J2ME-PP).


To manage a system, SUN developed a reference implementation of the Java Management eXtension
specification (the reason why we chose the JMX specification for managing the BAN is elaborated in
chapter 2.3.3). This leads us to the main goal and its accompanying research question for this project:


    -   To demonstrate the feasibity of managing BAN resources using the SUN Java Management
        eXtensions 1.2.1 Reference Implementation.


    -   Is it possible to (remotely) monitor BAN process information with the SUN JMX 1.2.1
        Reference Implementation?




                                                                                                      2
R J van den Berg                                    The management of a BAN using JMX 1.2.1, a case study



1.3.         Report structure

The remainder of this report is structured as followed.


Chapter 2 provides the reader with background information needed to comprehend the “what and
how” to manage the BAN. First, an illustration of the BAN architecture is given, that is used at our
research group ASNA [4]. We elaborate the physical structure of a BAN, the services it provides and
the service platform from which it runs its applications. Secondly, we discuss the BAN implementation
technology, which includes the BAN development process and the J2ME-PP platform. Finally, general
information about BAN management is introduced. This includes information about BAN management
agents and managed resources, BAN management applications, the “why” we chose JMX as an
implementation technology and concluding the chapter we explain the JMX architecture itself.


Chapter 3 provides the reader with the “What” question from above. What needs to be monitored is
identified as manageable BAN resources. The next section goes deeper into the subject, by explaining
host resources for a management application. This presents the reader with instrumentation on which
to build our management agent.


In chapters 4 the “How” question is answered by illustrating the structure and behavior of a
management agent for the BAN on a PDA, resulting in a prototype. The demonstration of this
prototype ultimately shows the feasibility of managing BAN resources using SUN Java Management
eXtension 1.2.1 Reference Implementation, the final goal of this project.


Chapter 5 concludes the report by presenting our findings and providing the reader with
recommendations for use and future research.




                                                                                                       3
R J van den Berg   The management of a BAN using JMX 1.2.1, a case study




                                                                      4
R J van den Berg                                   The management of a BAN using JMX 1.2.1, a case study




                   2.          Background


This chapter introduces the essential background information about the most important components
contained in this report. The first section provides the reader with an introduction to a Body Area
Network (BAN). Starting with an elaboration on the BAN architecture, this consists of the BAN physical
structure, the BAN services and the BAN service platform. The second paragraph continues with the
BAN implementation technology. It shows the Java 2 Micro Edition – Personal Profile (J2ME-PP)
platform that is used for building applications on the BAN. The third and final paragraph of chapter 2
provides the reader with general information about BAN management. First we elaborate on BAN
management agents and managed resources. Secondly are the BAN management applications. Thirdly
the reader is provided with an answer to the “why question”, concerning the use of Java Management
eXtension (JMX) as an implementation technology. Fourthly an abstract in introduction to the JMX
architecture is provided.



2.1.         Body Area Network – Architecture

2.1.1.       BAN physical architecture

The BAN is defined as “a collection of (inter) communication devices which are worn on the body,
providing an integrated set of personalized services to the user”. [5, 6] The BAN uses a Mobile Base
Unit (MBU) as a gateway to communicate with local (wireless) devices in the direct surroundings of
the body on the one hand and with the outside world, through the Internet, on the other hand (Figure
1).




Figure 1 BAN abstract overview




                                                                                                      5
R J van den Berg                                      The management of a BAN using JMX 1.2.1, a case study


The MBU can consist of a PDA, or any other device capable of performing the above service. The
communication that exists between local devices and the MBU is called intra-BAN communication, e.g.
Bluetooth. The communication of the BAN with the outside world is called extra-BAN communication,
e.g. Wireless LAN, GPRS or UMTS. A local device can be self-supporting or front-end supported. Most
of the local devices have very little or no computational power and other resources, e.g. battery
power. The choice of the MBU, the means of communication and the local devices depend on the
actual implementation of the BAN service. [7, 8, 9]

2.1.2.       BAN services

The BAN provides services in which the MBU works as a central device relaying and processing data to
and from local devices to and from the outside world. The MBU can accommodate various applications
with different requirements, e.g. specific for healthcare, and local devices, e.g. a heartbeat sensor.


In the case of a patient being monitored, the (wireless) local devices consist of sensors and actuators,
worn on or attached to the body of the patient, with the primary function to monitor the patient’s
health. The idea is that the MBU acquires and processes the data from the local devices. Analyzing the
data, the MBU is able to perform certain actions to assist the patient, e.g. alarming the patient of an
imminent epileptic seizure which allows him to find a safe place to lie down. Thus, the service
provided by the BAN is to monitor the patient during his normal day life and alarm him when an
alarming situation is imminent. [8, 9]


A second BAN service can be the scenario in which the BAN assists a visual handicapped person with
his normal daily activities. The user is able to talk to his MBU through a local device, e.g. a
microphone, and provide it with specific requests. For example, the user wants to travel to a
restaurant. The MBU, being connected to the internet, is able to acquire information, like public
transport or restaurant information. The MBU is also able to book a table at a restaurant or dial the
number so the user is able to book it himself with the help of (another) local device, i.e. a (wireless)
headset. [10]


There are various possibilities for the use of a BAN; these are only two but give an impression. We
use the patient monitoring example to elaborate in certain sections of the report.

2.1.3.       BAN service platform

The BAN service platform consists of the local device services, intra- and extra-BAN communication
providers, and the BAN service layer (Figure 2). In the area on the left side the BAN is placed in
contrast to the outside world in the right side of the area. Inside the BAN from left to right the local
devices are connected to the MBU via the intra-BAN communication provider. The local devices
provide the local device services, e.g. heartbeat or blood pressure functions. Inside the MBU we have
the BAN applications connected to the BAN service layer by Application Interaction (API) points. The


                                                                                                         6
R J van den Berg                                     The management of a BAN using JMX 1.2.1, a case study


implementation of the applications depends on the actual use of the BAN itself (e.g. healthcare). The
BAN service layer communicates to the outside world via the extra-BAN communication provider (e.g.
UMTS). In the outside world area an applications area exists to illustrate the remote services with
which the BAN service layer may communicate, e.g. remote monitoring applications, web-services or
databases.




Figure 2 BAN service platform



2.2.          BAN implementation technology

The technology used for the applications and services running on the BAN MBU is Java 2 Micro Edition
– Personal Profile (J2ME-PP). J2ME-PP is part of the J2ME platform. Java applications developed for
J2ME are designed to run on small, resource constrained computer devices, e.g. a PDA or
Smartphone.


In Figure 3 the Java 2 platform is depicted in an overview. It shows that the J2ME subsection,
illustrated by the dotted line, is subdivided into 2 columns and each with different layers. The
highlighted (left) column consists of the Connected Device Configuration (CDC), Foundation Profile
(FP), Personal Basis Profile (PBP), Personal Profile (PP) and optional packages.


The layers enable the developer to reach requirements limited by the constraints of the device. In
J2ME these layers are defined as configurations, profiles and optional packages. The CDC is designed
for devices that are less restricted, e.g. a PDA or Smartphone. The CDC is a superset of Connected
Limited Device Configuration (CLDC) such that CDC includes all the classes in CLDC. CDC also includes
some of the classes from Java 2 Standard Edition (J2SE) (Figure 4), which provides an overview of the
available libraries in J2ME-PP in comparison with J2SE 1.3.1). Profiles provide more facilities for device
specific properties. The FP is the lowest level profile and provides basic support classes, e.g. network


                                                                                                        7
R J van den Berg                                  The management of a BAN using JMX 1.2.1, a case study


and I/O support. The PBP provides a structure for building lightweight applications for network
connected devices that need a basic level of graphical presentation. The PP provides full graphical
user interface (GUI) or Internet applet support. Optional packages offer standard API’s for using
technologies such as Bluetooth and Web services. [10, 11, 12, 13]




Figure 3 Java 2 Platform overview




Figure 4 J2ME-PP API




                                                                                                     8
R J van den Berg                                     The management of a BAN using JMX 1.2.1, a case study



2.3.         BAN management

2.3.1.       BAN Management Agent and Management Resources

The BAN provides services in which the MBU works as a central device relaying and processing data to
and from local devices to and from the outside world, as mentioned above. In some scenario’s,
services are to be guaranteed 24 hours a day, 7 days a week, e.g. a patient monitoring system. On
the BAN’s MBU one or more management agents and management resources may reside.
Management agents are programs that provide one or more service, e.g. the polling (e.g. monitoring)
of a management resource and/or intervene (e.g. shutdown secondary processes) in the normal
operation of the MBU due to complications with this resource. BAN manageable resources are those
objects residing in the BAN that need to be monitored, if necessary controlled, by the manageable
agent. Examples of a BAN managed resource are a device, an application, or a service provided by the
BAN. A device is a resource since it contains information about any part of the hardware of the BAN,
e.g. the battery-lifetime or the performance of the heartbeat-sensor. An application is a resource
because it contains application or process specific data which can be used to locate specific conflicts
within the system and respond to these problems, e.g. an overkill in the allocation of virtual memory
to a process that complicates, for example slowing down, the functioning of the BAN. A service
provided by the BAN is a resource since it can have defined properties, e.g. the aggregation of virtual
memory usage of the combined processes needed to run the service, that provide the manager with
information about its functioning.

2.3.2.       BAN Management Applications

The agents and manageable resources are the basis from which management of the BAN is
performed. For example, the scenario in which a patient is being monitored by a health institution as
shortly illustrated above. A health institution’s BAN-system administrator is responsible for
management of multiple BANs. He, thus, has to be able to monitor them all at the same time. At his
workspace there is a management application currently monitoring every remote BAN. A specific case
could be when a patient ends the program, e.g. the patient no longer needs to be monitored by the
health system. The BAN-system administrator is then able to change the status of the BAN from, for
example, “handed out” to, for example, “in storage”, i.e. relates to inventory management. In another
case, the patient seems to have problems running the BAN. The BAN-system administrator is then
able to verify the usage, i.e. the workload, of the specific BAN and compare it with an average of all
the BANs currently in use. If this provides no valuable information, the BAN-system administrator is
able to reduce the data polling interval from, for example, every 10 min to every 1 min, so he is able
to more closely monitor this specific BAN.


The above example provides a small indication of what is, and is possible with, a BAN management
application. A more detailed discussion on this topic falls outside the scope of this project.


                                                                                                        9
R J van den Berg                                     The management of a BAN using JMX 1.2.1, a case study



2.3.3.       JMX as an implementation technology

The definition of an ideal management environment is, according to Sullins & Wipple [15]:


    “The ideal management environment would have a proactive capability for dealing with problems.
    It would constantly monitor the health of both devices and applications. Commonly when a device
    is down, it would need to discover an alternative device, reroute services and notify the
    administrator. The ideal management system would not only be aware of the health of the
    application, but it would also have the knowledge of the applications internals. The management
    system would make informed decisions and take action based on information gathered from
    applications and devices.” [15]


Second generation management technologies, e.g. Simple Network Management Protocol (SNMPv1),
are static in nature and can therefore only work with resources known in advance. The BAN system
might need to add new services during runtime and cannot afford to be restarted, e.g. due to the
need to have uninterrupted monitoring of an ECG for heart-patients. Java Management eXtensions
(JMX) provide tools, e.g. MBeans and services to manage a system. JMX enables developers to
encapsulate manageable resources as Java objects and it exposes them as manageable resources in a
distributed environment. Manageable resources can be an application, service and device. JMX is
designed to build flexibility and usability into a management environment by providing a mechanism
for agents, and instrumenting resources for management.


The second argument for using JMX as an implementation technology is due to the fact that Java
(more specific J2ME-PP) is used for development of BAN applications and the service platform.

2.3.4.       The JMX architecture

The JMX architecture is structured into three layers, the instrumentation layer, the agent layer and the
distributed layer and is depicted in Figure 5. [13, 14]


Figure 5 depicts the JMX architecture in three layers. Specifically the instrumentation layer is placed
inside the agent layer to illustrate the position of MBeans and the manageable resources. The
instrumentation layer is in fact a separate layer, which can function without the agent layer. The
instrumentation layer contains MBeans and their manageable resources. An MBean is a Java object
that implements a specific interface. There are 4 types of MBeans, Standard MBeans, Dynamic
MBeans, Open MBeans and Model MBeans. MBeans are Java objects that have to conform to certain
design patterns that particularly relate to the way in which the interface exposing the manageable
attributes and operations must be named. For example all the MBean types must have a constructor
and getter/setter methods. Standard MBeans are static, unchanging MBeans used for well-known or
predefined manageable resources and use an explicitly specified management interface to interact



                                                                                                       10
R J van den Berg                                   The management of a BAN using JMX 1.2.1, a case study


with a manageable resource. Dynamic MBeans expose an interface at runtime, i.e. they can also
change at runtime, to manage evolving resources in situations where the standard MBeans are not
appropriate. Dynamic MBeans must implement the javax.management.DynamicMBean interface and
they generate their management interface during runtime. An Open MBean is a Dynamic MBean that
relies on basic data types, e.g. java.lang.Void, java.lang.Boolean, for universal manageability. Open
MBeans also allow for more complex data structures, such as the composite- and tabular-data
interfaces. Model MBeans offer management and configuration capabilities that the Standard and
Dynamic MBeans do not, i.e. a Java object cannot be registered in the MBean server unless it is a JMX
compliant MBean, by instantiating a ModelMBean, resources are guaranteed that the MBean is valid.
For more information about MBeans please refer to the literature, e.g. [10, 11, 12, 15 and 18].


The agent layer controls the manageable resources and makes them available to remote management
applications. The agent consists of an MBean server and a set of services for handling MBeans. An
MBean server contains a registry to which MBeans register so they can be addressed. An MBean is
registered into an MBeanServer via the method registerMBean(mbean, objectName). The parameters
mbean and objectName represent the MBean-object, to be registered, and an ObjectName, to identify
and find the MBean in the MBeanServer, respectively. An ObjectName consists of two parts, a domain
name and property list. The domain name usually coincides with the domain name of the
MBeanServer in which the MBean wants to register or it is used as method to segregate one MBean
from another. The property list consists of a key, e.g. name, and a value, e.g. htmladaptor, to
uniquely identify the MBean and also provide information about the MBean [15]. An example of an
objectName is the string “JMXAgent:name=htmladaptor,port=9092 ”.


The agent services are objects that can perform management operations on the MBeans registered in
the MBean server, e.g. a dynamic class loader, monitors, timers and relation services (to define
associations between MBeans). In order to let JMX agents and MBeans send critical information to
interested parties, such as management applications or other MBeans, the JMX technology defines
notifications. Notifications are Java objects, emitted by an MBean or JMX agent, and encapsulate
events, alerts, or general information. Other MBeans or Java objects can register as listeners to
receive such information.


The distributed layer contains components that enable management applications to communicate with
JMX agents. The components provide an interface for a management application with an agent and its
JMX manageable resources through a connector, e.g. a TCP connector or an HTML adaptor. Via the
HTML adaptor the JMX agent is able to present the contents of the manageable resources in a web-
based environment.




                                                                                                     11
R J van den Berg                The management of a BAN using JMX 1.2.1, a case study




Figure 5 The JMX architecture




                                                                                  12
R J van den Berg                                    The management of a BAN using JMX 1.2.1, a case study




                   3.           Manageable BAN resources


Manageable Body Area Network (BAN) resources are the objects inside the BAN that need to be
managed, e.g. monitored, to assure the BAN’s health. Examples of BAN manageable resources are
abundant, e.g. generated network traffic, process information, memory utilization, CPU utilization, etc.
A part of the research question of this project is: “Is it possible to … monitor BAN process information
…” To make sure we don’t get overwhelmed by the large number of manageable resources a first step
towards the identification of manageable BAN resources is made in the following section, in which the
focus is specifically on monitoring all processes running on a BAN. Each process then has its own
specific process information, e.g. Process IDentification number (PID) or process memory utilization.
This provides a foundation with which the second part of the research question can be answered.


The second section presents a model to monitor the manageable resources, i.e. process information.
The model is inspired by the RFC 2790 Host Resource Management Information Base (MIB). [16] The
RFC 2790 defines a MIB for use with managing host systems. The host is any computer that
communicates with other similar computers connected to the Internet and that is directly used by one
or more human beings, e.g. the BAN’s MBU communicating with a remote server. The host resource
model & instrumentation are used as the foundation for the management agent presented in chapter
4.



3.1.         Extracting contents for manageable BAN resources

As mentioned in the introduction of this report the Mobile Base Unit (MBU), e.g. the HP IPaq, of the
BAN runs a Linux or Windows operating system specifically built for PDA sized devices. The basic idea
about these operating systems is that they have significantly reduced functionality to economically
handle the use of the already sparse resources, compared to operating systems used in, for example,
desktop PC’s or server systems. To obtain process information from an MBU system we make use of
the PS-command [17] from Linux, which also implies the use of a Linux based version of the MBU.
Executing the “PS –do pid, user, vsize, cputime, fname” provides us with useable data to acquire a
simple overview of the processes running on a system. PID provides the unique process identification
number allocated by the system. User provides the user name, e.g. root or Ruben, that runs the
process. Vsize returns the virtual memory size of the processes in kilobytes. CPU-time returns the
cumulative CPU time, [dd-] hh:mm:ss format. Fname returns the first 8 bytes of the base name of the
process’s executable file. An example of the provided data by this command is shown in Figure 6. The




                                                                                                      13
R J van den Berg                                   The management of a BAN using JMX 1.2.1, a case study


information is presented in text based output and is thus easily imported into a Java application, i.e.
as an object to be used in the application.




Figure 6 Result from a ps-command



3.2.         Host Resources for a Management Agent

3.2.1.       BAN Software Process Model

RFC 2790, a Host Resources MIB, specifies a schema for processing host resource data, e.g. software
runs on a system, which makes the software subservient to the system. Host resource data is the
process information needed to monitor the BAN system, e.g. applications or devices. Inspired by the
RFC 2790, the entities BANSystem, RunningSoftware and SoftwarePerformance were selected.


The entity BANSystem has a relation with the entity RunningSoftware, a BAN system has 1 or more
software packages running on it and software is running on 1 system.
The entity RunningSoftware contains attributes “PID”, the information about the unique process
identification number, “user”, the user running the software, and “command”, which contains data
about the name of the software installed on the system.
The entity RunningSoftware has a relation with the entity PerformanceSoftware, running software has
1 software performance entity and a performance entity has 1 entity of running software.
The PerformanceSoftware entity contains the attributes “vsize”, the virtual memory size and
“cpuTime” the time the process is running.


                                                                                                     14
R J van den Berg                                   The management of a BAN using JMX 1.2.1, a case study


A PerformanceSoftware object contains the two dynamic parts of the manageable resource.
An entity relation diagram is depicted in Figure 7, it shows the BANSystem, RunningSoftware and
PerformanceSoftware in their relationships.

                           Figure 7 Entity Relationship Diagram




                                              Figure 8 BAN Resources JMX Instrumentation-level




3.2.2.       BAN Resource Instrumentation

The host resource model from the previous section can now be woven into the JMX architecture from
section 2.3.4. The content from the ps-command provides us with application data, when reflected
upon the three manageable resources, i.e. services, applications and devices. To implement the
structure from Figure 7 into the JMX architecture MBeans are created to expose the contents for
management, e.g. the monitoring of the running software on the BANs MBU. Figure 8 illustrates the
JMX instrumentation level for the BAN system. The entity BANSystem from Figure 7 has gives access
to the entities RunningSoftware, such that one BANSystem has one or multiple instances of
RunningSoftware. Two MBeans are of interest in this case: the BANSystemMBean and the
RunningSoftwareMBean, both implemented by their related classes, BANSystem and RunningSoftware
respectively. The BANSystemMBean gives access to the total number of running processes on the BAN
system via the attribute numProcesses. The RunningSoftwareMBean gives access to the actual
process data retrieved from the BAN system by the ps-command, executed in the BANSystem entity.
In the next chapter the BANSystemMBean and the RunningSoftwareMBeans are exposed for
management in the JMXAgent.




                                                                                                     15
R J van den Berg   The management of a BAN using JMX 1.2.1, a case study




                                                                     16
R J van den Berg                                   The management of a BAN using JMX 1.2.1, a case study




                   4.           Design of the BAN management agent


Management of a computer system can be divided in five different pillars. A distinction is made
between Fault, Configuration, Accounting, Performance and Security management or FCAPS, the
pillars into which the FCAPS-model breaks the various network management tasks. Performance
management enables the manager to prepare the network for the future or monitor it to make sure it
is healthy. By collecting and analysing performance data, the network health can be monitored.
Trends can indicate capacity or reliability issues before they become service affecting. Performance
thresholds can be set in order to trigger an alarm. An alarm would then be handled by the fault
management part, which falls outside the scope of this project [18].


The research in this report is focused on the performance management of the BAN’s MBU. As
introduced above the performance is vital in knowing whether or not the host system is healthy and
performing as expected, e.g. if the BANs MBU is able to monitor a patient 24 hours a day. In this
chapter we elaborate on a performance agent build for the BANs MBU. The agent extracts
performance data from the MBU. First the structure and behavior of the agent are provided. This is
followed by a demonstration of the performance agent prototype for the BANs MBU.



4.1.         Structure of the Performance Agent Design

The structure of the performance management application can be divided in the three layers, the
agent, instrumentation and distributed layer, described in paragraph 2.3.4. Figure 9 shows the
performance agent in a JMX architecture. The agent layer contains the JMXAgent and the
agentMBeanServer, functioning as the core of the architecture. The instrumentation layer is
represented by the two manageable resource boxes and has the same structure as the one in Figure 8
The manageable resources are registered inside the agentMBeanServer so they can be exposed for
management. The manageable resources are the application results, i.e. the ps-command run on the
MBU system, extracting the performance data, e.g. virtual memory used or CPU-time, from the
system. The BANSystem contains the numProcesses attribute to provide the total number of running
processes registered as an MBean. The distributed layer, also registered as an MBean inside the
agentMBeanServer, consists of an htmlAdaptorServer generating a web-interface at port 9092 at
which a remote web-browser can communicate with the management application.




                                                                                                     17
R J van den Berg                          The management of a BAN using JMX 1.2.1, a case study




Figure 9 Performance Agent JMX architecture




                                                                                            18
R J van den Berg                                     The management of a BAN using JMX 1.2.1, a case study


Figure 10 depicts the UML class diagram of the performance agent design. The JMXAgent contains the
main method of the design. As discussed in the sections above, it contains the attributes
agentMBeanServer, htmlAdaptorServer and banSystem. The agentMBeanServer is the MBeanServer
which will contain the MBeans used in this design. The htmlAdaptorServer has the function to enable
the remote interface in the form of a web-service. The banSystem is the instrumentation layer section
of the design which contains the manageable resources. Finally the JMXAgent contains two methods,
one to register MBeans that need to be registered inside the agentMBeanServer during run-time, i.e.
after the initializing. And one to initiate the BANSystem section of the design.


The classes HtmlAdaptorServer and MBeanServer are standard classes that come with the JMX
reference implementation. For illustration the attributes and methods used in this design are depicted.
The managed resources exposed for management are both illustrated by their interfaces,
BANSystemMBean and RunningSoftwareMBean, and classes that implement these interfaces,
BANSystem and RunningSoftware.


The class BANSystem has the attribute numProcesses and the methods updateRunningSoftware and
getNumProcesses. The attribute numProcesses keep a count on the number of currently registered
processes inside the agentMBeanServer. The method updateRunningSoftware updates the current
agentMBeanServer by refreshing the RunningSoftwareMBeans. The method getNumProcesses returns
the current value of the numProcesses attribute, this is the only value of the BANSystem class
currently exposed for management.


The class RunningSoftware has the attributes pid, user, command and performanceSoftware and the
methods getPID, getUser, getCommand, getVsize and getCpuTime. The attributes all represent the
manageable     resources    elicited   from   the   ps-command      explained      earlier.   The   attribute
performanceSoftware contains the last two, i.e. vsize and cpuTime. They are placed in a separate
class, i.e. PerformanceSoftware, since they are dynamic with respect to pid, user, and command.


A detailed discussion of the workings of the classes shown Figure 10 is presented in the next section
which discusses the behavior of the performance management application.




                                                                                                          19
R J van den Berg                                 The management of a BAN using JMX 1.2.1, a case study




Figure 10 Performance Agent design Class diagram



4.2.          Behavior of the Performance Agent design

The behavior of the performance agent design is illustrated via UML sequence diagrams. To provide a
good understanding of the processes the complete sequence is split up into 3 phases. The first phase
creates an instance of the JMXAgent and HtmlServerAdaptor, this includes the registration of the
htmlServerAdaptor in the agentMBeanServer. The second phase creates an instance of the
BANSystem and multiple instances of RunningSoftware, according to the number of processes running
on the BAN system. The third and final phase illustrates the manual updating process via a remote
connection.




                                                                                                   20
R J van den Berg                                         The management of a BAN using JMX 1.2.1, a case study



4.2.1.        Phase 1: jmxAgent set-up

The class JMXAgent contains the main method of the performance agent design. Calling the main
method will create a JMXAgent instance. In the constructor of the JMXAgent an agentMBeanServer,
via createMBeanServer(mbeanServerName), and an htmlAdaptorServer, via new HtmlAdaptorServer(),
are   initiated.   The    htmlAdaptorServer       is   then   registered    in    the    agentMbeanServer,      via
registerMBean(mbean,        objectName).         The   parameter    mbeanServerName            in   the    method
createMBeanServer is a string representation of the server-name we want to give to the MBeanServer.


The classes JMXAgent, MBeanServer and HtmlAdaptorServer allow for JMXAgent to register MBeans
into the MBean-server so they can be viewed from a (remote) web-browser. In figure Figure 11 the
objects jmxAgent1, agentMBeanServer and adaptor represent instances of the three classes
JMXAgent, MBeanServer and HtmlAdaptorServer respectively. First the adaptor is set a specific port,
e.g. 9092, and then the adaptor is registered as an MBean in the agentMBeanServer. Finally the
adaptor is started, starting the webserver, which allows for the jmxAgent to be managed from a
remote location.




Figure 11 Sequence diagram HTML adaptor initialization

4.2.2.        Phase 2: banSystem set-up

The initialization of the banSystem is illustrated in Figuur 12. The instance jmxAgent calls the
initBANSystem method which creates a new banSystem object. After the creation of the banSystem
object the new object is registered in the agentMBeanServer. Then the jmxAgent calls the
updateRunningSoftware method on banSystem. UpdateRunningSoftware runs the ps-command
,discussed in section 3.1, and creates RunningSoftware instances from the contents provided by the
ps-command.        For   every   instance   of    RunningSoftware     and        MBean   is   registered   in   the
agentMBeanServer and functions as a repository for the manageable data.




                                                                                                                21
R J van den Berg                                     The management of a BAN using JMX 1.2.1, a case study




Figuur 12 Sequence diagram banSystem initialization

4.2.3.       Phase 3: Remote updateRunningSoftware

The last sequence diagram illustrates the update process done via a web-browser (Figuur 13). A
request to update to the current state is received via the web-interface. The adaptor forwards the
request via the agentMBeanServer to the banSystem where the updateRunningSoftware method is
executed. The method updateRunningSoftware updates the system, executing the ps-command and
creating runningSoftware instances, and registers the new MBeans to the agentMBeanServer. The
current   design   removes,   deregisters,   all   the   previous   runningSoftwareMBeans      from   the
agentMBeanServer and registers the new MBeans as the update. Future applications could more
logically update the MBeans, by for example only changing the contents of the MBeans, e.g. the
virtual memory size and the CPU-time.




Figuur 13 Sequence diagram remote updaterRunningSoftware




                                                                                                       22
R J van den Berg                                    The management of a BAN using JMX 1.2.1, a case study



4.3.         The Performance Agent prototype

In this section a small proof of concept is provided to the reader in order to demonstrate the
performance agent design prototype as a working application corresponding to the above described
design. The application is run on a host, a Linux desktop computer, simulating the BAN MBU
environment. The environment is created by running the J2ME-PP platform and the JMX reference
implementation as it would do when installed on a BANs MBU. An elaboration on how the system is
configured can be found in Appendix A. The screenshots illustrate the views acquired from the host,
the desktop computer, and the remote interface, the web-browser.

4.3.1.       Phase 1: Agent and adaptor initialization

The first part of the proof of concept shows the initialization of the JMXAgent and the HtmlAdaptor-
Server as illustrated in Figure 11. The view from the host is shown in Figure 14. At different stages
the application prints successful completions of the agent start-up initialization info. After completion
the performance management application is waiting for a remote connection on the URL:
http://utip071.cs.utwente.nl:9092. The remote connection is set-up via a web-browser, e.g. Internet
Explorer or FireFox. It shows the initial representation of the JMXAgent, including the initial MBeans,
generated by the HtmlAdaptorServer from the JMXAgent’s contents (see Figuur 15).

4.3.2.       Phase 2: BANSystem initialization

Now that the JMXAgent and the web-interface are running phase 2 the BANSystemMBean,
implemented by the BANSystem class, can be initiated and registered into the JMXAgent, as illustrated
in Figuur 12. The view from the host is shown in Figure 17. The host shows the stepwise registration
of the different MBeans, acquired from the execution of the ps-command, into the agentMBeanServer.
After all the MBeans have been registered, the remote web-browser is able to present the result to
the user of the remote connection (Figure 18). Clinking on the hyperlink of the banSystem shows the
attribute exposed to management of the banSystemMBean (Figure 19). The exposed MBean shows
the attribute numProcesses. The numProcesses attribute exposes the total number of registered
RunningSoftwareMBeans in the agentMBeanServer.

4.3.3.       Phase 3: Process contents and remote updateRunningSoftware

The third and final part of the proof of concept shows the acquiring of the process information from
the RunningSoftwareMBean and a remote update of the RunningSoftwareMBean as presented in the
performance agent design sequence diagram in Figuur 13. Figure 18shows the current view for the
remote user. The user now accesses the BANSystemMBean as shown in Figure 19
The acquiring of process information from the RunningSoftwareMBean is done via the Agent view,
Figure 18. When following a link of the RunningSoftware Process ID’s, the contents of the attribute
are shown (Figure 19).



                                                                                                      23
R J van den Berg                                  The management of a BAN using JMX 1.2.1, a case study


The BANSystemMBean shows one operation, “updateRunningSoftware”. Pressing the button will
execute the operation inside the JMXAgent on the host, e.g. the BANs MBU. The method updates the
MBean contents as explained in section 4.2. The result is shown in Figure 20. Firstly JMX shows that
the operation was successfully invoked for the BANSystemMBean. Secondly the attribute representing
the number of processes running on the host system is still 20, since the total number didn’t change.
Returning to the Agent view will show the new pid-numbers which, as mentioned before, indicate the
unique process numbers.




Figure 14 JMXAgent initialization




Figuur 15 JMXAgent initialization web-interface


                                                                                                    24
R J van den Berg                          The management of a BAN using JMX 1.2.1, a case study




Figure 16 BANSystem initialization: updateRunningSoftware




                                                                                            25
R J van den Berg                          The management of a BAN using JMX 1.2.1, a case study




Figure 17 JMXAgent initialization of the BANSystemMBean


                                                                                            26
R J van den Berg                          The management of a BAN using JMX 1.2.1, a case study




Figure 18 JMXAgent initialization of BANSystemMBean web-interface




                                                                                            27
R J van den Berg                          The management of a BAN using JMX 1.2.1, a case study




Figure 19 JMXAgent RunningSoftwareMBean




                                                                                            28
R J van den Berg                        The management of a BAN using JMX 1.2.1, a case study




Figure 20 JMXAgent BANSystem updateRunningSoftware operation




                                                                                          29
R J van den Berg   The management of a BAN using JMX 1.2.1, a case study




                                                                     30
R J van den Berg                                    The management of a BAN using JMX 1.2.1, a case study




                   5.           Conclusion & Recommendations


In order to ensure the health of a BANs MBU this project started out to demonstrate the feasibility of
remotely monitoring BAN process information with the SUN JMX 1.2.1 Reference Implementation. The
use of SUN JMX 1.2.1 Reference Implementation is preferred for two reasons, first due to its dynamic
property and easily enable remote management; second because SUNs JMX 1.2.1 Reference
Implementation can be combined with the already used platform for the BANs MBU, J2ME-PP. The
health of the BANs MBU is vital, e.g. when a patient is allowed to freely continue his life and still
needs to remain under medical supervision. The underlying goal of the project, being able to manage
a BANs MBU from a remote location, has successfully been presented in chapter 4. A proof of concept
was given showing a performance management application that monitors management contents, i.e.
process information, which can be remotely presented via a web-interface.


The success of this project opens a new area in which further research needs to be done. Now that
standard-MBeans are running on the J2ME-PP platform more JMX functionalities, e.g. notifications,
services, other network connections, and dynamic, model & open MBeans. The services presented in
paragraph 2.3.4, i.e. timers, monitors, dynamic class loader and the relationship-service, could be of
interest to extent the management application. Currently a web-interface is used to remote interface
the BAN management agent. Other network connections, e.g. a TCP-connector or RMI-connector,
could broaden the possibilities of the management application. Some successful preliminary tests have
been done with notifications and also with a TCP connection; however more research needs to be
done.


The specific question answered in this case study is concerning the feasibility of monitoring BAN
process information with the SUN JMX 1.2.1 Reference Implementation. The next question to answer
could be whether or not this reference implementation is the best option to monitor the process
information? Are the currently chosen tools, i.e. Standard MBeans and a web-interface, the best (or
sufficient) options? What kinds of security issues, e.g. secure data-transfer or access-control, need to
be considered? Figure 4 shows that the java.security package is also supported in J2ME-PP. Going a
step further, the question at which levels, e.g. cpu-utilization or memory usage, should a management
system start to interrupt the system or alarm a user? All to serve a broader goal in the context of this
project: “to ensure the health of the BAN and ultimately its patient”.




                                                                                                      31
R J van den Berg   The management of a BAN using JMX 1.2.1, a case study




                                                                     32
R J van den Berg                                  The management of a BAN using JMX 1.2.1, a case study




Reference
[1]     CBS, http://statline.cbs.nl/StatWeb/table.asp?PA=70655ned&D1=11,12,14,15,17-52,72-
        147&D2=0&D3=(l-11)-l&DM=SLNL&LA=nl&TT=2
[2]     The economist, IT in the health-care industry, Apr 28th 2005, SAN FRANCISCO
[3]     Freeband Awareness project “context AWARE mobile NEtworks and ServiceS”
        http://awareness.freeband.nl
[4]     Architecture and Service Network Applications, http://asna.ewi.utwente.nl/
[5]     Aart van Halteren, et al. Mobihealth: Ambulant Patient Monitoring Over Next Generation Public
        Wireless Networks, University of Twente, Netherlands
[6]      Wireless World Research Forum, 2001, The Book of Vision 2001: Visions of the Wireless
        World, version 1.0, December 2001; http://www.wireless-world-research.org/
[7]      Dokovsky, van Halteren, Widya, BANip: enabling remote healthcare monitoring with Body
        Area Networks, 2004, University of Twente, Netherlands
[8]     Bults, Wac, van Halteren, Konstantas, Jones, Widya, Body Area Network for Ambulant Patient
        Moniroting Over Next Generation Public Wireless Networks, 2004, University of Twente,
        Netherlands
[9]     MobiHealth project “Innovative GPRS/UMTS mobile services for applications in healthcare”
        http://www.mobihealth.org, Funded by the EU, Brussels, 2002-2003
[10]    Sun Microsystems, java.sun.com, Sun, Palo Alto
[11]    Sun Microsystems, Datasheet Java 2 Platform, Micro Edition, Sun, Palo Alto, 2002
[12]    Sun Microsystems, Datasheet Java 2 Platform, Micro Edition Connected Device Configuration,
        Sun Palo Alto, 2004
[13]    Sun Microsystems, Java Management Extensions White Paper, Sun, Palo Alto, 1999
[14]    Sun Microsystems, http://java.sun.com/developer/technicalArticles/J2SE/jmx.html, Sun Palo
        Alto, 2004
[15]    G. Sullins & Mark B. Wipple, JMX in Action, Manning, Greenwich, 2003
[16]    S. Waldbusser & P. Grillo, RFC 2790 Host Resources MIB, Network Working Group, March
        2000
[17]    Branko Lankester, Linux User’s Manual, http://unixhelp.ed.ac.uk/CGI/man-cgi?ps, July 28
        2004,
[18]    Flextronics Software Systems, http://www.futsoft.com/pdf/fcapswp.pdf
[19]    Java Management Extensions 1.2.1 API specifications




                                                                                                    33
R J van den Berg   The management of a BAN using JMX 1.2.1, a case study




                                                                     34
R J van den Berg                                    The management of a BAN using JMX 1.2.1, a case study




List of Abbreviations

API                -   APplication Interface
BAN                -   Body Area Network
CPU                -   Central Processing Unit
FCAPS              -   Fault, Configuration, Accounting, Performance, Security
GPS                -   Global Positioning System
GUI                -   Graphical User Interface
HTML               -   Hyper Text Markup Language
ICT                -   Informations and Communications Technology
J2ME               -   Java 2 Micro Edition
J2ME-CDC           -   J2ME – Compact Device Configuration
J2ME-CLDC          -   J2ME – Compact Limited Device Configuration
J2ME-FP            -   J2ME – Foundation Profile
J2ME-PBP           -   J2ME – Personal Basis Profile
J2ME-PP            -   J2ME – Personal Profile
J2SE               -   Java 2 Standard Edition
JDMK               -   Java Dynamic Management Kit
JMX                -   Java Management eXtentions
JMX RI             -   JMX Reference Implementation
LAN                -   Local Area Network
MBean              -   Management Bean
MBU                -   Mobile Base Unit
MIB                -   Management Information Base
PDA                -   Personal Digital Assistant
TCP                -   Transmission Control Protocol
UML                -   Unified Modeling Language
UMTS               -   Universal Mobile Telecommunications System
WiFi               -   Wireless Fidelity




                                                                                                      35
R J van den Berg   The management of a BAN using JMX 1.2.1, a case study




                                                                     36
R J van den Berg                                                The management of a BAN using JMX 1.2.1, a case study




Appendix A
This part elaborates how the system was configured and which command line entry was made to run
the compiler and the virtual machine used during this project.


Edit of the .bash_profile file


The following lines were added to the .bash_profile file, located in the users home directory (e.g.
/home/ruben/) to make sure the correct CVM and j2sdk files are used.


# set PATH so it includes CVM            # set PATH so it includes
if [ -d /usr/local/j2me-pp1.0 ] ; then   j2sdk1.4.2_07
 CVMHOME=/usr/local/j2me-pp1.0           if [ -d /usr/local/j2sdk1.4.2_07 ] ;
 PATH=${CVMHOME}/bin:"${PATH}"           then
fi                                       JAVAHOME=/usr/local/j2sdk1.4.2_07
                                         PATH=${JAVAHOME}/bin:"${PATH}"



Javac, the compiler


The following line was entered in the directory that contains the example package in order to
compile all java files inside this package.


javac -bootclasspath /home/ruben/j2me/j2me-pp1.0/btclasses.zip
-classpath /home/ruben/j2me/j2me-pp1.0/lib/personal.jar:/home/ruben/jmx/jmx-1_2_1-
bin/lib/jmxtools.jar:/home/ruben/jmx/jmx-1_2_1-bin/lib/jmxri.jar:/home/ruben/jmx/jmxremote-1_0_1-
bin/lib/jmxremote.jar example/*.java



CVM, the virtual machine


The following line was entered in the directory that contains the example package in order to start
the exampleAgent class running the core of the JMX prototype.


cvm -Xbootclasspath:/home/ruben/jmx/jmx-1_2_1-bin/lib/jmxri.jar:/home/ruben/jmx/jmx-1_2_1-
bin/lib/jmxtools.jar:/home/ruben/jmx/jmxremote-1_0_1-bin/lib/jmxremote.jar example.exampleAgent




                                                                                                                  37

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:9
posted:10/25/2011
language:English
pages:47