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.

Sanjiva.

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/


Mime
View raw message