OSGi and Eclipse Make Me Smile

So, I finally did it.  After some preliminary research and a bit of procrastinating, I went all in and began to adopt the newfangled OSGi approach.  Er, maybe not so new, but new to me.

Surprisingly, everything now seems to just ... work.  After months of toiling with Eclipse trying to ensure that my classpath settings were right, and dreading every completely updating as I knew my classpath would be shredded to bits by a co-worker, the combination of some built-in plug-in development tools from Eclipse and some knowledge of OSGi have brought me to tears ... of joy.  

Anyway, a while back, somewhere between the research and procrastination, I came across a very helpful presentation that got my feet wet, and I'd recommend as a nice starting point for newcomers:

http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-1419&yr=2007&track=3

The conversion of my projects from the traditional monolithic project to the multiple modules approach was not initially fun.  I'd actually compare it to the transition from creating verb-based Web Services to RESTful Web Services, to a degree.  The presenation below goes into more detail on things related to that.

http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5122&yr=2008&track=javaee

So, tying this all into Eclipse: if you've got a fresh version, a lot of the work is done for you via the Plug-in Development Tools!  Simply take the time to appropriately fill out your Manifest information for your bundles (er, plug-in projects), create an Application using said bundles (again, it's built-in), and you're off to the races!  And one thing you've got to appreciate is work already done for you!

:)

Anyway, you can of course find Eclipse-related resources on their site, which has treated me pretty well in regard to finding information I'm looking for.  But the links above were particularly helpful for me to start from scratch and sink my teeth into OSGi.  Hope you find them useful, and feel free to submit your own references!

--
Carl Scott
Software Developer, Solertium Corporation

RESTful Client-Side tools for GWT

I guess this is more of an announcement than a blog, but I just wanted to do a quick follow up to my last blog to mention some new developments pertaining to using a RESTful approach to GWT.

In my last blog, I spoke of RestLet, a server-side Java framework for REST. When I first learned of this technology, my cronies at Solertium Corporation and I fully embraced the concept, even doing some development on the open-source tool. Between then and now, I have been experimenting with client-side tools that provide reliable API through GWT to a RESTful server.

I first found GWT-REST, which if you saw my comments, I found to be pretty usable. Like the original developers of RestLet, though, I found it to have almost too much going on to make it work for me at the time. In addition, since, at the time, I have a strong code pattern that worked, it didn't make me want to go through the trouble of refactoring. After speaking with their development team, though, it looks to be strong in the future.
http://code.google.com/p/gwt-rest/

Since then, the RestLet guys have announced the release of a Restlet-GWT module, a port of RestLet to GWT, supported by the release of GWT 1.5. You can check out the official announcement here:
http://blog.noelios.com/2008/07/25/restlet-ported-to-gwt/

I am interested in seeing the differences between this and GWT-REST, but from my initial reading it seems that the RestLet version is an attempt at a direct port as opposed to something customized to have client-side conveniences implemented -- which I feel has strong and weak points, but the good should outweigh the bad here. I'm excited to see the implementation details, though! If you want a quick overview, the RestLet wiki provides pretty pictures and diagrams:
http://wiki.restlet.org/docs_1.1/g1/43-restlet/144-restlet.html

Again, I want to express that the RESTful method is more of an alternative to RPC than a replacement, both having benefits and drawbacks. The main drawback to RPC that has turned me to this approach is the tight client-server coupling issues and the limitations it enforces on your back-end server technologies.

My suggestion -- give Restlet's GWT module a shot. Like I said, it's an alternative, and it works right alongside RPC so it's not an either-or situation. We all have our own ways of getting the job done, but I'm always excited to hear of new developments and try them out, especially ones like these which make my job that much easier!

Thanks for your time in reading this. Feel free to comment with opinions for or against REST in GWT as I'd love to hear both sides. Also, if you'd recommend any technologies, again, feel free.

--
Carl Scott
Software Developer, Solertium Corporation



References:

• GWT-REST: http://code.google.com/p/gwt-rest/
• RestLet Wiki: http://wiki.restlet.org/docs_1.1/2-restlet.html
• RestLet with GWT: http://blog.noelios.com/2008/07/25/restlet-ported-to-gwt/
• Google Web Toolkit: http://code.google.com/webtoolkit/
• Roy Fielding explains REST: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
• RestLet: http://www.restlet.org/
• My previous blog: http://gogocarl.blogspot.com/2008/04/internet-alternative-to-gwts-rpc.html