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
