ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Using Jini to Build a Catastrophe-Resistant System, Part 2

by Dave Sag
05/15/2002

In the first part of this series, I discussed the technologies underlying an application that could resist the impact of a 767. I called this system Corporate Operating System, or COS. The need for such systems has forced the emergence of many new layers in application development, above and beyond the traditional n-tier structure. We have the Java Virtual Machine layer as a substrata, followed by a Service Container layer, in parallel with a basic set of ensemble provisioning services, such as those provided by Rio. Above that you now have a couple of application layers.

For some applications you may need to write specialized services. For this, you have access to all of the code of COS (described in detail in part one), and soon (hopefully) you'll also have access to the source code for Rio, as well as Jini. You could simply extend COS' AbstractCosJSB (a super-class of Rio's own Service Beans) and fill in the blanks, or for a more complex JSB that interacts with COS' serviceFlags, extend AbstractServiceFlagJSB. This extends AbstractCosJSB and like it, provides a method:

public abstract boolean performServiceOperation(CosEntryInterface entry,
    Transaction trans,
    String serviceparam)
  throws CriticalObjectStoreException, CosApplicationException;

This is the central method that executes a "worker" method on the target object. It takes two interesting parameters: the target entry object, and a string parameter that is used to select the method on the target to execute. The service parameter is often used to morph the behavior of this method, with each value relating to a different interface method on the primitive target entry.

The values of the service parameter are usually hard-coded into the definition of this method on the implementing service bean. They are also specified in an XML configuration file in the central COS system, and are distributed along with the ServiceConfiguration object. The parity of these two sources can be verified in the doServiceConfiguration method of the interface.

Each service extending this class follows the "Service Flag Pattern." This pattern connects the service to a named JavaSpace, where it listens for ServiceFlag with a property set to the name of that service bean implementation. ServiceFlag objects are messages describing the location of a target Entry in the space and a simple instruction as to what it is to do with that Entry.

Services have access to the full range of features of a Rio JSB, and as such can be good citizens of a J2EE or CORBA environment, or a JSP Web application.

COS Admin screen snapshot.
Figure 1. COS Admin Screen.

For many applications, the default services provided by COS -- JDBC archiving (Karen), HTTPPosting (Roger), garbage collection (Otto), distribution (Max), scheduling (Robin), emailing (Pat the Postman), and a growing list of others -- will work for you out of the box, so you can simply use a default ensemble configuration.

Figure 1 shows the COS admin tool having loaded the dawgTaskTracker.xml file that specifies the Ensemble application. This file is a copy of the default COS ensemble file, the only difference being the line <CosApplication name="dawgTaskTracker" apptype="Dawg">.

A COS client application is simply an application that connects to a named COS ensemble. The client application may simply extend AbstractClientApp and call on its inherited connect() method to perform the actual connection. For security reasons, the COS admin tool is to be used to deploy, start, and stop applications. Your client application will simply connect to the named application if it is running.

Once connected to the COS, your application provides a handy CosConnectable object with create, retrieve, update, delete, and other methods you can use to manage shared information.

Our sample application is an example of what we call a distributed, ad hoc workgroup ("Dawg") application, called TaskTracker. (Great name, huh?)

TaskTracker works as follows: Users log in and report a task or tasks. They allocate the tasks to their buddies. The task itself is represented by an instance of a TaskTrackerEntry that is passed between the COS' JavaSpace and your GUI client app.

Let's take a quick look at the actual TaskTrackerEntry:

public class TaskTrackerEntry extends CosEntry implements Archivable

Task List Screen Snapshot.
Figure 2. Task List.

A CosEntry is a simple extension to the JavaSpace's Entry class, which serves as a COS-specific marker. CosEntries add an application context and a creationEnsembleName, as well as creation and modification dates. This associates the CosEntry with an ensemble. When cos.create(entry) is called, the entry's setCreationEnsembleName() is called. Like JavaSpace entries, all CosEntries must have null constructors and public properties.

In addition to a null constructor, our TaskTrackerEntry provides a more useful constructor for a client application to use when actually creating a new TaskTrackerEntry.

public TaskTrackerEntry (String projectname,
    String name,
    Integer priority,
    String category,
    String blurb,
    String message,
    String user)

The basic principles of the TaskTracker are as follows:

  • Projects can be broken up into descrete high-level tasks.
  • For every task there is a TaskTrackerEntry to represent it.
  • Any member of the system may create and accept tasks.
  • Tasks may be divided into subtasks.
  • Anyone may reassign a task to their buddies.
  • When you accept a task you must say how long you think it will take you to finish it. You may change your mind later on.

This inverts the traditional ERP (Enterprise Resource Planning) or MS ProjectPlan-style project management system in that, although you do specify tasks in a similar way and can easily add sophisticated task dependencies and so forth, only the description of the tasks is done from the top down, and then only at first. The Dawg model encourages a bottom-up approach to task and resource allocation. It permits people to broadcast and refine what they want and to volunteer for duty.

Pages: 1, 2, 3

Next Pagearrow