4.3.1 Agent
We choose to implement the agent with JMX.
First of all, we implement a MBean server. MBean server will login to the Jabber server when the MBean server is created. Then MBean server creates a RMI connector server to listen to RMI connection. We can connect to the MBean server in two ways: The connection can be set by RMI connector or directly or locally connect to the MBean server. The first method is suitable for our use. But in some occasional case (for example, the network connection fails). Administrators can connect to MBean server at the local machine to configure the MBean server.
We have to implement MBean for each access point. MBean server queries the database for the information of access points, create the corresponding MBean for each access point, ant then register them to the MBean server.
The attributes of the MBean include IP address, position, etc. Operations of the MBean provide the function to detect the access point, for example, make a SNMP request to a access point that supports SNMP. If the destination access point does not response. MBean will send notification to MBean server. MBean server will handle the notification. In this case, MBean server will send a warning message to the administrators on the roster.
4.3.2 Web Structure
We choose Apache Tomcat[25] as our web server in the system. Apache Tomcat is a servlet container based on servlet and JavaServer Pages (JSP) specification. It provides an environment for Java code to run in cooperation with a web server. We implement JSP to produce dynamic web page as the front end interface that can interact with administrators.
To write a more maintainable code, we choose the model 2 Model-View-Controller (MVC) design pattern to implement the management console.
MVC model is often applied in the GUI application or enterprise web appli-cations. It separates the program into three components:
Figure 4.2: The program structure of wireless monitoring system
• Model: represents the business logic layer of the application. It pro-vides data processing, database connection and produce data, etc.
• View: represents the presentation layer of the application. It provides user interface which the user can input data, and represents the result after processing the input data.
• Controller: process users action, determine the data from the view and deliver to the designated business logic, then forward to the view displaying the result.
We choose the appropriate implementations according to the functional-ity. JavaBean is an appropriate technology to design the model; JSP page is used to design the presentation of HTML page; the controller is implemented by servlet. The whole architecture is shown in Figure 4.3.
There are several advantages in the MVC design pattern:
1. There is no real processing happening in the view; it serves only as a way to output data. Web page designers do not need to consider the program logic; they only have to think about the presentation of the web page.
Figure 4.3: MVC design pattern
2. The model component represents only the data. The data returned by the model is display-neutral, meaning that the model applies no formatting. So a single model can provide data for any number of display interfaces. This reduces code duplication because model code is written only once and is then reused by all of views.
3. The controller controls the whole processing flow which reduces many conditional codes in the view components.
By leading the MVC pattern into our system, we use JavaBean to com-plete the interactions with the MBean server. JavaBean connects the RMI connector server which MBean server created through a connector. After connection complete, JavaBean can remotely control the MBean server. It can invoke MBean to execute operations hold the result. The controller for-wards to the JSP page then JSP request and formats the result and then response to the administrator. Figure 4.4 describes the components.
4.3.3 Jabber
There are many Jabber services provided by organizations around the world.
We can choose a Jabber client, configuring an IP address of one Jabber server and user the Jabber service for free after registration. But for privacy issue, we do not want to expose the message sent between administrators
Figure 4.4: The structure of the web based management console in the wire-less monitoring system
and agents to other network. In the other way, to preserve the integrity of the system, we provide the service.
There are many Jabber servers and clients listed in Jabber Software Foun-dation. Anyone of them is suitable for us. We choose Wildfire[26] as our Jabber server. Wildfire is a Jabber server implemented by Java language, so it is platform independent.
4.4 Summary
When the architecture is deployed in NCTU campus, we may have the sce-nario like Figure 4.5. In Figure 4.5, only part of hotspot in NCTU dis-played. Each hotspot is managed by one or more administrators. Assume the supreme administrators is in the Computer and Network Center, we set the web server and the Jabber server in the Computer and Network Center.
According this architecture, the supreme administrator can make manage-ment request to each hotspot to get the information of access points in each hotspot (As the line in Figure 4.5). When the error is detected, the agent in that hotspot would send message back to the administrators (As the dotted line in Figure 4.5). In this way, we can have overall understanding about the wireless problems in NCTU campus and get the warning in real time.
Figure 4.5: The scenario when deploying the wireless monitoring system into NCTU
Chapter 5
Implementation
This chapter we introduce the implementation according to our design in last chapter. We will introduce our implementation in each component and describe the functions in detail.
5.1 Agent
The implementation of the agent consists of two parts:
• MBean
• MBean server
5.1.1 MBean
A MBean object represents a access point in the architecture, so the at-tributes and operations in the MBean are related to access points. We im-plement standard MBean as our MBean. To define a standard MBean, we have to write a Java interface named AccessPointMBean:
public interface AccessPointMBean { public String getIp();
public boolean getSupportSnmp();
public int getPort();
public String getCommunity();
public int getStatus();
public String getFloor();
public int getPosX();
public int getPosY();
public String getLocation();
public void setPos(int x, int y);
public void setSupportSnmp(boolean support);
Each method in the interface defines a attribute or a operation. These attributes and operations follow a design pattern. According to JMX specifi-cation, a method whose name started with“get” and return value is not void is called “getter”. For example, getIp() is a getter which gets the attribute named“Ip”. A getter should return a value with the same type as the corre-sponding attribute; A method whose name started with “set” and whose one parameter is called “setter”. For example, setIp(String s) is a setter which sets the attribute name “Ip” to a string s. An MBean interface consists of named and typed attributes that are readable and possibly writable, and named and typed operations that can be invoked by the applications that are managed by the MBean. In our example, snmpFailureTest() in Access-PointMBean is an operation; An attribute with only getter but no setter means that the attribute is readable and not writable. We write Access-Point class which implements AccessAccess-PointMBean. Each AccessAccess-Point object is an MBean in the architecture and it represents an access point, because it communicates directly to the access point. One of the communications is to request an OID value through SNMP. We defined the methods list blow to get a OID:
public void setSnmpQuery(String oid);
public String getSnmp();
setSnmpQuery() set the OID attribute we want to query, and getSnmp() makes get request to the access point.
We include a library named JoeSNMP[15] to be the SNMP engine. JoeS-NMP is an open source Java SJoeS-NMP class library. We wrote a SJoeS-NMP client that makes SNMP get request. As shown in Figure 5.1:
Figure 5.1: Basic components of joesnmp API
First, we create a SnmpPeer by an IP address for the remote SNMP agent. One SnmpPeer represents one agent. Then we define the parameters to SnmpPeer which include SNMP port, Timeout delay, retries, SNMP ver-sion and community. A SnmpSesver-sion has to be created for the SnmpPeer.
SnmpSession creates a SnmpPortal thread that will receive all response from the remote agent. It also creates a SnmpVarBind array to hold all SNMP requests.
We implemented a get-request by the following steps.
1. SnmpSession.send() will send a request. It’s a non-blocking request which will create a new thread to send request and handle retries and timeout.
2. Call Session.wait()
3. When SnmpSnmp receive the response from remote SNMP agent, Sn-mpHandler.snmpReceivedPdu() will handle the response. OID value in the response is abstracted and call Session.notify() to restart the thread waited in step 2.
4. If timeout or other mistakes happen, SnmpPeer will still callback to SnmpSession and call snmpTimeoutError() or snmpInternalError() in SnmpHandler.
getSnmp() in the AccessPoint class use above steps to get SNMP response.
SnmpChecker class make a SNMP get-request to the designated device and check to see if the SNMP can work correctly according to the response from the SNMP agent. AccessPoint class will call SnmpChecker to check the status of the device in snmpFailureTest(). If the access point does not response, AccessPoint will send a notification to its MBean server. The
MBean server will handle the event. For the access points that do not support SNMP, if we want to get its status, we can only send ICMP echo request to them and get their ICMP echo response. Because the “ping” command is provided in almost every system, we invoke our request by executing the ping command in the system and judge the status of the access point from the output of ping command. If the output is like “request timeout”. AccessPoint will send a notification to the MBean server. The MBean server will handle the event.
5.1.2 MBean Server
The implementation of the MBean server includes:
1. Login to the Jabber server
2. Create and Register AccessPoint MBeans 3. Create the connector server
4. Failure testing
After the MBean server we named AgentMBeanServer is initialized, it will login to the Jabber server. We implement a Jabber client called the Jab-berClient. JabberClient imports the XMPP API provided by Jivesoftware.
The relateds actions are illustrated as Figure 3.9 and Figure 5.2:
XMPPConnection conn = new XMPPConnection(server);
conn.login(user, password);
roster = conn.getRoster();
The account is we pre-registered on the Jabber server. We also add administrators’ Jabber account to the contact list of this account.
The JabberClient implements MBean and is registered to the MBean server. The created MBean is registed to the MBean server with an object name. The object name is an identifier of an MBean. Each object name uniquely identifies an MBean within an MBean server. Management appli-cations use this object name to identify the MBean on which to perform management applications. An object name consists of two parts:
• Domain: provides a structure for the naming space within a JMX agent.
• Key properties: enable us to give a unique name to the MBean of a given domain.
Figure 5.2: Actions of the JabberClient after booting the agent
String representation of an object name has the following syntax:
[DomainName]:property=value[,property=value]*
In our implementation, we define the object name of the JabberClient as:
Default Domain:type=JabberClient
Besides sending messages to administrators, JabberClient also needs the ca-pability to receive notifications. After AccessPoint sends a notification, Jab-berClient receive the notification and activates handleNotification() which sends the message to all administrators on the roster:
for (Iterator i = roster.getEntries(); i.hasNext();) { RosterEntry anEntry = (RosterEntry) i.next();
Chat chat = conn.createChat(anEntry.getUser());
Message message = chat.createMessage();
message.setBody(msg);
chat.sendMessage(message);
}
Figure 5.3: Initialization of AccessPoint MBeans
We create an MBean object for each access point. As shown in Figure 5.3. The information about access points is fetched from the database.
In our implementation, we define the object name of each MBean as:
Default Domain:type=AccessPoint,index=[0-9]*
Where the key property “index” makes the MBean can store in an array and the MBean server can access each AccessPoint MBean with a loop.
After all MBeans are created and registered, in order to make a connection through the connector by the administrator, the MBean server creates a connector server:
JMXServiceURL url = new JMXServiceURL(
"service:jmx:rmi:///jndi/rmi://localhost:9999/server");
JMXConnectorServer cs =
JMXConnectorServerFactory.newJMXConnectorServer(
url, null, mbs);
cs.start();
When start() is called, the connector server start to listen to the request from the client on the port 9999.
At last, the MBean server start polling each MBean and invoke the MBean the snmpFailureTest() and pingFailureTest(). In the beginning of each loop, The MBeanServer will query all AccessPoint MBeans by their object names(As step 3 in Figure 5.3).
The object name can be used as pattern matching with the following syntax:
1. * matches any character sequence, including an empty one 2. ? matches any single character.
For example, the following object names:
MyDomain:description=Printer,type=laser MyDomain:description=Disk,capacity=2 DefaultDomain:description=Disk,capacity=1 DefaultDomain:description=Printer,type=ink
• “*:*” will match all objects
• “MyDomain:*” will match all objects in the domain MyDomain.
• “??Domain:*” will match all objects in the domain
• “*Domain:description=Printer,type=laser,*” will match:
MyDomain:description=Printer,type=laser and DefaultDomain:description=Printer,type=ink The MBean server uses the object name:
DefaultDomain:type=AccessPoint,*
to get all the AccessPoints MBean registered on the MBean server.
Querying the AccessPoint MBean in the beginning of each polling loop is efficient when a new access point is added by the administrator. The MBean server will not have to be restarted.
5.2 Web
The management interface in the manager side includes several parts:
1. Choose to enter an agent
2. List all access points in the agent
Figure 5.4: Agent class diagram 3. List the detail information of an access point 4. add a new access point
5. delete an access point
The first page of management console is a list that the administrator can choose to enter an agent. In this page, the web page needs to know where the agents are, what their name is and how to contact them. The information must be provided by a database. The database needs to store at least the IP address of the agent, and the information of an agent’s database. Those data may be used after entering into the following web pages, so we store the data into a list of JavaBean named Agent. Then the JSP page accesses each Agent and lists them in the web page. Figure 5.4 is a class diagram of the Agent JavaBean.
When the administrator decides to enter the chosen agent, the button makes a request to the servlet named ListApServlet. ListApServlet will first make a connection to this agent:
public MBeanServerConnection connectMBeanServer(String url){
MBeanServerConnection mbsc = null;
JMXServiceURL jmxUrl = new JMXServiceURL(url);
JMXConnector jmxc =
This connection is stored in the Agent JavaBean that other servlet or JSP page can operate the Agent by this connection. ListApServlet create an AccessPoint JavaBean for each access point. The information in the AccessPoint JavaBean is got from the AccessPoint MBean:
String ip = mbsc.getAttribute(
(ObjectName)mBeanNames[i], "Ip").toString();
AccessPoint ap = new AccessPoint();
Ap.setIp(ip);
AccessPoint JavaBean is existed in an array and stored in a session. Be-sides AccessPoint JavaBean, there are many other information related to this agent. They are all stored in the session, and in this way the web server can understand which agent the administrator enters and have appropriate operations in the following pages.
ListApServlet then forwards to a JSP page (list-ap.jsp). The JSP page requests the AccessPoint JavaBean and formats the return values to a web page.
The detail information about an access point provided so far included the position of this access point which represented in a plan graph. The basic SNMP information is also provided for an access point which supports SNMP.
We adopt an applet to present the plan graph. According to the param-eter tag, the applet can show the appropriate plan this agent resides. The location of this agent resides is also labeled in the plan, and different status of this agent will labeled with different colors. As in Figure 5.5, the access point is labeled in white when the status of the access point is normal and red when abnormal.
The parameters in the applet tag are provided bye PositionServlet. Po-sitionServlet fetches the designated AccessPoint JavaBean according to the
Figure 5.5: Labels of access points on the plan. White lebel indicates teh normal access point red label indicates the abnormal access point.
administrator requests, and forward to the JSP page. The JSP page accesses this AccessPoint JavaBean and output the HTML code as:
<applet code="mapapplet.MapApplet.class"
width=700 height=600 codebase="/mvc_client/">
<param name="image" value="../image/EC.png">
<param name=x0 value=416 >
<param name=y0 value=195 >
<param name=s0 value=0 >
</applet>
As for SNMP information, due to the private MIBs provided by each access point manufacture, it is difficult to support those private MIBs. In addition, the information SNMP can provide is very rich, if too many unnec-essary information presented in a page, the administrator may feel confused.
So we provided only the basic public MIB data and an interface that the administrator can input and query the OID in this access point.
DetailServlet receives the SNMP request and fetch the designated Ac-cessPoint JavaBean according to the administrator requests. Then control the MBean server to invoke a snmp-get method. After receiving the results, DetailServlet forwards to the JSP page to format the output.
String domain = mbsc.getDefaultDomain();
ObjectName name =
new ObjectName(domain+":type=AccessPoint,IP="+ip);
Object[] params = {oid};
String[] signature = {"java.lang.String"};
String result =
(String)mbsc.invoke(name, "getSnmp", params, signature);
AddApServlet is in charge of adding an access point. AddApServlet di-vided the functionality into three stages:
1. Input the IP address, is support SNMP, the location in which floor, etc.
2. Confirm the input
3. Add the data into the database, and register the access point to the MBean server.
AddApServlet have to deal with each stage and forward to different JSP pages according to different stages. As shown in Figure 5.6:
The initial stage is “INPUTDATA”. AddApServlet forwards to add-1.jsp.
After the administrator fill in the form and press the submit button, the stage is come in to “CONFIRM” stage. AddApServlet forwards to add-2.jsp and list the data that the administrator has filled. After the administrator press the submit button, the stage comes to “COMPLETE” stage.
In “COMPLETE” stage, AddApServlet request the MBean server to cre-ate a new AccessPoint MBean and register it to the MBean server. Then AddApServlet makes a SQL query to add a row about the access point to the database. At last, AddApServlet forwards to add-complets.jsp to show the “add success” page if all the adding action are complete, or forwards to
In “COMPLETE” stage, AddApServlet request the MBean server to cre-ate a new AccessPoint MBean and register it to the MBean server. Then AddApServlet makes a SQL query to add a row about the access point to the database. At last, AddApServlet forwards to add-complets.jsp to show the “add success” page if all the adding action are complete, or forwards to