 | Level: Intermediate Paul Monday (pmonday@home.com), Senior Software Engineer, Imation Corp.
01 May 2001 If you're looking for a unique programming challenge, try your hand at building a management application for a distributed, cross-platform network. Consider, for example, what it takes to build a storage network. Network switch and hub technology is typically purchased from one vendor, storage appliances from another vendor, and file servers and software from yet another set of vendors. And then it's up to you to make sure they all work together, with nary a hiccup. Luckily, two technologies have the potential to vastly improve the current state of affairs. This article is the first in a three-part series that looks at how Sun Microsystems's Jiro technology and the Distributed Management Task Force's Web-Based Enterprise Management Initiative (WBEM) can simplify the creation of management applications for heterogeneous environments. Author Paul Monday launches the series this week with a beginner's introduction to the Federated Management Architecture and Jiro technology.
The Federated Management Architecture (FMA), a standard extension to
the Java 2 platform, is Sun Microsystems' architecture for creating
policy-based management application infrastructures. Jiro technology,
also from Sun, is currently the only implementation of the FMA.
Together, Jiro and the FMA fill an essential niche in Sun's platform
line-up, providing a clean development solution where it is most
sorely needed. The FMA defines a service-centric model that enables Java
developers to build complex, policy-based management solutions for
distributed environments. Jiro technology implements the FMA, using
the Java and Jini platforms as its base and extending those platforms
with services and capabilities specific to distributed storage
networks. In this article, the first of a three-part series on developing
management applications, I'll provide an introduction to
the FMA and Jiro technology. We'll go over the FMA specification and
I'll explain its analysis model and describe each of its components
in depth. I'll show you, in a rudimentary way, how to build a
management facade and how to implement management policies. I'll also
explain how Jiro works to extend Jini technology and the Java 2
platform, offer download information and advice, and describe the
tools that come packaged with Jiro. Before we launch into the thick
of things, however, I think an overview of policy-based
management is in order.
Note: This series assumes you have
functional knowledge of the Jini platform and distributed object
programming. Explanation of the terms and concepts related to Jini
technology and distributed object programming is beyond the scope of
this series. Policy-based management
While there is nothing new about policy-based management, the need
for it has never been greater. Managing storage resources is
expensive, error prone, and often done manually. As distributed
storage networks grow in size and complexity, the expense and effort
of tending to them by hand becomes overwhelming, if not
impossible. Traditionally, policy-based management has been deployed across a
network to control and define user access to resources. As defined by
the FMA and implemented by Jiro, policy-based management assigns
components within a system (such as a storage network) to
automatically respond to events fired within the system, according to a
predefined set of rules, or policies. For example, you might establish a policy to handle space on a
filesystem. You would define a policy component to monitor
your system's filesystem allocations, and when the available free
space dropped below the established parameter, the component would
take steps to increase the free space. There are several ways to set
up such a policy. In its simplest form, the policy could instruct
the component to delete all files that had gone unused for a
given number of days. A more sophisticated approach would be to have
the component locate a free storage volume and expand the filesystem
over to the new storage volume. The second, more complex, approach
is the more desirable of the two. But your ability to implement
complex policies is dependent on the underlying architecture of your
system. This is where the FMA comes in, providing that architecture
as an extension to the Java 2 platform.
The Federated Management
Architecture
The FMA was developed under the Java Community
Process and released in its final version last year. It is a standard
extension to the Java 2 platform. The FMA allows managed resources
and management components -- such as the filesystem and policy
component in the above example -- to coexist and communicate within a
common framework. Because the FMA is an open, Java-based standard, it
greatly increases the ease with which Java developers can build
automated solutions for complex, distributed environments. The architecture is separated into three parts, which we'll
explore in depth:
- An analysis model, which defines the boundaries of the FMA
specification
-
Static services, which are always available in a
management domain
-
Dynamic services, which are constructed and deployed into a
management domain
A management domain represents a portion of the network.
Multiple management domains comprise the network. Each management
domain is a logical partition of managed resources and management
services. For example, one management domain might contain the
logical partition of the storage network that contains the employee
storage volumes, while another might contain the Web servers and
software that make up the management components for the company's
external Web site. The FMA's analysis model
The two important points to be derived from the FMA's analysis
model are that:
- Services are deployed into management domains that are
logical partitions of managed resources.
- Applications built with the FMA should conform to a three-tier
architecture consisting of clients, services, and managed resources.
As Figure 1 illustrates, the FMA sits
squarely in the services tier of this architecture. The services tier
itself is informally split into three types of services:
-
Static services that provide common application
communication points.
-
Dynamic services that represent managed resources to other
components and clients. These services are known as management
facades.
-
Dynamic services that act on data available from both static and
dynamic services. These types of services are known as management
policies.
The three-tier structure for developing applications and the three types of
services that comprise the services tier are illustrated in Figure 1.
Figure 1. FMA's three-tier solution
By defining a three-tier model, then splitting the services tier
into three types of service, the FMA creates a clean split in the
programming requirements for management applications. Now, let's take
a closer look at how those services work.
How services work
The Jiro SDK includes a tool, the igniter, that takes care of
starting up management servers, also known as stations, in the network.
Each station will host a management domain as well as all of the
components that should run in a station. The igniter launches the
following services
in each station:
- A class server (used for remote class loading)
- A Jini lookup service, for locating and using services offered in
the hosted management domain
- A deployment station, so clients can attach to
the station and deploy additional management services
- The static services (with proxies to the services offered in the
lookup service)
- The RMI Activation Service
The igniter is shown at work in Figure 2.
Figure 2. The igniter at work
A client can get a proxy to a station and instantiate classes and
call static methods on classes residing within that station via an
Extended Remote Method Invocation (ERMI) model. A client can
also get proxies to object instances that reside in a station and
call remote methods against a given instance, similar to RMI. Proxies
to services in a station are obtained through the Jini lookup service
that is run with the station. The station also manages additional
behavior defined by the FMA, such as distributed locking
capabilities, object persistence, and object availability. Often, a management domain and its contents are driven by
necessity rather than load management in a particular domain. For
example, a component that represents a storage array that is
manipulated through the SCSI command set must reside on the server
that is directly connected to the storage array via the SCSI card.
As a result, the station and the management facade must both be
located on the same host on which the SCSI commands are required to
run. On the other hand, a storage array that is manipulated through a
Web server does not require the management facade implementation to
be co-located with the server that writes data to the disk array. This
separation of the data path from the control path is known as
out-of-band management. Both of these configurations are shown
in Figure 3.
Figure 3. Management domains
Static services
The FMA defines a set of static services in its specification. When
implemented by the Jiro platform, these services are deployed to each
publicly available management domain. The static services are as
follows:
-
Scheduling service. This service is used to schedule coarse-grained
events. System components are registered with the scheduler, which
then makes calls to those components by calling the
Notify method on Jini's RemoteEventListener
interface. A variety of schedule types are available.
-
Log service. This is a location that receives logged
events and allows the events to be queried by a variety of parameters
and search criteria. Logged messages are ordered by a hierarchical
topic tree. Messages can contain exceptions that may have occurred
in the network, and all text is localizable.
-
Event service. This is a topic-based event service that
handles delivery of messages to interested parties that register
based on a particular topic. (The event service will be demonstrated
later in this article.)
-
Controller service. The FMA defines a unique method of
synchronization known as controller synchronization. The controller
essentially handles the holding and releasing of distributed locks
based on controller generations. In the FMA, there are three types
of synchronization. To understand all types of synchronization, you
should take time to read the FMA spec (see Resources).
-
Transaction manager. The transaction manager deployed by
the Jiro platform is actually the same transaction manager offered by
the Jini platform. The FMA does not use transactions in the normal
database sense, but rather as a way to offer distributed
synchronization capabilities.
Locating static services in the network
All of the above services can be located via the
javax.fma.services.ServiceFinder
class. The service finder provides an easy-to-learn interface that
allows a component to look up a service that exists either within
the same management domain as itself or in a domain that the component
is not a part of. For example, you will occasionally need to use a
service from a client program. Because the client is not part of any management
domain, you will use a method signature that contains as a parameter the management
domain from which you wish to retrieve the service. The interface for the service finder is shown in Listing 1.
Listing 1. The service finder
public final class ServiceFinder
{
/** Returns transaction service for local management domain.
* @return TransactionManager for local management domain.
* @throws ServiceNotFoundException if service is not found.
*/
public static TransactionManager getTransactionService()
throws ServiceNotFoundException;
/** Returns controller service for local management domain.
* @return ControllerService for local management domain.
* @throws ServiceNotFoundException if service is not found.
*/
public static ControllerService getControllerService()
throws ServiceNotFoundException;
/** Returns log service for local management domain.
* @return LogService for local management domain.
* @throws ServiceNotFoundException if service is not found.
*/
public static LogService getLogService()
throws ServiceNotFoundException;
/** Returns event service for local management domain.
* @return EventService for local management domain.
* @throws ServiceNotFoundException if service is not found.
*/
public static EventService getEventService()
throws ServiceNotFoundException;
/** Returns scheduling service for local management domain.
* @return SchedulingService for local management domain.
* @throws ServiceNotFoundException if service is not found.
*/
public static SchedulingService getSchedulingService()
throws ServiceNotFoundException;
/** Returns transaction service for specified management domain.
* @param domain Management domain of desired service.
* @return TransactionManager for specified management domain.
* @throws ServiceNotFoundException if service is not found.
*/
public static TransactionManager getTransactionService( String domain )
throws ServiceNotFoundException;
/** Returns controller service for specified management domain.
* @param domain Management domain of desired service.
* @return ControllerService for specified management domain.
* @throws ServiceNotFoundException if service is not found.
*/
public static ControllerService getControllerService( String domain )
throws ServiceNotFoundException;
/** Returns log service for specified management domain.
* @param domain Management domain of desired service.
* @return LogService for specified management domain.
* @throws ServiceNotFoundException if service is not found.
*/
public static LogService getLogService( String domain )
throws ServiceNotFoundException;
/** Returns event service for specified management domain.
* @param domain Management domain of desired service.
* @return EventService for specified management domain.
* @throws ServiceNotFoundException if service is not found.
*/
public static EventService getEventService( String domain )
throws ServiceNotFoundException;
/** Returns scheduling service for specified management domain.
* @param domain Management domain of desired service.
* @return SchedulingService for specified management domain.
* @throws ServiceNotFoundException if service is not found.
*/
public static SchedulingService getSchedulingService( String domain )
throws ServiceNotFoundException;
}
|
A working example
To better understand the workings
of static services, consider the event service. The event
service defined by the FMA adds value to the traditional event model.
The FMA event service receives events from components and forwards
them to subscribers, offloading event distribution from management
components. The FMA event service also alters the structure of
event notifications in significant ways. Events are topical in nature. For instance, an event to indicate
that the statistics for a filesystem have changed might be
".filesystem.changed". Subscriptions to event topics can be for
entire topic branches or for single event topics. Both observers and
responsible listeners can subscribe to events. An observer that
subscribes to an event will receive all events based on a topic
string. A responsible listener has the capacity to act on an event
notification, resolving the event if necessary. To better understand how this works, refer back to the filesystem
example. A policy has been established to expand the filesystem upon
reaching a certain low free-space parameter. In our example, a series
of components would be deployed to resolve out-of-space problems.
When an out-of-space event was fired, each component in the
responsible-listener chain would have the opportunity to resolve it.
Once resolved, no other listeners would be notified. The FMA event service passes
javax.fma.services.event.Event object instances around
the network. The Event class itself is an abstract
class. To post an event, you must subclass the Event
class and post the subclass to the event service. An important part
of subclassing is to provide a type-safe constructor. In addition to
the type-safe constructor, it is often convenient to have the event
topic string within the subclass so that the object posting the event
does not have to deal with the topic string. Listing 2 shows an
example of an event subclass.
Listing 2. A subclass of an FMA Event
public class FileSystemChangeEvent
extends Event
{
public FileSystemChangeEvent(FileSystem source) {
super(source, "filesystem.changed");
}
public Object clone(){
return new FileSystemChangeEvent(
(FileSystem)getSource()
);
}
}
|
A broader discussion of static services is beyond the scope of
this article. See Resources for links to additional
information about static services.
Management facades
The management facade is one of two types of dynamic services
specified by the FMA. Management facades are created to represent
components -- such as tape devices, networking infrastructure,
storage units, and software -- to other components in the network.
Each component, or managed resource, in the network must present a
management facade to be accessible to other components in the
network. A management facade presents a common interface, but its
implementation is typically tied to a specific technology. If a
common interface for a service is available from the Jiro community,
then vendors will create implementations of that service for their
products. Most likely, the implementations of the methods will be
unique, unless the managed resource can be manipulated with
standardized control points. This may be the case if a product
adheres to a standard such as Simple Network Management Protocol
(SNMP) or supplies a Web-Based Enterprise Management (WBEM)
implementation. (I'll talk more about WBEM in the next
installment in this series.) Often, method implementations will require native implementations because many resources can only be manipulated through
low-level system calls. An example of this would be a tape library
that is managed through the SCSI command set. Currently, there are management facades available for products
from Crossroads, Veritas, and Sun (see Resources).
In the next section, I'll show you how to build your own very simple
management facade. Building a management facade
Filesystems typically
have a wide variety of common properties and methods, such as the
amount of space that is used and the method by which that total space
is obtained. A very simple filesystem interface may appear as shown
in Listing 3.
Listing 3. A filesystem interface
public interface FileSystem {
public long getTotalSpace() throws RemoteException;
public long getUsedSpace() throws RemoteException;
public void setUsedSpace(long usedSpace) throws RemoteException;
public void setTotalSpace(long newSpace) throws RemoteException;
}
|
Note the use of the RemoteException in Listing 3.
All methods in an interface for a dynamic service must throw
a remote exception. After an implementation of the filesystem is
built, it is deployed to a management station and registered in a
Jini lookup service. From that point forward, clients of the
management facade will obtain a proxy to the service and use it
remotely. There are a variety of circumstances under which the
Jiro infrastructure would throw a remote exception, all of which
are detailed in the FMA specification (see Resources). Listing 4 shows a very simple management facade implementation for
a filesystem. This implementation should never be used in a real
application.
Listing 4. A filesystem management facade
package com.ibm.jiro;
import java.rmi.RemoteException;
import javax.fma.services.ServiceFinder;
import javax.fma.services.event.*;
public class SimpleJavaFileSystem
implements FileSystem {
protected EventService ev = null; // cache variable
protected FileSystem proxy = null;// cache variable
protected long totalSpace = 10; // total space
protected long usedSpace = 0; // total used
/**
* Default null constructor
*/
public SimpleJavaFileSystem(){
}
/**
* Returns the total amount of space on filesystem
* @return long indicating the total amount of space
*/
public long getTotalSpace()
throws RemoteException
{
return totalSpace;
}
/**
* Returns the total amount of used space on the
* filesystem
* @return long indicating total amount of used space
*/
public long getUsedSpace()
throws RemoteException
{
return usedSpace;
}
/**
* This is code to get a non-complex example,
* it allows the used space to be incremented.
* Normally, a call like this would actually
* be native and call to the operating system.
* @param usedSpace is the total amount of used
* space on the filesystem
*/
public void setUsedSpace(long usedSpace)
throws RemoteException
{
this.usedSpace = usedSpace;
EventService ev = getEventService();
// Construct a proxy to this object and post
// it to the event service.
ev.post(new FileSystemChangeEvent(getProxy()));
}
/**
* This is code to get a non-complex example.
* It allows the total space to be arbitrarily
* set. Normally, expanding or contracting
* a filesystem would be an extremely complex
* operation.
* @param newSpace is the total amount of space
* in the filesystem
*/
public void setTotalSpace(long newSpace)
throws RemoteException
{
totalSpace = newSpace;
}
/**
* Returns the event service that is local
* to the service's management domain. If
* this was already called, a cached event
* service proxy will be returned.
* @return EventService is an instance of a
* proxy to the event service.
*/
protected EventService getEventService()
throws RemoteException
{
if (ev == null) {
try {
// Attempt to locate the event service,
// because this component is running
// in a management domain, we do not
// need to specify the domain
// to locate the service.
ev = ServiceFinder.getEventService();
} catch (
ServiceFinder.ServiceNotFoundException snfe
)
{
// exception recovery
snfe.printStackTrace();
}
}
return ev;
}
/**
* This returns a proxy to this service. If one
* was already built, the cached version will be
* returned.
* @return FileSystem is a proxy to this service.
*/
protected FileSystem getProxy()
throws RemoteException
{
if (proxy == null) {
// A proxy is built from within a service
// by calling a constructor
// on the proxy with the current class instance
proxy = new SimpleJavaFileSystemProxy(this);
}
return proxy;
}
}
|
Some notes about the example:
- The method for changing the statistics, total space, and used
space is to actually have a client attach to the service and
increase the used space. This is a contrived example; in reality, you
could have the service poll the filesystem or be driven from events
within the filesystem itself through a native API to the
filesystem.
- When the used space is changed, an event is posted to the
domain's event service. The event service then handles who receives
the event based on the subscriptions.
- The proxy passed with the event is an ERMI proxy, not a
traditional RMI proxy. (See Resources for more
information on programming to the Jiro distributed object model.)
- An additional method was added to obtain a reference to the event
service if one was not yet retrieved.
In a distributed management system, the above filesystem
management facade would be deployed to a management domain via a
management station. It would be instantiated within the station via a
constructor, using a proxy that was itself generated using a tool
shipped with the Jiro SDK. Other services or clients could
subsequently connect to the filesystem and use it.
Management policies
The second type of dynamic service in the services tier is the
management policy. Management policies define the internal workings
of the heterogeneous components within a distributed network.
Typically, the management policy is defined by the solution provider
as part of the creation of a management application for a distributed
network. Management policies leverage management facades, other
management policies, and the available static services to achieve
their purpose. Creating a management policy
To help you better
understand how management policies work, we'll define a simple
management policy for the maintenance of filesystem memory, using the
filesystem interface in the above example. According to our policy,
when a filesystem's total free space reaches one unit remaining, we
want to increase the total space by calling the
setTotalSpace() method on the management facade,
allocating a larger amount of space. There are many ways to achieve the desired behavior. We could
locate all of the management facades that implement the
FileSystem interface via a lookup to a Jini service
registrar, then poll them every few minutes, checking the amount of
unused space. An alternative method would be to simply wait to
receive an event that matched a preset topic string. With the event
would come a reference back to the originating object, and we could
then intervene by resetting the space on that filesystem. We will use the second method, which allows us to leverage the
Jiro event service. We will first define the interface for the
management policy, then define an implementation. The split between
interface and implementation allows our management policy to be used
remotely, and to have more than one implementation if the need should
ever arise. Listing 5 shows the interface to our available space policy. Like
the filesystem example, this policy is very simplistic. It
essentially receives event notifications and reacts to the events
when the available-space threshold is crossed.
Listing 5. Available space policy interface
public interface SpaceMonitorPolicy {
public void setSpaceThreshold(long availableSpace)
throws RemoteException;
}
|
The monitor policy shown in Listing 6 is based on the above
interface. It is entirely event driven. Upon creation, it registers
an interest with the event service for the ".filesystem.changed"
topic string. The event service will deliver the event and the
monitor policy can then take action based on whether or not the
filesystem is running out of space.
Listing 6. Available space policy interface
public class SpaceMonitorPolicyImpl implements
SpaceMonitorPolicy, RemoteEventListener {
protected long spaceThreshold = 1;
protected EventService ev = null;
protected LeaseRenewalManager lrm = null;
protected SpaceMonitorPolicy proxy = null;
/**
* The default constructor will locate
* the event service and subscribe our instance
* to the observer list for the event with the
* topic "filesystem.changed". The component
* is then able to receive callbacks via the
* notify method.
*/
public SpaceMonitorPolicyImpl() {
try {
EventService eventService =
getEventService();
Lease l = eventService.subscribeObserver(
"filesystem.changed",
(SpaceMonitorPolicyImplProxy)getProxy(),
null, Lease.FOREVER);
lrm = new LeaseRenewalManager(l,
Lease.FOREVER, null);
} catch (RemoteException re){
re.printStackTrace();
}
}
/**
* Changes the space threshold at which we will
* increment the total space on the filesystem
* @param availableSpace is a long that determines
* the threshold of available space at which the
* target filesystem will be increased.
*/
public void setSpaceThreshold(long availableSpace)
throws RemoteException {
this.spaceThreshold = availableSpace;
}
/**
* The space threshold at which we will act to
* increase the target filesystem's space.
* @return long is the space threshold.
*/
public long getSpaceThreshold(long availableSpace)
throws RemoteException {
return this.spaceThreshold;
}
/**
* This method is called against a proxy to this
* service that resides in Jiro's event service. The
* proxy then calls this method and we are able
* to process the event.
* @param event is a Jini remote event instance that
* contains the source of the event as well as some
* other important information.
*/
public void notify(
RemoteEvent event) {
System.out.println("Received Event");
Object o = event.getSource();
if(o!=null && o instanceof FileSystem){
FileSystem fs = (FileSystem)o;
try {
long totalSpace = fs.getTotalSpace();
long usedSpace = fs.getUsedSpace();
System.out.println("Total Space="+totalSpace+
", Used Space="+usedSpace);
if((totalSpace - usedSpace) < spaceThreshold){
System.out.println(" Increasing Space");
fs.setTotalSpace(totalSpace + 10);
}
} catch(RemoteException re){
re.printStackTrace();
}
}
}
/**
* Returns the event service that is local
* to the service's management domain. If
* this was already called, a cached event
* service proxy will be returned.
* @return EventService is an instance of a
* proxy to the event service.
*/
protected EventService getEventService()
throws RemoteException
{
if (ev == null) {
try {
ev = ServiceFinder.getEventService();
} catch (
ServiceFinder.ServiceNotFoundException snfe
) {
// exception recovery
snfe.printStackTrace();
}
}
return ev;
}
/**
* This returns a proxy to this service. If one
* was already built, the cached version will be
* returned.
* @return SpaceMonitorPolicy is a proxy to this service.
*/
protected SpaceMonitorPolicy getProxy()
throws RemoteException
{
if (proxy == null) {
proxy = new SpaceMonitorPolicyImplProxy(this);
}
return proxy;
}
}
|
Some notes about the example:
- The
SpaceMonitorPolicyImpl class implements
Jini's RemoteEventListener interface. This is the
mechanism with which the event service calls back to interested
parties. Our notify method is called when the event service receives
an event that matches the topic string that we've registered
for.
- The constructor subscribes the component to the
".filesystem.changed" topic string upon instantiation of the service
within a management domain.
- Like the management facade, we will have to register a proxy to
our service with the event service, thus the
getProxy()
method and the getEventService() methods are
useful.
The management facade and policy are instantiated within a
management domain via an ERMI proxy call to the constructor of each
service. The services will then run until their Jini lease runs out.
Advanced Jiro programmers can leverage additional FMA services to
control the behavior of a service.
A word about advanced capabilities
The FMA defines interfaces and services that programmers can use to
bootstrap component development. For instance, deploying a service
into a pure Jini network involves locating network registrars,
registering the service with the registrar, and maintaining a lease
that is returned to the application that registers the service. With
the Jiro platform, as defined by the FMA, a developer can leverage
the Jiro station through component implementations to handle the
leases for the software component. Persistence is another service that is built into the Jiro
foundation. By adding a modifier to a class, the Jiro infrastructure
will make instances persistent within the context of the station
after they are instantiated. Other class modifiers exist for
security, for distributed locking mechanisms, and to define the behavior
of software components relative to garbage collection and restart of
a station. Finally, a localization framework and special classes to aid in
debugging components are built into the Jiro technology. Some of
these, such as localization, are defined by the FMA; others are built
specifically for the Jiro technology. With a basic understanding of the development framework specified
by the FMA, we're ready to move on to learning about Jiro. To learn more
about the analysis model, static services, dynamic services, and
advanced capabilities supported by the FMA, see the FMA specification
(in Resources).
Getting started with Jiro
technology
Jiro technology comes in two forms: a run-time kit and a software
development kit (SDK). Both versions of the Jiro platform come with
the proper classes for the supported Jini platform. For the Jiro
technology to work, the Java 2 platform, version 1.3 must already be
installed on the target system. You can download the Jiro SDK directly from Sun (see Resources). Both Windows NT and Sun Solaris are
supported, and you will also find a .tar file for unsupported UNIX
environments. I have successfully used this on the Linux 2.2
operating system kernel. After download, run the installer on the target operating system.
The following documents will get you started with the Jiro technology
SDK:
- The Jiro technology Installation and Configuration Guide
will tell you what platforms are supported, inform you of the
dependencies you must meet, and step you through any issues you may
have with installation. It is important that you meet all
dependencies and version requirements. If unheeded, subtle changes
in distributed object support could cause your programs to fail in
unexpected ways.
-
Jiro technology SDK Programmer's Reference is a good place
to get started with the concepts and terminology that you will need
for programming with Jiro technology.
Expect to take some time to become an effective Jiro technology
programmer, especially if you do not have advanced Jini technology
skills or if you are not well-versed in distributed object
programming. The installation documents serve as a good starting
point. See Resources for further references
(including my book).
What's in Jiro's toolkit?
The Jiro SDK comes complete with a host of developer tools, which you will
use throughout your work with the Jiro technology. The tools
typically are available in two forms: a GUI version and a
command-line version. I recommend
that you start with the GUI version of each tool, then work your way
into the command-line version
if you prefer. The tools that comprise the Jiro toolkit are
listed below.
-
igniter: We discussed the igniter earlier in this article. The
igniter starts up a station and its associated management services in one
easy step.
-
jarpack: When deploying a service to a station, it is important
that all dependencies (not including the Java 2 platform classes) be
packaged in the jar file that contains the service. This package
should also include the resources. jarpack will help you
assemble your services into three jar files: one that is deployed to the
station; one that will be downloadable from the station for clients
of your service; and one for the interface.
-
jiroc: This tool generates extended remote method
invocation proxies and also aids in putting code modifiers into your
implementation file. The code modifiers are used for synchronization,
security, and station modifiers.
-
jardeploy: This tool helps you deploy your packed jar files to a
station for use by others.
Conclusion
Clearly, the FMA and the Jiro technology implementation cannot be
completely covered in the space of one article. Instead, I've
concentrated on providing an overview of the architecture
and getting you started with the Jiro technology.
All examples used in the article were overly simplified, because
management application programming is an inherently complex
space. One of the benefits of using an implementation of the FMA is the
ability to define and apply different types of expertise in problem solving.
For example, experts in device interaction are able to focus on programming
management facades that interact with managed devices, while experts
in policy programming are able to focus on building policy
components. The next installment in this series will be dedicated to
the Web-Based Enterprise Management (WBEM) initiative.
WBEM is a standard developed by the Distributed Management Task Force (DMTF).
It defines a method for representing managed elements in a common network
repository and a set of standards for interacting with that network
repository. At first glance, you will notice that there appears to be overlap
between the Jiro technology and WBEM. We'll address that overlap
in the third installment in the series, where I'll talk about
how the Jiro platform and WBEM can coexist and
leverage each other's strengths to achieve complete
network management solutions.
Resources - Participate in the discussion forum.
- Download the complete FMA specification (in PDF).
- Part 2 of this series, "Introduction to WBEM and the CIM" (developerWorks, June 2001), focuses on Web-Based Enterprise Management and the Common Information Model. Part 3, "Building management applications with Jiro and WBEM" (developerWorks, July 2001), shows you how to leverage the best parts of Jiro technology and the WBEM initiative.
- There are surprisingly few independent resources for developers
developing Java-based management applications. JavaWorld
offers some coverage with its management series.
- Paul Monday and lead FMA architect William Connor coauthored The Jiro Technology Programmer's Guide.
- Find out how the RMI activation framework can produce self-sufficient, flexible Jini services (developerWorks, October 2000).
- The IBM Almaden research lab offers TSpaces, communication middleware that allows heterogeneous, Java-enabled devices to exchange data.
- Visit Storage Networking Industry Association site to see how its members are shaping the way storage is managed.
- Visit the DMTF Web site to see what this group is
doing to standardize distributed management capabilities.
- See what IBM is doing with storage and storage management.
About the author
Rate this page
| |
