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 Sun, 18 May 2008 21:43:05 GMT
On Sat, May 17, 2008 at 11:20 PM, Sanjiva Weerawarana <sanjiva@opensource.lk>
wrote:

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


4.0 and 5.0 has support or PUT, DELETE, even OPTIONS and HEAD.  Those were
added back in 2003 [1], are standard fair in 6.0, and if you believe their
CTO[2] will remain in WebSphere indefinitely.

Assaf

[1]
http://publib.boulder.ibm.com/infocenter/wasinfo/v4r0/index.jsp?topic=/com.ibm.support.was40.doc/html/Plug_in/swg21145705.html
[2]
http://searchsoa.techtarget.com/news/interview/0,289202,sid26_gci1257544,00.html



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


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

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