ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ritz Bossicard <vladi...@ritz-bossicard.com>
Subject Re: [gsoc] Monitoring Console / Architecture
Date Wed, 14 May 2008 06:23:06 GMT

I've been listening to the conversation and I would like to make a 
suggestion.  If it is completely off-topic, please just disregard it.

Why not exposing ODE's various management functionalities via JMX?  The 
Monitoring Console would simply be a web based JMX console (similar to 
JManage) with the latest-greatest Web 2.0 technologies.

I see several advantages:
   * the project can be split into two: 1) JMX interface for ODE 2) JMX 
management web application; Potentially 2 different students could 
tackle the tasks
   * the JMX management console could also be used by other projects 
since it wouldn't be ODE specific

Again, since I don't know ODE's architecture very well, these remarks 
may simply not apply.

Best regards,


> +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 <tvanlessen@gmail.com>
>> 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 dev@ode 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
> paulrbrown@gmail.com

View raw message