Hi, I'm Mario and I work with Nando and Gonzalo. I'm kinda-sorta the architect of this whole mess we're working on and currently the lead of the front-end development team.
Nando's posting is an excellent summary of what we're doing. I would like to add, regarding the real-time posting of the workitems to the client, that we're evaluating using COMET vs. XMPP. On the one hand, COMET would allow us to: * use a single connection for everything * have a single process running on the server * make it easier in the future to have a web client for this kind of real-time notifications On the other hand, XMPP would give us: * more implementation independence (as in MRI vs. JRuby vs. IronRuby vs....) * use XMPP for other kinds of notifications we might need to send to the client * give us an asynchronous channel in case we need that at some point The main problem I see with using XMPP is having to maintain another server process with its infrastructure, plus having to use a separate connection. Any input in this regard would be greatly appreciated. Cheers! -Mario. On Apr 6, 9:05 pm, Nando <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
