NcML AIS: Build a BES Handler: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
No edit summary
Line 9: Line 9:


==Explanation of the Classes in the Diagram==
==Explanation of the Classes in the Diagram==
===Basic operation of the BES Framework===
The BES is a daemon that waits for connections and, when one is detected, reads the commands and executes the appropriate methods in either the BES framework or one of the handlers that are loaded into the BES during initialization. In a very general sense, the BES follows this workflow:
* Parse the command associate with the current request
* Decide which handler should be used to satisfy the request
* Use the handler to build a response
* Return the response
It's possible to define new commands and new ways of transmitting data for various protocols, but those uses of the BES are beyond what a simple data handler that works with Hyrax needs. A data handler to be used with Hyrax that only needs to support the basic BES command (e.g., ''show version''), the DAP commands and return responses using HTTP, does not need to specialize the command set, the response types or the transmitter classes.
===Classes that are Provided===
===Classes that must be Specialized===
===BES Framework Singleton Objects===
===Putting it all Together===

Revision as of 21:22, 17 April 2009

Back: AIS Using NcML

A UML Class diagram for a Simple BES Handler

There are several ways to build a shell BES handler and then add specific functionality to it. One way is to use the besCreadeModule script that is included in the BES source code. A second way is to copy and modify the csv handler software that's also included in the BES source code. In each case it's important to know that the BES is an object-oriented framework and as such, you will be specializing classes that the framework defines and then adding new classes and/or functions that are specific to your handler. With that in mind a static class diagram can help show how the BES's classes are related to each other and to the software you must write. Shown to the left is a UML class diagram that includes the most important of the BES classes when writing a new data handler.

A high resolution version of the class diagram to the right.

Also, be sure to look over hte BES documentation files included on this design's main page and on in the Hyrax documentation. Especially useful is the BES Handler tutorial that covers building the Hello, World and CSV handlers. It's so useful I'll repeat it here: Extending the OLFS: Writing Custom Dispatch Handlers.

Explanation of the Classes in the Diagram

Basic operation of the BES Framework

The BES is a daemon that waits for connections and, when one is detected, reads the commands and executes the appropriate methods in either the BES framework or one of the handlers that are loaded into the BES during initialization. In a very general sense, the BES follows this workflow:

  • Parse the command associate with the current request
  • Decide which handler should be used to satisfy the request
  • Use the handler to build a response
  • Return the response

It's possible to define new commands and new ways of transmitting data for various protocols, but those uses of the BES are beyond what a simple data handler that works with Hyrax needs. A data handler to be used with Hyrax that only needs to support the basic BES command (e.g., show version), the DAP commands and return responses using HTTP, does not need to specialize the command set, the response types or the transmitter classes.

Classes that are Provided

Classes that must be Specialized

BES Framework Singleton Objects

Putting it all Together