The wiki page appears to be "immutable", so I'll throw in my additional ideas and thoughts,
1. Management * Delete instance(s) * Terminate instance(s) 2. Monitoring I think some of the metrics are not currently supported in the PM API (e.g. number of messages sent/received). So we're looking into extending the query capabilities? IMO, the process instance explorer is probably what people want most at first. Metrics are very useful once you've got your processes running, but getting there can be painful. I would try to invest as much as possible in the debugging features first, then proceed to metrics after that. (This is just my intuition; I'd be happy to hear otherwise) alex On Tue, May 13, 2008 at 6:48 AM, Tammo van Lessen <[EMAIL PROTECTED]> wrote: > Hi all, > > Milinda and I had a little chat about the architecture of the monitoring > console last week and decided to move the topic to [EMAIL PROTECTED] to raise > a > discussion on that to gather more feedback. Once we have an agreement I will > put it to the wikipage at [1]. > > First a bit on the requirements. What I have in mind: The console should > be a replacement for the web console currently shipped with Ode's Axis2 > deployment which is actually the one that comes with Axis2. It should > provide a dashboard-like landing page which shows some interesting metrics > like the ones identified at [1]. These metrics should be unobtrusively > updated via AJAX requests. Additionally, process models and their instances > should be monitorable, i.e. should have a page in the management console > displaying the metrics specific for a certain process model or instance and > allows for management functionalities like activate/deactivate/retire for > models and suspend/resume for instances. > Additionally the deployment of process models (as zip files) should be > supported). > > A nice-to-have feature is a BPEL debugger that allows for > displaying/editing variable values, ideally in a graphical notation. This is > most probably out of scope. > > Regarding the architecture, the most important part is probably how to > integrate the web console with Ode. There are different possible solutions, > let me sketch 3 of them: > > 1) The console is mostly JS-based, the interaction is via WSO2's > WSRequest object, i.e. SOAP/HTTP calls to ODE's management interface > > 2) The console is mostly JS-based, the interaction is via Ajax GET > requests to specific servlet, which serves the requested data as JSON > objects. The management interaction is a) also via JSON or b) via SOAP to > the management interface. > > 3) RESTful interface, modeling the landing page, process models and > process instances as resources with (at least) two content types (aka > representations), namely HTML and JSON where the HTML variant already > contains the JS/Ajax logic to update pages with JSON requests. Management > functionalities could be modeled as PUT requests for existing resources or > as POST for deployment... > > I'm actually in favor for 2) and 3) as I doubt that 1) will scale very > well. Although it is probably possible to create small-footprint services > for the monitoring stuff (i.e. services that don't calculate the metrics for > each call but rather deliver them), I think the cacheable and idempotent > nature of HTTP GET requests is more appropriate for this kind of polling. > > Regarding option 3 I like the idea to model a collection of process models > as resources, which process instances as child resources with different > states and different representations and I think it a very good use case for > a resource-oriented accessing schema (while having in mind that the > WS-star-ish management console is already available). > > So far my 2 cents. Any comments, objections? Discussion is more than > welcome :) > > Cheers, > Tammo > > [1] > http://wiki.apache.org/general/MilindaLakmal/ApacheODEAJAXBasedMonitoringConsole/Requirements >
