RAMADDA is organized around a central class ucar.unidata.repository.Repository. This class is responsible for system initialization, receipt and dispatch of incoming http requests and orchestration of the various manager components.

A key design goal of RAMADDA is to limit dependendcies from any particular web or database environment. In the future we don't know the contexts in which it might run. If we design it with core dependencies on a particular database or a particular web environment it will be very difficult to change. Furthermore, RAMADDA implements a framework, a domain specific framework for geoscience oriented content management.

The design of RAMADDA is similar to the Tomcat servlet framework in that incoming requests are defined with a Request object and the results are captured in a Result object. However, RAMADDA explicitly does not have dependencies on Tomcat or any other framework. This has been done so that it can run in a wide variety of contexts. It can run stand-alone with its own built in http server or it can run within Tomcat in a servlet context. The RepsitoryServer class (~300 LOC) is the wrapper used when running with the stand alone ucar.unidata.util.HttpServer class. The RepositoryServlet (~400 LOC) class is the wrapper when running in the Tomcat environment. The only functional difference is that some services (e.g., OpenDAP) only are available under Tomcat because of their dependencies on that framework.

There are a set of RepositoryManager classes that are responsible for different functional areas:

• DatabaseManager Handles access to the database.
• AccessManager Manages the access control to entries.
• HarvesterManager Manages the set of Harvester objects.
• MetadataManager Manages the set of MetadataHandler objects.
• StorageManager Manages storing data files to disk.
• UserManager Manages the users.
• ActionManager Used to provide asynchronous actions to browser based clients.

Initialization

The API into RAMADDA is declaratively defined with one or more api.xml files:

<api>
  <property name="admin" value="false"/>
  <property name="cancache" value="true"/>
  <group handler="repository">
      <api request="/entry/show"             method="processEntryShow"    name="Home" toplevel="true" ishome="true"/>
      <api request="/entry/show/*"           method="processEntryShow"/>
...
  </group>
  <group handler="metadatamanager">
      <api request="/metadata/list"       method="processMetadataList"/>
      <api request="/metadata/form"       method="processMetadataForm"       actions="edit"/>
...
  </group>
  <group handler="admin">
      <api request="/admin/sql"          method="adminSql"           admin="true"/>
      <api request="/admin/startstop"    method="adminDbStartStop"   admin="true"/>
...
  </group>

</api>
developer/api_dummy.xml

This file can be organized as a set of group tags that define a handler and contain a set of api. The api tag can also define a handler. The handlers are one of: usermanager, admin, harvestermanager, actionmanager, accessmanager, metadatamanager, repository.

External classes can be used as handlers by providing the full class name. These handlers need to implement RequestHandler and need to have a public constructor that takes as argument the Repository object and the xml api Element.

The api tag contains a path attribute which is used the the url path. e.g., the main way to view an entry is the "/entry/show" path. The url ends up looking like:
<repository suffix>/entry/show?id=<entry id>
The method attribute is the method name on the handler that is called. These methods have the signature:

public Result processEntryShow(Request request) throws Exception {
    ...
}

They take a Request object and return a Result object.