This animation gives an overall view of  how Ngin works.

Ngin helps disparate services running on any platform to communicate using any(therotically) communication protocol and exchange data. The default implementation uses Jini to communicate with distributed services. The services can be anything from an application which queries a database .. so on, only limited by our imagination.

The core interfaces reside in the highest level packages. Ngin contains at the highest level   5 packages - communication, localengine, service, space, util. The test package just contains test modules for some classes.

This image shows the package structure of the Ngin application.

This image is a screen shot of the localengine package. It is the heart of the application. All the work is done by the classes in this package. The mainengine just delegates the work to the localengine. The 'work' here is the BeanShell script which describes how the services are to be invoked - i.e. in which sequence. Actually the script allows the business manager to have very tight control over the sequence in which the services are to be invoked. It also allows the services to be fired asynchronously. That is when a timer fires. Each service has associated with it a timer which can be set to fire  and start itself/another service. Apart from the BeanShell script describing the sequence in which the services are to invoked, the mainengine also sends a file which describes in detail which services are involved in the current 'work/task'. This information is very important because the services can be, as I said before, using any protocol.
Note: Although there is no separate package as such called mainengine, I will keep referring to the program which invokes and submits the 'work' to the localengine as the mainengine.

Since the script is a BeanShell script, it can make use of almost all the features Java provides. From if...else,for loops to Threads. So, the scripts can be very powerful (and complicated). Currently the scripts have to be coded in a text editor. But a GUI would make the task of scripting very easy. The script refers to the services as Nodes. So, each Workflow Instance will have associated with it a collection of Nodes which are proxies for the real service.

Coming back to the localengine, I'll quickly go through all the important classes and interfaces in this package.

Package : ngin.localengine

Interfaces :
ILocalEngine - The interface allows the mainengine to control the workflow instance, in case a  manual over ride is  required other than the way described in the script.

ILocalEngineCallback - The callback interface that the mainengine must interface to receive    any events from the localengine.

IBeanShellScript - The interface the BeanShell script must implement.

IBeanShellScriptCallback - The callback interface the BeanShell script must use to start/suspend services or access workflow variables.

ILocalEngineConstants -Contains constants used by the localengine.

ILocalEngineDescription - A marker/tag interface which contains no method names. But just an interface the classes of the communication wrappers must interface to describe the localengine.

Classes :
Hub- The class which implements a lot of interfaces :-) and does most of the 'work'. Each 'work' submitted to the localengine is referred to here as a Workflow Instance.

WFInstanceData- Contains all the data about the Workflow Instance.

NodeVar - Contains all the data about a Node(service) in the Workflow Instance.

NodeStatus - The status of a Node is encapsulated in an object so that it can be serialized and sent over the wire.

NodeCodeAssist - Should be used in the script to store any required data.

This image is a screen shot of the service package. It contains only generic interfaces defining what a service must/should do.

 Package : ngin.service

Interfaces :
IService : The super interface all services must implement.

IServiceCallback : The super interface a class must implement to handle the requests made by the service.

IServiceDescription : The super interface which describes an Ngin service.

This image is a screen shot of the space package. As told previously, Ngin acts a mediator between services participating in the Workflow Instance. So, this facilitates a loosely coupled architecture between ngin services. ngin does this by storing the data sent by a service in JavaSpace. Other services can at a later stage use this data, thus facilitating data exchange between disparate, distributed ngin services.The data exchanged between JWorkFlow services are encapsulated in a Message/FullMessage object. The access to JavaSpaceis handled through transactions.

 Package : ngin.space

 Classes :
Message: Ngin services can exchange 2 types of services. This is one type where they can exchange a Boolean, an Integer, a Float and a String.

FullMessage : This includes a Message object and a Marshalled object, which can practically contain anything, as it is just a byte stream with the URL of the class definition annotated along with the byte stream.

MessageEntry : The localengine stores the data exchanged between the Ngin services into JavaSpaceas this  class which encapsulates both the Message part and the Marshalledobject(if it is a FullMessage, null otherwise).

Space and SpaceTxnFinder : Two helper classes which access and manage the JavaSpace and the Mahalo Transaction Manager.

This image is a screen shot of the communication package. This package will replicate the main package structure of localengine and service. For each communication protocol used by the Ngin services, a corresponding sub package will exist in the communication package.

Package : ngin.communication.localengine

Class:
 ServiceFinder - Uses the ngin.service.IServiceDescription super interface to query which service has to be contacted. But first it finds out if there is a package already deployed and loaded which can speak the required  protocol. If not, it tries to dynamically load the communication package from the URL specified. Thus  facilitating hot deployment of communication packages.
 

Package : ngin.communication.localengine.jini

Important Classes :
 Jini_ServiceManager : The most important class of this package. It is designed so that the Jini Services and Jini ServiceRegistrars are cached and even looked up in advance. This saves a lot  of time for subsequent requests for the Jini services.

Jini_ServiceDiscoveryManager : This class is a replacement for the ServiceDiscoverManager provided by the Jini package. It allows a more customized lookup for multiple Jini services. I had to write this class as the ServiceDiscoveryManager somehow failed to work on my comp.

This image is a screen shot of the util package. This class contains a number of miscellaneous utilities like a threadpool and an objectpool. The objectpool has not been used in the existing system. But I thought it'd be useful sometime later. So I wrote it.

Package : ngin.util.logging

Classes : JWF_FileHandler - Writes log messages into a specified directory, under a specified file name. This class is a modified  version of Brian Gilstrap's Lunmberjack logging utility for JDK's older that 1.4