|
|
The engineering viewpoint will be sparse for J4ONet,
because the engineering viewpoint is concerned with deployment of
a system. J4ONet is a framework for implementing a distributed
JMX solution, thus deployment is not determined in this phase of
development. However, the shape and design of J4ONet make certain
directions more obvious or likely than others.
JMX4ODP deployment will obvious include some sort of JMX and
Java technology. How these technologies are deployed is not an
issue for JMX4ODP.
MC Java (Java as a Wrapper)
JMX4ODP is a JMX framework. JMX is the Java Management
Extension. However, this does not limit the system to managing
only Java based applications. One of the focuses of J2EE is the
concept of using Java as a unifying wrapper technology. The idea
is that many large enterprise systems were not built in a single
iteration, but instead grew and evolved over many iterations.
Sub-systems were phased out and new components added in.
Enterprise systems usually have several generations of technology
operating simultaneously. They usually have their ghettos,
suburbs, mass transit systems, urban renewals, and infrastructure
problems. Enterprise systems end up resembling major cities in
their patchwork assembly. Numerous forces, people, and politics
shape such systems over the years of their operation. These
systems are seldom retired, but instead are modified over and
over again to meet the needs of the current user populous.
To
be a true enterprise solution, J2EE had to deal with the way that
real enterprise systems are grown. Rarely will an organization
replace an entire system with a pure Java solution. Much more
likely is that you will see an organization augment a currents
system with Java components. As time goes on you will see more
and more Java technology integrate into the system and replace
legacy code, especially the archaic, esoteric, or impossible to
maintain pieces. But the mainframe, or master database, or
built-just-for-us proprietary box will never be replaced. Using
JNI or network services, it is a common design to use a
light-weight Java wrapper to make these components accessible to
the whole system.
For example, several network services
of a mainframe application can be wrapped in a light-weight
object. Now this object can be accessed by EJB's, embedded into a
Servlet or JSP, managed by JMX, made to operate via Message
Oriented Middleware via JMS, accessed via a portable swing
client, throw events to a unified event model, or log via Log4J.
In other words, Java can act as an abstraction layer that shields
the proprietary/legacy aspects of a system. Newer technologies
have a unified layer to plug into. Older technologies don't need
to be retrofitted every time something is changed. Java can act
as an infrastructure that is flexible enough to insulate
sub-systems from the evolution of the whole system.
So
despite the fact that this is a Java based project, it can be
used in all sorts of systems: legacy, enterprise, pure Java,
windows, UNIX, client side, server side, Internet, LAN, etc.
JMX:
The Java Management Extensions (JMX)
is a wrapper based architecture for making objects manageable.
Large systems usually involve many sub-systems that each come
with their own management complexities: configurations,
monitoring, events, logging, etc. This becomes especially
apparent in systems that have evolved over time, or that span
across a network. Evolved systems usually employ a multitude of
management systems and techniques. As pieces are added, they used
whatever was available at the time. Some parts use configuration
flat-files, other read XML from a database, some might start a
web server to listen for commands, others use a proprietary
client. Then security might be added haphazardly as possible.
Systems that span a network involve keeping track of multiple
configurations, multiple points of access and control. Now
systems that have evolved to span a network have all of these
issues and more. This is where JMX comes in.
JMX is
usually implemented in one of two ways, as the a core part of the
application, or as icing on the cake. These are the sort of
deployments that JMX4ODP will be used in.
JMX as Core:
Some applications, like JBoss for
example, started with the idea of being managed by JMX from the
beginning. The developers quickly realized that JMX could be
more that just a peripheral system for management, it could be
used to create a highly flexible system that was based on
management. A JMX agent acted like an application kernel, and
managed components are added to the agent to add functionality
to the application. Thus for something like JBoss, the user
could make it as large and feature rich or as small and compact
as he needs at deployment time by editing a configuration file.
In such systems the architecture of the application becomes
manageable, as well as the operation of the application.
JMX
as Icing:
More commonly, JMX is added to an already
existing application as a management layer. Several sub-systems
made from different technology all need to access some common
configuration data, or need unified control. JMX wrappers can
make these object all access a single configuration bean. A
control bean can throw an event that multiple wrapper objects
will listen for. Thus a large enterprise system can be
retrofitted to be managed by SMTP, HTTP, or such.
|