The main goal of the Elk Framework project is to create an application framework that provides the services needed by a JDF Device or Controller. The framework is implemented in Java and is based on CIP4's open source JDF Java SDK JDFLib-J.
A sub-goal of the project is to create a reference implementation of the Elk Framework. The hope is that the reference implementation will be able to serve as a test tool and a starting point for others wishing to implement a JDF enabled system.
This project is a work in progress. Any input or contributions are welcome.
The Elk Framework consists of a number of classes that specify the services needed by a device or Controller. The class diagram below gives an overview of the most important classes in the Elk Framework. These are the classes that you would implement if you wanted to create your own implementation of the Elk Framework. The JavaDocs give detailed descriptions of all classes in the diagram.
The packageorg.cip4.elk.jmf defines classes for
handling JMF messages. JMFProcessors are registered
with the IncomingJMFDispatcher that dispatches
incoming JMF messages to the processors. The
OutgoingJMFDispatcher dispatches JMF messages
to other devices or controllers. The
SubscriptionManager is responsible for registering
subscriptions and sending JMF Signals to the
subscribers.
The class org.cip4.elk.queue.Queue represents a job
queue. The class
org.cip4.elk.device.process.Process represents a
device's process, the part of the device that executes
JDF and controls and underlying machine.
The class org.cip4.elk.JDFElementFactory is a
convenient way of creating new JDF elements.
The class org.cip4.elk.Config represents the
configuration of a device or controller. It is usually loaded at
startup and passed to the main components of a
device/controller, for example the Queue or
Process.
The Elk reference implementation is an implementation of the classes specified by the Elk Framework. The reference implementation is a JDF Device that implements the Approval process specified by the JDF specification, 6.2.1 Approval. The reference implementation is implemented as a web application that is deployed in a servlet container such as Jakarta Tomcat.
The UML deployment diagram below describes the components that the reference device web application consists of:
IncomingJMFDispatcher, described in section
3.2 below.
This servlet is for testing JMF clients that post MIME packages and is not connected with the reference device in any way. It is included for test purposes.
This servlet logs all JMF messages it receives and generates a generic response. It is not part of the reference device but is included for testing purposes. For example, it can be used for testing that the reference device registers subscriptions and sends Signals correctly by registering this servlets URL as the subscriber's URL.
The UML class diagram below shows the reference device's
concrete implementations of the Elk Framework's classes for
JMF message routing. The device has a servlet
DispatchingJMFServlet that handles all
incoming messages. The servlet delegates the incoming
messages to an IncomingJMFDispatcher that in
turn dispatches messages to message handlers,
JMFProcessors. The dispatcher also looks
for subscriptions in each message and registers any
subscriptions with the SubscriptionManager. The
SubscriptionManager listens for events from
the device's Queue and Process.
When it receives an event it dispatches Signals
using the OutgoingJMFDispatcher.
MemoryQueue is
completely abstracted from all JMF message processing which
is instead done by a number of JMFProcessors.
Each JMFProcessor handles a different type of
queue-related JMF command/query. The queue listens to status
changes in the reference device's Process by
implementing ProcessStatusListener.
The reference device's process ApprovalProcess
has a reference to the queue which it polls for new jobs to
execute.