Cormorant is a library of useful routines for creating DHI servers as well as example servers that use a DHI-specific database schema. Cormorant allows creators of new DHI servers to concentrate on the mapping from their database to the DHI objects and to worry less with the details of Corba and the Naming Service.
A tar or zip file with scripts and all needed jars can be downloaded here. The JavaDocs for the latest release of cormorant can be browsed here. You may also be interested in the source as it stands in CVS, which you can get from Fisheye, our CVS viewer.
While Cormorant cannot help with the implementation of the actual server to database interaction, it can make the other details of server creation easier. First, create a controller class that will create your server Impl and handle any internal setup. It should extend edu.sc.seis.cormorant.AbstractController. It must have a constructor that takes Properties confProps, String serverPropName, ORB orb as its arguments. There should also be a public abstract Servant getServant() method that returns your Impl object.
This class will be loaded dynamically via reflection based on a properties file passed into cormorant with a -props command line argument. The property file should contain at a minimum the following four properties, where myserver is replaced by whatever name you wish to use.
cormorant.servers=myserver cormorant.servers.myserver.controller=edu.mypackage.MyServerController cormorant.servers.myserver.name=myServer cormorant.servers.myserver.dns=edu/mydns
The first property gives the key that is used to load the rest of the properties. This can be a comma delimited list as cormorant has the ability to start more than one server in the same process, but we currently recommend separate processes for each server. The controller property specifies the name of your Controller class, which should extend AbstractController. The name and dns properties specify the server name and server dns that will be used to register it with the name service. You will likely also want to set the edu.sc.seis.fissuresUtil.nameServiceCorbaLoc and possibly edu.sc.seis.fissuresUtil.additionalNameServiceCorbaLoc properties so that the name service can be easily resolved. The first would usually be your local name service while the second would often be the IRIS DMC's name service. Cormorant uses these to find the name service instead of the orb dependent resolve_intiial_references method.
An example server startup script is included in the scripts directory. It should be edited to add any jars that your server needs, as well as the name of the property file. At this point you should be able to run the script and have your server up and correctly registered with the naming service. Once it is up, sending a TERM signal to the process will cause comorant to unregister the server from the name service and gracefully quit. If your server needs to do something specific when starting up, override start(ORB orb, FissuresNamingService ns). To do something on shutdown override stop(ORB orb, FissuresNamingService ns). Just be sure to call super.start(orb, ns) and super.stop(orb, ns) in your methods or the name service binding and unbinding will not happen.