...
The central management piece for each KNSG application is KNSGFrame, an extension of BardFrame that registers tupelo utility methods for CETBeans used by the KNSG framework. In this document, we will will use the name BardFrame since our extension only overrides the method for registering beans, the rest is the same. BardFrame provides an interface for working with the Tupelo semantic content repository and is responsible for managing contexts, bean sessions, data, etc. The use of beans will be a core concept for persisting information in the KNSG framework so all beans will need to descend from CETBean. Because every application will have its own bean requirements, each KNSG application should have its own instance of BardFrame to handle this as well as an ontology to define domain specific concepts. All application bean types should register with BardFrame and the IBardFrameService should provide the correct instance of BardFrame at runtime.
Tupelo Beans
...
These are the bean classes that will be required for the KNSG framework. Where possible, the core CETBeans will be used to minimize the work required and maximize compatibility across projects. Some beans will be marked optional if they are part of PTPFlow and it is uncertain that they will be managed by Tupelo or continue to be managed by PTPFlow's current repository.
Scenario Bean
A scenario bean will be used to organize things such as user data and workflows specific to a scenario (or project). This will include datasets (input and output), workflows, and possibly the RMI service for launching jobs. A snippet of what the scenario bean might look like is below:
...