OpenEFM Developers Guide






Intro


OpenEFM has been built to be highly customizable. It has therefore been built using a great amount of abstraction. Each type of functionality that the EFM was designed for has been layed out in an Interface. Thus allowing any implementation of that interface to work with the rest of the system. An example of this abstraction might be the LxmlValidator, LxmlStorage, FilingTranceiver, CmsConnector, or the Filing interfaces.


OpenEFM is launched by the OpenEFMServer class. This class instantiates an OpenEFMController class which takes care of all the real work. The Controller class reads a config file ( openefm/etc/config.xml ) and instantiates instances of the interfaces based on what is specified in the config file.


In general, OpenEFM can be modified by simply implimenting an interface, then changing the config file to specify the custom class that you have written.


Controller Model


As mentioned before the OpenEFMController loads all of the necissary pieces for the EFM to operate. Specifically it load an instance of the following interfaces:


a FilingTransceiver This interface defines methods for excepting a filing from an outside source, such as HTTPS or SOAP via HTTPS.
a QueryTransceiver Currently this element in still in abstract stages. It is a place holder for the eventual construction of a Query / Response functionality based on the Query / Response standards currently under development by the Oasis Court Filing community.
a SecurityManager This interface is designed to control the authentication of filing parties. Since arrangements will have to be made between the local court and the filing parties authentication is needed. Currently this an HTTP cookie based implementation.
a CmsConnector This element handles the network connection to a CmsAdapter.
an LxmlValidator This component checks the well formedness of recieved xml and can be configured to check for specific data elements, both for existance of elements and for specific data sets. Currently only a simple implementation is used which validations all received filings against the DTD developed through the Georgia Court Atomation Commities Interoperability Pilot Project. The dtd is located at 'openefm/etc/dtds/GeorgiaCourtFiling.2001.08.08.dtd'. The validator class is located in openefm/lxml/validator/SimpleLxmlValidator.java
an AuditLogger The audit Logger is designed to record specific events that the server may encounter. Currently minimal logging is going on. Events are recorded in the standard log files.
An ID-Dispenser The ID Dispenser is used to dole out ID's used for the filings as they enter the system. The actual generation of unique ID's is done in a specific class. Currently two classes for this are in the code base, UUIDDispenser ( intended to generate guarenteed Unique ID's ) and TimestampIDDispenser. The IDFactory class loads a Dispenser class and in currently setup to load the TimestampIDDispenser class.


Common Customizations
The most common areas of customization are most likely in the LxmlValidator and possibly with other areas such as ID-Dispensor and CmsConnection.

LxmlValidator
The interface that defines an LxmlValidator is located at

'openefm/src/com/counterclaim/lxml/validator/LxmlValidator.java'.

A simple implementation has been provided at

'openefm/src/com/counterclaim/lxml/validator/SimpleLxmlValidator.java'.

This simple validator mearly checks for well-formedness of the filing and makes sure that it validates against a specified DTD. The most common change here might be the inclusion of a different DTD to validate against. This could be accomplished by placing the DTD in accessable directory, ( we use 'openefm/etc/dtds' ), and the dtdFile attribute in the lxml-validator element of the config.xml file located in 'openefm/etc'.

Another common change to the lxml validator might be to check for specific data elements and and values in the xml filing. This could be easily accomplished in a number of ways. Most likely the easiest solution would be to add some custom XPath queries to the end of the validateFiling(LxmlFiling filing) method in SimpleLxmlValidator.java. This can be easily accomplished since the LxmlFiling class handles XPath queries.

However, if one had a need, a new LxmlValidator class could be written that extends the interface and used in it's place. The new class would need to be specified in the openefm/etc/conf.xml file's lxml-validator element.


The CmsAdapter ( The last mile )
The CmsAdapter is the piece of code that actually enters data into the court's CMS. This is expected to be implemented on the CMS's side. We provide interfaces to implement for a SOAP connection or for a Java RMI connection.
Jim Beard
Last modified: Tue Jun 25 15:08:38 PDT 2002