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