First off, let me explain a bit about our current project. We work for
a start-up that develops products for the international commerce
sector. Our original plan was to use OpenESB, but after a while we
came back to our senses and fled SOA and BPEL. We wanted something
simple, developer-friendly and RESTful. So after investigating for a
while, we found ruote and route-rest. During the past three months,
we've been adapting both of them to meet our needs.
So our feedback on ruote-kit is somewhat intertwined with the little
changes we made to ruote itself. Plus some remarks and notes about our
concerns. Again, we can provide code, extra hands and further
discussion about each and every topic below. Some of them are part of
a work in progress.
* JRuby-friendly.
With some minor tweaking, ruote-rest works well with JRuby 1.2. We
have to make sure that ruote/ruote-kit are 100% JRuby-compatible.
* Easily deployable within Glassfishv3/Tomcat/Jetty/...
ruote-rest works like a charm within any modern servlet container via
JRuby-Rack. The only quirk is stopping the app ($rr.engine.stop) -
AFAIK, it has to be done using the server's life-cycle Java API.
* Use HTTPS as a much needed envelope to Auth:Basic.
Either go for Apache/Mongrel or use a servlet container, which would
take care of the SSL stuff.
* Our front-end guys are working on a swing-based heavy client which
relies on a clean, stateless REST interface to ruote-rest. Will ruote-
kit be stateless as well?
* Centralized process-definition:
We have created a new URI
---begin snip----
GET /startables
<?xml version="1.0" encoding="UTF-8"?>
<startables count="2">
<entry>
<created_at>Wed Jan 28 10:40:19 +0100 2009</created_at>
<definition_id>1</definition_id>
<description>Add new contact to Address book</description>
<version>1.0</version>
</entry>
<entry>
<created_at>Mon Feb 02 10:40:19 +0100 2009</created_at>
<definition_id>2</definition_id>
<description>Vanilla sequence</description>
<version>1.0</version>
</entry>
</startables>
---end----
It shows all the launchable processes for any user belonging to a
given group. The next step would be:
---begin snip----
POST /processes
<process>
<definition_id>2</definition_id>
...initial field values...
</process>
---end----
There is a process_definitions table, which maps id,description,and an
URI to access the process definition. For example:
id:1 ; desc:"Add new contact to Address book"; uri:"public/
process_definitions/agenda.newContact.rb"
The URI points by default to the local filesystem, but there could be
a RESTful process definition repository, or a textfile in a webserver
The point is, that it's accesible. The client only GETs/POSTs some
ID's, never knowing about the real process definition storage. More
security.
* Comet support: it would be nice that REST clients were notified of
any changes in their workitems. We know the implementation is server-
dependent (Glassfish:Grizzly/Jetty/Ebb/Rails:Juggernaut,...), but
Jetty and Glassfish are in our roadmap. A more ruby-esque approach
could be implemented in ruote-kit as well?
* Maven/Rake: we noticed that ruote is migrating to Maven. Any plans
for route-kit?
* As for the tracker/poject mgmt tool, why Lighthouse?
* Oracle support. We can help here as well.
Hope this makes sense. I'll be expanding this thread as I discuss the
subjet with more co-workers.
Kindest regards,
//nando
--~--~---------~--~----~------------~-------~--~----~
you received this message because you are subscribed to the "ruote users" group.
to post : send email to [email protected]
to unsubscribe : send email to [email protected]
more options : http://groups.google.com/group/openwferu-users?hl=en
-~----------~----~----~----~------~----~------~--~---
