We have revamped the Pipeline framework to be extension based. That is, the functionalities of the application will be modularized, and packaged into their own extensions, which can optionally be loaded by the user as desired.

The extensions framework is based upon event processing. The application on startup bood loads the extension manager, which then in turn, loads all the extensions. The application has a set of predefined events which the extensions can post. Alternatively, each extension can post self defined events. These events are posted by each of the extensions to the extensions manager, which in turn passes them onto other extensions. Upon receiving posted events, each extension checks to see if it should process the event. If so, it will. Otherwise, the event is ignored by that extension.

Currently, these are the extensions planned

1. ExtensionManager^? - manages all extensions
2. PipelineManager^? - manages all pipelines
3. ExecutionManager^? - manages execution monitors
4. ProcessScheduler
5. LogManager^? - manages all loggers
6. UIManager - manages user interface object instances
7. a graphical user interface
8. a command line interface
9. a provenance engine
10. a validation engine
11. SecurityManager^? - manages security issues
12. NetworkManager^? - manages network connections
13. ResourceManager^? - manages resources needed by the pipelines
14. ApplicationsManager - manages applications for users
15. an AI engine
16. a data store

This design allows for extensions to be added, so long as they are aware of the edu.ucla.loni.EventListener and edu.ucla.loni.Event classes. The extensions do not need to know which other extensions are loaded (unless they intend to specifically process events posted by another extension), nor do they even need to be aware of the extensions manager.

Users: submit comments here

-- MichaelJPan - 20 Feb 2004