I would also tend toward #3, preferably using an existing server-side framework that supports AJAX/Comet and good JavaScript integration (e.g. JQuery, JSON) so most of the work can be focussed on building better management interfaces for Ode rather than reinventing the web tier. I think it's worth exposing process models, instances, events, ... using REST since it will also make integration with other web applications easier.
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 >
