Configuration

Java Properties objects are the foundation for configuration throughout the library. The Configurable interface marks its implementers as being able to be configured using a properties object. As Properties only supports string values, a JavaProperties class provides a facade onto a properties object with Java type specific access methods.

ClassPathConfiguration is a singleton which can load properties files (note, with the suffix .conf rather than .properties) from the class path, either for a name or specific class.

Datasets

Embedded HTTP

Embedded JavaScript

Java Messaging

This package provides two closely cooperating classes for using JMS topics. The JMSSession singleton handles all the connectivity with the JMS provider, and is also a factory for making and keeping JMSTopic objects. Each JMSTopic provides a single point for subscribing, publishing and requesting messages over a topic.

The package uses a JMS correlation id scheme which allows both requests and responses over the same JMS topic.

An example implementation with these classes. Get the session singleton and configure it with properties. Then open the session.

public void begin() {
    JMSSession jms = JMSSession.getInstance();
    jms.configure(this.properties);
    jms.open();
}

The properties need to contain slightly more than with the http package. Here is an example for Fiorano;

#
# JMS provider configuration.
#
java.naming.security.principal    = anonymous
java.naming.security.credentials  = anonymous
java.naming.provider.url          = http://localhost:1856
java.naming.factory.initial       = fiorano.jms.runtime.naming.FioranoInitialContextFactory
#
# Session configuration.
#
connection.factory                = PrimaryTCF

Once the session is open, add any subscribers (implementors of the JMS MessageListener interface) for topics using the JMSTopic class, then start receiving messages.

public void subscribe() {
    JMSSession jms = JMSSession.getInstance();
    JMSTopic ticker = jms.getTopic("ticker");
    ticker.subscribe(new TickerListener(this));
    jms.startReceiving();
}

Each JMS topic should have the message time to live and priority configured in the same JMS properties as above. For example, with the 'ticker' topic;

#
# TICKER topic configuration.
#
ticker.time.to.live = 60000
ticker.priority     = 4

The JMSTopic instances provide publishing and requesting methods as well;

public void publish() {
    JMSTopic ticker = JMSSession.getInstance().getTopic("ticker");
    MapMessage msg = ticker.makeMapMessage();
    ...
    ticker.publish(msg);
}

public void request() {
    JMSTopic ticker = JMSSession.getInstance().getTopic("ticker");
    MapMessage request = ticker.makeMapMessage();
    ...
    MapMessage reply = ticker.request(request);
}

Java logging

The decision on logging was difficult not because it is controversial - the library uses logging to advise on all status and exceptions - but because of preferences in the underlying logging package. I have used log4j and will doubtless extend the library logging package to use it; but for now this package is a simple implementation of Java logging.

Maths

The maths package principally contains classes oriented towards finance, including a Black-Scholes options model. Subpackages also define a range of average price calculators (simple and exponential moving averages, plus VWAP and TWAP); and stock price models.

Multicasting

The multicast package implements a framework for multicasting which is similar to JMS. A MulticastSession class defines the IP address and character conversion for the session, plus methods for sending multicast packets using a given protocol. The .etc package defines two such protocols: an elementary protocol and another, MulticastSessionProtocol which prevents published packets from being received by an observer with the same session id.

Some of the Gamma, Helm, Johnson and Vlissides design patterns - and others

Of course, the prime reference for this is the Design Patterns book (ISBN 0-201-63361-2). I have followed the naming conventions of the authors wherever possible. Some of the patterns are simply marker interfaces, for example those for Singleton and Visitor. The memento pattern is more elaborate, as there are interfaces for both the Memento and the MementoOriginator. The Memento interface also allows for an (optional) persistence mechanism using byte arrays.

One pattern that is not in Design Patterns is closure. I was introduced to this by Mark Chaplin and have persisted with it because of its benefits. The principle of closures is that a class owning a collection of objects does not expose an iterator on that collection but instead implements methods which allow a visitor-like class to see each member in the collection. The advantages are that the owner keeps control over synchronisation, casting and the sequence and selection for the iteration: the exposed methods are much like a query language on the collection. The downside (for some) is that the implementation of the visitor usually requires inner classes.

For example; a closure on some class ...

public interface ThingClosure extends Closure {
    public void visit(Thing thing);
}

... with some things owned by another class ...

public class ThingOwner {

    private Thing[] things;

    public void forEachOddThing(ThingClosure closure) {
        for (int i = 0; i < this.things.length; i += 2) {
            closure.visit(things[i]);
        }
    }

}

... and an application which needs to see these things.

public class Application {

    private ThingOwner owner;

    public void execute() {
        this.owner.forEachOddThing(new ThingClosure() {
            public void visit(Thing thing) {
                //do something
            }
        });
    }

}

The util package

This package contains some classes with useful methods for dealing with byte arrays, Bytes, and strings, Strings. There is also a text formatting class and a Java Date equivalent for universal time, UTC.