On Sat, May 17, 2008 at 11:20 PM, Sanjiva Weerawarana <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: >> >> On Wed, May 14, 2008 at 3:16 PM, Tammo van Lessen <[EMAIL PROTECTED]> >>> 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
