ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: [gsoc] Monitoring Console / Architecture
Date Tue, 13 May 2008 18:53:26 GMT
What Alex and Assaf say.

I'm also in favor of #3 although I don't know if that can fit in the GSoC
timeframe. Revamping the management API as a RESTful interface would take
some additional time.

For the API, we could represent process and instance lists as Atom feeds,
Abdera could help us get there quickly. There would only be a few additional
resources needed for global stats and such but most of the information would
be in the feeds. When you come down to it, there's not much that can't be
seen as a feed. And for the XML allergic (count me in) I Abdera has a JSON
representation as well.

Then for the view, I'm sure there are some JS Atom readers that would also
help a lot (I know JFeed for JQuery, dunno if there's one for prototype). So
standardizing on Atom would also help us there. Everybody knows how to
render an Atom feed these days.

Matthieu

On Tue, May 13, 2008 at 11:33 AM, Assaf Arkin <arkin@intalio.com> wrote:

> 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 definitely prefer REST, you get more mileage out of that.
>
> Do not mix the programmable Web interfaces (API) with the user interface
> (UI).  It's tempting because it's possible, but turns out to be not such a
> good idea (speaking from experience).
>
> Keeping the API resources separate from UI resources make the API easier
> to
> version, you don't want changes to the UI breaking the API and vice versa.
>
> If you keep the API to simple and straightforward data structures you can
> serve both JSON and XML, and when necessary other content types like Atom,
> iCal, etc.  Just stay away from excessive use of namespaces and complex
> content models, and you can have data that translates nicely to a lot of
> different representations, depending on the client needs.  Easiest way to
> do
> this: start with a simple abstract data model and avoid premature
> XML-ization; if your spec is defined in terms of XML elements and
> attributes, you're heading in the wrong direction.
>
> Do not confuse JSON and sending partial page updates as JavaScript.  Those
> are two separate things.  JSON is just data, content model would be
> application/json, and it belongs in the API.  Partial page updates is
> code,
> content model would be application/javascript, and it's tightly bound to
> the
> rest of the UI.
>
> Also, keep these partial updates on separate resources from HTML or the
> API,
> otherwise, client-side caching will bring some interesting surprises.
>
> We can do the UI and API side by side, but worth considering is building a
> UI as one tier that then uses the API.  That way you're starting with at
> least one client, it's easier to make sure the API is simple, functional
> and
> complete.
>
> Assaf
>
>
>
>
> >
> >
> > 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
> >
>
>
>
> --
> CTO, Intalio
> http://www.intalio.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message