The framework code and the initial versions of the TPTP GLA adapter and Agent Controller adapter have been checked in so anyone who is interested can find the code in CVS under data-collection/org.eclipse.cosmos.dc.tptp.gla.components. We deferred an in depth discussion of the framework code and its setup and build instructions due to the absence of key individuals. Contact Joel with any questions. Marius has a working build that he intends to check in soon so he should be able to help with build issues.
Query Interface
The early consensus was that we did not have a quorum to discuss the detailed architecture of the query framework (although several attendees joined somewhat later) so we chose to skip ahead in the agenda and focus on the usage of SML in the end to end scenario.
SML
We discussed several aspects of the role of SML in COSMOS. It was agreed that there would be several types of SML documents and that there would be linkages between them, but we are not yet able to describe the structure of some of these inter-document dependencies and the structure of the repository. Among the types of information that need to be modeled are:
Topology of the monitored infrastructure
Details of each monitored hardware or software component
Agent capabilities
Monitorable and monitored data items (are these associated with an agent or a component or both?)
We discussed how the reporting system would find the SML documents. Craig anticipated that the application should be able to browse the file system for SML documents. It is less clear how a customer would choose a particular one but we agreed that selecting a file with a descriptive name from a hard coded directory would be sufficient for June. Valentina confirmed that the current approach in COSMOS is to browse the file system for SML-IF documents, but that an adopter could use a database or other scheme. She also explained her proposal that reporting would be done by generating an SML-IF document on demand to drive the BIRT reporting.
We discussed the use of SML throughout the end to end scenario and came to the conclusion that there are a lot of details that are unclear at this point. For example, the data reporting component should be able to associate the components of the monitored infrastructure with their models and should be able to understand the semantics of the collected data in light of the model. What is less clear is how this is done. For example, are the observable characterstics of the monitored object properties of the object or of the agent that could monitor the object? How does the persistence framework retain knowledge about the models that are relevant to the collected data so it can be queried by the reporting component?
