+1 to Alex's suggestions.
I like #3, too, especially given the prevalence of JSON libraries and
APIs. (So far, I've liked all of the JSON APIs that I've worked
with...) As much introspection as we can offer is going to help
people get a handle on what's going on.
-- Paul
On May 13, 2008, at 8:20 AM, Alex Boisvert wrote:
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
Paul Brown
[EMAIL PROTECTED]
