On Tue, May 13, 2008 at 11:53 AM, Matthieu Riou <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > 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 > > > -- CTO, Intalio http://www.intalio.com
