In the spirit of choosing weapons carefully I’ve decided to start a weekly post about a technology that is currently at the top of my list of solutions for a particular problem. I like to evolve my technology stack slowly and what better way to do that than to get some feedback on the solutions I’m using and possible alternatives to them. I’m hoping that this will create an exchange about tools of the trade that will be of value not only to me, but others evaluating similar technology.
First up is Direct Web Remoting (DWR). DWR is currently my Java Ajax framework of choice. I figure this is a good first topic since JavaScript is all the rage right now and there are a plethora of tools available in this space. DWR makes exposing server side Java via JavaScript simple and clean. Essentially you just register a DWR servlet that generates JavaScript to match your server side objects and make an XML configuration file that lists which Java objects should be exposed. You can literally be making remote calls to your existing server side objects in about 5 minutes. The latest version also supports annotations, eliminating the need for a configuration file.
In general, when I’m evaluating technologies there are a few important factors I always consider. First and foremost I look for something that provides the features needed for me to solve the problem at hand in the simplest manner possible. DWR does a good job of this. I think it’s a great example of a relatively simple solution for a complex problem. It is very easy to use yet it has the functionality I expect from such a framework.
Another thing I like to look at is a tool’s ability to integrate with the other technologies I’m using. DWR has support for integration with several common frameworks including Spring, Struts and Hibernate to name a few. I’ve personally used the Spring integration and was really pleased with it.
Good documentation is a critical factor for me when I’m choosing technologies. There is inherent risk when adopting new technology. This is one of the main reasons I feel the choice to use a new technology should be made carefully. New tools come with new problems and you need good documentation to help you tackle those problems. I wouldn’t say that DWR gets an A+ in the documentation department, but it’s pretty good. The getting started section is a nice way to get up and running in minutes and there are several tutorials to help get you started with common tasks.
Finally, I feel that mainstream adoption is an important consideration. I don’t like to put a project at risk by adopting a technology that no one is getting behind. There are a lot of factors that contribute to the success or failure of a technology; I won’t begin to pretend that I know which unproven technologies are going to make it. DWR passes the test in this area too. Several large companies including TIBCO, Wal-Mart and American Airlines are using it.
Of the tools I’ve used for Ajax functionality, DWR is the hands-down winner. If you haven’t used it, I highly recommend checking it out. If you have used it, I’d be very interested in hearing if it is indeed your weapon of choice when it comes to Ajax or if you've got something else to recommend.
Posts
I don't have a favorite Ajax framework but I do agree that documentation is really key.
ReplyDeleteJust recently I was working with two APIs neither of which is well documented and as a result it took me hours and hours to figure out how to use them. I can't stand that!
Maybe that's why people invent new frameworks, because if they build it at the very least they'll know how it works.
Nice blog! Keep it up.
I have to say I've never used a javascript framework that integrates with the backend, though I'm not sure how I feel about the idea. The ones I've played around with generally have more script that needs to go to the client ( decreased user experience ). Conceptually it's sound in reducing the initial work and having easy interop. However, I would look at it from a portability standpoint too. For the same reason you follow OO practices to make your objects less dependent on knowing about each other, I would lean towards advocating the same on your front-end versus back-end.
ReplyDeleteI've been using jQuery now for a while for a javascript library and have been enjoying the simplicity and flexibility. Syntactically you can query for elements in the DOM the same way you would with CSS, which is obviously a good thing (tm). It has stuff built in for dealing with AJAX calls and you can process XML or JSON natively, or just output widget HTML ( depending on your architecture for how things will be used ).
Throwing in some simple OO concepts you can create portable chunks of functionality incrementally that are independent of the technology that you are implementing server-side. I don't like my client-side code being dependent on what is running on the server.
=)
I'm also a fan of jQuery. It is currently my javascript library of choice and actually might be a technology I talk about in a future “Tools of the Trade” post. I certainly don't use DWR to replace something like jQuery, it’s strictly for ajax calls. I agree that OO principles help to loosely couple layers and that is a good thing. For me I think the choice to use the ajax functionality available via jQuery over DWR depends on the situation. The jQuery functionality is excellent for RESTful type interaction and is an approach I favor for new development. I like DWR in situations where I have existing server side objects that I need to call in an RMI manner. That type of interaction is inherently more tightly coupled and thus maybe not as desirable but sometimes it’s the right solution.
ReplyDeleteVery nice article. DWR is a great framework especially when you are working with Spring, great integration.
ReplyDeleteBut I won't agree on documentation. The API keep changing but the documentation are not updated. Therefore if a beginner try to use DWR he will get nothing but frustration. This is my experience in past, I don't know if they have improved the documentation lately.