Building the Sample Java Manager


If it is required to build the Java program, then the files in Figure 7-12 should be downloaded from the Prentice Hall Web site [PrenHallCodeWeb]:

Figure 7-12. The JDMK SNMP manager project files.

graphics/07fig12.jpg

The purpose of these files is now briefly described:

  1. mib_II.txt contains the definition of the MIB II standard objects.

  2. SynchronousManager.java contains the Java class that sends either an SNMP GET or getNext message.

  3. Get.bat executes a single SNMP GET operation against the agent.

  4. GetNext.bat executes a single SNMP getNext operation against the agent.

Once the Java class files are created in the next section, it is possible to run the batch files.

To Build the Java Program

Two commands are required to build the Java program:

  1. mibgen -mo -d . mib_II.txt

  2. javac -d . *.java

The first command builds a file called RFC1213_MIBOidTable.java . The second command creates the bytecode file SynchronousManager.class . The latter is the binary (executable) file for the examples that follow.

An SNMP GET

To run the program, double-click on Get.bat to invoke Java and execute a GetRequest operation. This should result in a display similar to that shown in Figure 7-13.

Figure 7-13 GET operation on the system.sysContact.0 .
 java SynchronousManager GET myHostPC public sysContact.0 NULL 161 < Sent GET request to agent on myHostPC port 161 > < Result: [Object ID : 1.3.6.1.2.1.1.4.0  (Syntax : String) > < Value : StephenMorris] > 

Figure 7-13 illustrates a GET operation on the sysContact object from the standard system table. The object instance is hardcoded (i.e., there is no way for the value to be changed other than by a program source code change) internally to the program. The value of system.sysContact.0 is illustrated as StephenMorris . Recall that this object instance was set to its current value in Figure 7-7.

An SNMP GETNEXT

To run the program, double-click on GetNext.bat to invoke Java and execute a GetRequest operation. This should result in a display similar to that shown in Figure 7-14.

Figure 7-14 GETNEXT operation on system.sysContact.0 .
 java SynchronousManager GETNEXT myHostPC public sysContact.0 NULL 161 < Sent GETNEXT request to agent on myHostPC port 161 > < Result: [Object ID : 1.3.6.1.2.1.1.5.0  (Syntax : String) > < Value : myHostPC] > 

Figure 7-14 illustrates a GETNEXT operation on the sysContact object from the standard system table. As was the case with the C++ program, the GETNEXT response provides the lexical successor to the system.sysContact.0 object. This is the system.sysName.0 object and has the value myHostPC .

The Structure of the Synchronous Manager

The Java program is very simple indeed. All of the code is contained in one file that in turn contains a Java class called SynchronousManager . The command-line parameters are validated , and the required operation type is recorded as either GET or GETNEXT . The next nine lines prepare the API for making SNMP calls. The actual SNMP request is made in the method called:

 public static void issueRequest(SnmpPeer agent, String operation,              SnmpVarBindList list, SnmpSession session,              String host, String port) 

It is this method that issues the message and processes the agent response. Any exceptions that occur are caught in an overall try/catch block.

The Synchronous Java Manager

The JDMK API provides both synchronous and asynchronous operation. Synchronous operation simply waits for responses from the network, whereas asynchronous operation uses callbacks to allow the program to proceed with other tasks . A production-standard NMS tends to use asynchronous operation, or it may use synchronous calls in conjunction with multiple threads. In either case, the NMS should not simply block until a response is received. As we've seen, there is generally much ongoing work to be done by a given NMS as it strives to keep up to date with the managed network. So, execution time should never be squandered waiting for (possibly) tardy devices to respond.

Our examples are all synchronous in nature in order to illustrate the software components in as simple a fashion as possible.

Comparing the Visual C++ and JDMK 4.2 APIs

Table 7-1 shows a brief comparison between the Visual C++ and JDMK APIs.

Table 7-1. API Feature Comparisons

SNMP API

M ULTI- P LATFORM

SNMPv1

SNMPv2

SNMPv3

JDMK 4.2

Yes Java

Yes

Yes

No [*]

Visual C++

No

Yes

No

No

[*] SNMPv3 support is provided as part of JDMK 5.0.

An interesting exercise in interoperability is to mix and match the operation of the two programs, for example,

  1. Set the C++ program to listen for traps.

  2. Execute a security violation (using the wrong community name ) with the Java program.

  3. Watch the traps coming back from the SNMP agent.

To compare the performance of the two APIs, a new batch file can be written to make multiple calls (e.g., 10 GET s) to one of the example batch files. The system time can be printed at the beginning and end of the new batch file, and from this, a very simple idea of the overall execution time can be derived.

In this case, the agent is (happily) communicating with two entities, one written in C++ and the other in Java. Though a relatively trivial test, this shows the platform-independent power of standardized protocols.

Ways to Improve the Two Sample Programs

Our two efforts are far from being production-standard code! There are many ways in which they both can be materially improved:

  • Make the operations asynchronous to free up resources when waiting on replies.

  • Move the parameters off the command line or provide them in encrypted form.

  • Make the programs independent of MIB object specificationsthe existing structure is inflexible because a MIB change would require a code change.

  • Provide a facility for adding support for new MIBs.

  • Allow multiple OIDs in one PDUthis reduces traffic for multi-object operations.

  • Move all SNMP API code into a separate module or even a separate server. The latter would help to thin down the client programs.

  • Remove global variables .

  • Provide a non-debug version of the C++ program (faster and smaller).

  • Allow table-based operations, such as for getting and setting rows in a MIB table.

  • Provide an external data source other than the command line.

  • Support SNMPv3.

It is better to fulfill the above from the ground up, that is, before writing any code. The examples were written purely to try to make concrete some of the major SNMP concepts.



Network Management, MIBs and MPLS
Network Management, MIBs and MPLS: Principles, Design and Implementation
ISBN: 0131011138
EAN: 2147483647
Year: 2003
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net