Dashboard > Data Handling Interface > ... > DHI 2 > Implementing DHI2 Servers with Cormorant
  Data Handling Interface Log In | Sign Up   View a printable version of the current page.  
  Implementing DHI2 Servers with Cormorant
Added by Philip Crotwell, last edited by Charlie Groves on Jun 29, 2006  (view change)
Labels: 
(None)

Cormorant is a server harness for DHI servers. Version 2 of cormorant goes a step beyond the basics of corba initialization to separate the corba configuration and setup from the database access. This should make it easier to implement new instances of DHI2 servers on different databases by allowing full reuse of the cormorant corba setup. By providing a strong separation between the ORB, POA and other corba specific items on one hand, and the data access interfaces on the other, server implementors are able to concentrate on the specifics of their database and the mapping into fissures objects without the complication of also learning the details of corba servers.

For each server type in DHI2, Cormorant provides "Internal" interfaces that follow the DHI IDL interfaces, but are simplified where possible. So, for example, the queryEvents method in EventDC returns an array of Origins as well as an origin iterator, which is a corba object that must be registered with the ORB and POA. In the InternalEventDC interface, the return is type is a OriginSeqIterOperations. This is a straight Java interface, and Cormorant takes care of calling next() on on this iterator to get the first set.

The Internal interfaces are:

The rest of the source code for Cormorant can be found here. Those wishing to see what Cormorant does internally should start by looking at the abstract controllers for each server type.

EventDC

  1. create a class that extends AbstractEventController
  2. implement the methods in InternalEventDC
  3. Write a props file per the general Cormorant instructions for starting a server.

An example mock implementation can be seen in MockEventController.

SeismogramDC

  1. create a class that extends AbstractSeismogramController.
  2. Implement the methods in InternalSeismogramDC
  3. Write a props file per the general Cormorant instructions for starting a server.

An example mock implementation can be seen in MockSeismogramController.

NetworkDC

  1. create a class that extends AbstractNetworkController.
  2. Implement the methods in InternalNetworkDC
    and InternalNetworkAccess
  3. Create a props file per the general Cormorant instructions for starting a server.

An example mock implementation can be seen in MockNetworkController.

General Cormorant Startup

Cormorant relies on a properties file to set general configuration items, as well as to tell it which class that it should start up and register to the worldmock.prop starts the mock servers metioned above. It registers servers
with the main IRIS nameserver under the edu/sc/seis/internal name context. You should change the name service to use a local name server for testing purposes.

Once you have the properties set up, you would run cormorant with -p myconfig.prop.

Site powered by a free Open Source Project / Non-profit License (more) of Confluence - the Enterprise wiki.
Learn more or evaluate Confluence for your organisation.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request - Contact Administrators