ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: [gsoc] Monitoring Console / Architecture
Date Sun, 18 May 2008 06:20:44 GMT
I'd suggest writing the management API in Java using a Java class and 
publishing it as either a RESTful binding (Axis2's WSDL 2.0 stuff can be 
used to do full RESTful binding) or a WS-* binding.

The message format can then be either XML or JSON .. Axis2 has a flag to 
turn on JSON.

The UI code IMO should use WSRequest because it supports everything in XHR 
and a bit more. Why is the bit more useful? WSRequest supports WS-Sec 
username token for example .. which means you can secure the management 
services with username token. There's also a way to make it support more 
of WS-Sec but that's a longer story!

I'm not a fan of using full REST here because it'll limit usability of 
Ode. For example, does WebSphere allow PUT and DELETE? I'd be surprised 
but maybe I'm wrong.


Milinda Pathirage wrote:
> Hi all,
> First of all I apologize for my late reply. Past few days I was busy with
> new key manager implementation for Apache Rampart/C and some bug fixes.
> At the beginning of this project I planned to implement a Web Services and
> AJAX based management console(Because I prefer WS-* than REST). Management
> and Monitoring API will be implemented as Web Services and AJAX requests
> used to update the UI. But now I feel that we have more things to when
> implementing web based management console.
> I think that using JSON objects will increase the responsiveness of the Web
> UI, because JavaScript understand JSON than XML(XML APIs are different from
> browser to browser).
> If we use Atom API, I think we can implement a API like Google Data API :).
> Frankly, I don't have any experience with pros and cons of these
> technologies.
> I think it's better we can first define the API in whatever the way (Web
> Services or REST) and then go for the UI. While defining API and implement
> it we can give a very basic level of Management interface by using currently
> available Web Service based API. Then we can identify the issues with the
> WS-* based API and also can discover more and more requirements.
> Please feel free to comment on this.
> Thanks
> Milinda
> On Thu, May 15, 2008 at 12:14 PM, Assaf Arkin <arkin@intalio.com> wrote:
>> On Wed, May 14, 2008 at 3:16 PM, Tammo van Lessen <tvanlessen@gmail.com>
>> wrote:
>>> Hi Assaf,
>>> Assaf Arkin wrote:
>>>> Here's four things I learned from trying to do that, which just didn't
>>>> work.
>>>>  There's more, but I think these four would be enough:
>>>> 1.  Quite early into the development you realize the UI and API are
>>>> optimized for different tasks, they quickly diverge and you end up with
>>>> components that have UI and API functionality, but they don't always
>>>> overlap.  It seems like a good idea -- reuse -- but the resulting code
>> is
>>>> unfortunately harder to maintain than keeping the two separate.
>>>> 2.  If you're coming up with a new version of the API, it's generally a
>>>> good
>>>> idea to place it elsewhere than the original version, so each version
>> gets
>>>> its own resources.  If you're coming up with a new version of the UI,
>> it's
>>>> generally a good idea to place it where the old version was, preserving
>> as
>>>> many resources as possible.
>>>> 3.  The API response to creating a new resource is 201, the UI response
>> is
>>>> 303, unless you want some JavaScript code back to render the change, in
>>>> which case it would be 200.  The URL for an API update would point to
>> the
>>>> resource you're changing (with a PUT), but the URL for a UI update would
>>>> point to a form which will then be used to make the update.
>>>> 4.  If you can request the same resource as HTML or JSON, you can
>> imagine
>>>> using one to render a full page, and the other to just pull new data and
>>>> update existing page in-place.  Except browsers don't handle Vary, so
>> the
>>>> second request would bring the cached HTML copy instead of the expected
>>>> JSON.
>>> Thanks, point taken. That it very interesting! Sounds like theory and
>>> practice aren't aligned here as well :) I should spend more time with
>>> playing with code...
>> I'm working now on a task manager for ODE, it's a sandbox project, if you
>> want to have a look at it.  Great place to experiment with some of these
>> issues, specifically because it serves both end-users and workflows, which
>> have different requirements.  And also because it will be pulled by the
>> forces of too-much AJAX on one side, and fondness for EJB/HTTP on the other
>> side.
>> Assaf
>>> Cheers,
>>>  Tammo

Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

View raw message