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