|
|
 |
Java
CMIP Toolkit Architecture ... |
| |
 |
Introduction |
 |
Customers
Need Integrated Management Solutions
A network administrator works in a
complex heterogenous environment that
makes up the enterprise. They must
use a diverse set of autonomous applications
to manage a wide range of remote information
to solve service problems and keep
business in operation. Network management
application architects and developers
too have to work with a diverse set
of environments, and platforms to develop
and maintain these applications.
|
|
Heterogenity
is a given
Different operating systems, different
hardware, and different network protocols
make up the enterprise computing environment.
The differences are only going to get
greater as new technologies appear.
|
|
The Current
Porting Paradigm
The industry has not developed common
set of interfaces for management
applications. Today’s platforms and frameworks
only make life more complicated. They
contain multiple distinct interfaces
exacerbating the task of porting applications.
Application developers must port multiple
times to support multiple platforms,
and aren’t able to optimize
the interaction between applications
and
shared management services.
|
|
Things
Change
New releases of software, better hardware
capabilities, and different network
protocols are a fact of everyday life
for administrators. Unfortunately,
the tools that they use to manage these
resources are unable to cope gracefully
with these changes.
|
|
Industrial
trends
To address the above issues, since
Java is a natural choice for distributed
applications, it is rapidly becoming
the defacto platform for network management
applications. Java has the potential
to unify the complex environments and
diverse platforms under a common umbrella.
To be able to develop the network management
applications in Java, you need the
ability to deal with the requirements
of a variety of network management
and communication protocols in Java.
CMIP is one of the most commonly
used network management protocols.
The complexities
of CMIP have since long posed a challenge
to develop CMIP applications in Java.
The JCMIP toolkit addresses this
issue.
|
|
JCMIPMan
API
JCMIP attempts to overcome this
handicap by bridging the gap between
CMIP and Java. It can integrate with
other Java based network management
architectures enabling seamless application
development.
With application integration, a previously
diverse set of autonomous applications
may be brought together under a common
look, feel, and behavior everywhere
they run. This greatly simplifies the
management task.
|
|
Benefits
of the JCMIPMan API
The JCMIP API is a collection of
Java classes that allow developers
to more easily build applications
to provide integrated management
solutions
by taking advantage of the Java computing
environment. By combining Java and
the JCMIP API, developers wanting
to develop integrated management
solutions gain the following benefits: |
| |
|
Develop Anywhere,
Run Everywhere
The
Java Virtual Machine
runs on a number of operating
systems,
and this number is growing.
The JCMIP API further
enhances
the platform independence
provided by Java by allowing
secure downloading
of libraries that implement
native methods. An essential
component
of the toolkit, the GDMO
and the ASN.1 compilers
are written
in Java, thus enabling
the toolkit to work on
all platforms.
|
|
Integration Is the Key The
classes provided by the
JCMIP API allow for easy
integration from the user
interface components
to the object definitions.
By registering the pages
and object
definitions, navigation
throughout the management
information space
is seamless.
|
|
Eliminates Agent Versioning and
Distribution Problems
Management in the enterprise
environment is inherently distributed.
This requires administrators
to perform operations on resources
that are located throughout the
network. All distributed management
products refer to the software
components that implement these
remote operations as agents.
Agents are very specific to a
version of software or hardware
that they provide the management
interface for, which creates
a problem.
|
|
|
Goals
In
order for JCMIP to be successful,
the following goals must be fulfilled:
Leverage existing technologies.
The JCMIP cannot implement all
of
the necessary functionality from
scratch. Rather we must rely on
other existing
technologies for the basis of implementation.
Minimize dependencies. An attempt
to eliminate dependencies on technologies
that are not considered commodities
is a must.
Bridge the reality of today with
the future. A large installed base
of non-integrated management applications
exist today. We must address the
migration issues of getting to
the future from where we are today.
|
|
Dependencies
We cannot realistically build
and deliver all the infrastructure
necessary
to provide management functionality
that scales from workgroups to
the enterprise. What’s
needed is a basic infrastructure
on which to
layer
management functionality. The infrastructure
must be widely available and adopted,
as well as provide necessary and
sufficient functionality.
Given these constraints,
the following technologies must be
in place to support this architecture:
A Java-enabled Web browser with JDK1.2
or above. All relevant commercial web
browsers are already Java-enabled.
A JDK1.2 or above virtual machine.
A commercial relational database that
has a JDBC driver.
|
|
|
|
JCMIP
architecture... |
| |
The
JCMIP package is divided in the following
components: |
| |
|
GDMO
to Java Compiler |
|
ASN.1
to Java compiler |
|
Java
ASN.1 base classes |
|
Java GDMO
base classes and Generated Code |
|
Communication
APIs |
|
Sample Code |
| In
the following sections, we will discuss
each of the components in detail. |
|
GDMO
to Java Compiler
The GDMO to Java Compiler
is used to convert the information
model
expressed in terms of GDMO template
files to Java classes. We have
tried to adhere to NMF's GDMO-C++
mapping
as closely as possible. However,
since Java does not support multipleinheritence,
and the GDMO does, we have altered
the mapping for this special case.
If a GDMO Managed Object (MO) class
is derived from multiple MO classes,
in the corresponding generated
Java code, it is derived from the
first
class in the "DERIVED FROM" list,
and the attributes of the rest
of the base classes are directly
made
data members of the class under
consideration.
The
compiler is based on the Metamata Inc.'s JaCC parser generator tool.
The JaCC grammer's generated Java
code parses the GDMO template definitions
in the GDMO files, and builds a
parse tree. This parse tree is
used in
conjunction with code generation
templates to generate Java code
for the GDMO templates. It is worth
noting
that "root" of the "inheritence
tree" of the GDMO classes is
considered to be the "top" class
in the X721 standard. This is in
agreement with the NMF's specifications. |
| |
|
|
ASN.1 to
Java Compiler
The ASN.1 to Java Compiler is used
to convert the data types expressed
in terms of ASN.1constructs to Java
classes. The generated code for an
ASN.1 data definition is as close to
the original data definition as possible.
In addition, since the classes in generated
code are derived from the classes in
the Java ASN.1 library, users get access
to the useful methods of the base classes
to manipulate the objects of the generated
classes, compare the objects, and display
the contents of the objects. This minimizes
the amount of generated code. The base
classes in the Java ASN.1 library also
contain methods to perform BER encoding,
and decoding of the ASN.1 objects.
The
compiler is based on the Metamata Inc.'s JaCC parser
generator tool.
The JaCC grammer's generated Java
code parses the ASN.1 constructs
in the ASN.1 files, and builds a
parse tree. This parse tree is used
in conjunction with code generation
templates to generate Java code for
the ASN.1 constructs. It is worth
noting that "root" of the "inheritence
tree" of the generated Java
classes is "JAsn1Obj" class
defined in our Java ASN.1 library.
|
|
|
Java ASN.1
base classes
The Java ASN.1 base classes form
the basis of our Java ASN.1 library.
They provide methods for encoding,
decoding of ASN.1 objects, to manipulate
and examine the contents of the objects
by easy and intuitive means, to compare
two objects, and to print the contents
the objects in a meaningful way for
debugging purposes.
Each ASN.1 data type defined in
an ASN.1 file is converted into
a generated Java class, which is derived
from an appropriate base class
in
the Java ASN.1 library. For example,
a data type defined as: |
| |
MyInteger
::= INTEGER
has a Java class equivalent in the
corresponding generated class as
public class MyInteger extends JAsn1Int
{
...
} // end class MyInteger
Similarly, for each integer, boolean,
and OID value definition, a data
field with the value is defined in
the corresponding class. |
|
|
|
|
|
