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.

Back to top

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:

1. Services are deployed into management domains that are logical partitions of managed resources.
   
   
2. 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.

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.

Back to top

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.

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.

Back to top

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.

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.

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.

Back to top

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.

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.

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.

Back to top

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.

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.

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.

Back to top

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).

Back to top

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).

Back to top

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.

discuss this topic to forum