ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: [gsoc] Monitoring Console / Architecture
Date Tue, 13 May 2008 19:30:45 GMT
On Tue, May 13, 2008 at 11:53 AM, Matthieu Riou <matthieu@offthelip.org>
wrote:

> 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.


Indeed, because the capacity to add unnecessary abstractions is infinite.
 But unless it can only be seen as a feed, what's the benefit?


> 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.


Yes, but I'm not convinced rendering a JSON feed would do our end-users any
good.  Anyone interested in reading JSON?

Most people would prefer a nicely styled HTML page, so now that JSON has to
be converted into HTML on the client-side.  Or you could just send HTML
directly from the server (for the buzzword inclined, it's called AJAH).

Assaf


>
>
> 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
> >
>



-- 
CTO, Intalio
http://www.intalio.com

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