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
