COSMOSInitalPrototype

COSMOS Main Page

Proposal

The purpose of this prototype is to flush out technical details and issues as well as provide something usable that moves toward the kind of capabilities COSMOS intends to provide. The desire is also to do this quickly and iteratively so there is continuous value.

TPTP provides some basic similar uses cases but does not have a robust and scalable data storage systems or a web-oriented user interface. This is why TPTP has committed to resolve its scalability issues in the 4.4 release (part of Europa in June 07) and do it in collaboration with COSMOS. The end goal is to make the data and data collectors sharable between the projects in order to support life cycle use cases that span the target user types of each project.

The proposal for the first step is to leverage the TPTP data collectors for statistical, trace and log data (in that order) and store the data via a COSMOS isolation API layer. Storage can in fact initially be in the existing TPTP EMF models, although clearly this is not the end game for COSMOS. BIRT and web-based UI can access this data via a new COSMOS api, thus maintaining storage system isolation and driving the COSMOS architectural intent.

One key part of COSMOS is to be able to observe the "Data Center" and initially via user interaction select nodes in the system for observation. In TPTP this would be done by acting on the "hierarchy" model which captures a group of machines with processes and data collectors on them. In this prototype the hierarchy model could be replaced by a data center model that eventually would be SML-based. Initially this could simply be reuse of the SML-IF sample we have seen.

This prototype would let COSMOS quickly string together all of its sub-components along with TPTP use cases and begin to show its unique value-add as well as places for collaboration with TPTP, etc. Once this proof of concept is working each of the architectural areas of COSMOS can begin to evolve in parallel.

In order to protect the user community COSMOS would not provide any "API" in Eclipse terms at this time, in order that everything can be replaced as needed going forward.

A few iterations of this prototype could be demo-ready by EclipseCon time frame.

User flow(s)

Initially the user has a browser-based visualization of a network topology. One logical view provides a tree-style decomposition of an enterprise system, perhaps known as the sales system. The sales system can be viewed as a network of large-grained software components that are contained/serviced by a system unit. Each system unit and each software unit can be selected, and a number of possible statistical or health indicators/measurements can be selected for viewing. Each indicator can be turned on or off, and if there is data available it is shown. Initially this prototype will require the user to have manually entered and described each node that is visible, along with any connection information needed to control the data collection. It will have to be determined how many units can be viewed and if the views are aggregated or not.

This is all the user can do: - describe a network of software and hardware components - look at some specific logical views of an application stack - turn data collection on and off - view the data based on a selectable time scale other than current

A Plan That I Think Can Work

I (Oliver) had an action item to try and drive towards a concrete proposal. Herein, I summarize where I think the conversations have been going. Am I way off base?

We start with the premise that if no one uses our COSMOS stuff, then we might as well not have written it. We also start with some good "management" technologies already in tptp (CBE, JMX, ARM and WSDM). These are good "management" technologies, all agree, so why aren't they in use? So let's start by making them used.

All things considered, the appropriate "market" for our software is developers. The 4 management technologies are targeted to production systems, but realistically, we will not get any users in the production space. So, let's go after developers for our first iteration.

So here is the use case that I think can be demonstrated by eclipsecon (with OCS doing a lot of the major lifting). It reuses a lot of tptp stuff. We have discussed this before in our various calls. I use the term BTM as the main function to be performed, ignoring exactly what software is tptp vs COSMOS at this point.

In summary, the demonstration will do an end-to-end use case for the developer using CBE for an SML application. It eliminates many of the steps currently involved to insert log statements in the application, finding the existing log files and viewing the results. Why CBE? This is open for debate, but to me, it seems the easiest thing to get people using ASAP. Specifically, much software out there already produces logs (consumable by tptp CBE) and everyone is quite used to low-tech logging so adoption should not be too much of a problem.

1. Developer invokes SML viewer to examine the SML for the system that he will be working with (perhaps debugging, testing, performance tuning).
   1. Is there a specific BTM SML viewer? I am assuming that functions other than BTM will want to view and use the SML description.
   2. This viewer can be quite primitive in the demonstration, since the demonstration will be only against known elements (TomCat so far).
2. The Developer sees that TomCat is highlighted (because BTM knows about TomCat). Gee (sez developer to self), I am in luck, I want to do some development of some code that is running on TomCat, I will "choose" TomCat and see what happens, and he clicks on TomCat.
   1. I think we already agreed that TomCat was an appropriate target for the demonstration. Vsevold here at OCS wants to add MySQL too.....
3. Now, BTM knows TomCat is the resource to be monitored. BTM knows that the tptp log viewer is available for TomCat and highlights the tptp log viewer. The user chooses the tptp log monitor. (Someday, there will be others...)
   1. At this point BTM knows that tptp log viewer is the voyeur and TomCat is the voyee.
   2. I bet I am never again allowed to use those words.
4. BTM puts up a screen giving the user options as to what BTM can do with this combo: TomCat and tptp log viewer.
   1. As it turns out, TomCat produces a log file. One of the choices BTM should provide is to enable the logging in TomCat. The user should not have to be concerned with what configuration switches need to be set, or where the log file goes. Just turn it on.
   2. There will likely be some additional useful "CBE probes" provided by BTM that can be chosen by the user. Perhaps we have some COSMOS-specific ones and BTM can just add those (at the users behest) without the user being aware that they are probes. They are just additional monitoring points.
   3. The BTM screen should also allow for the user to insert CBE "log" statements into various places in the source code.
5. Now that configuration is complete, user runs the application. BTM should have taken care of all the nitty gritty issues so that the user can just run the application normally.
6. During the application run, the user can bring up the tptp log viewer, click refresh, and the log(s) are automatically collected and displayed.
7. It is likely that the user will want to add and subtract CBE log statements in a quick iterative fashion and the workflow should suport this.

Bold text