This post is part of the “ITworks Design Journal” series.
Currently, ITworks uses JSON generated via PHP for client-server communication. This decision was made for several reasons:
- I am not extremely familiar with Java servlets or serving them (ie, Tomcat, etc)
- I am not familiar with accessing SQL databases from Java code
- I am experienced in PHP and quickly wrote code to convert SQL result sets into JSON responses
- I already had code to authenticate via LDAP written in PHP that could be reused for this application
- The university already has servers set up to serve PHP scripts
However, after reading more about GWT RPC and how it works, I decided to try my hand at setting up my first Tomcat instance. When the university’s web developer asked for a new Apache server, I figured it was an opportune time.
So, after a lot of experimentation and a lot of reading documentation, I installed my first Tomcat server, and even got the GWT "Hello World" demo app (the one that gets created when you use webAppCreator) to run by using mod_proxy and ProxyPass (I’m still having issues getting mod_jk to do what I want it to, but I think I’m close). So, now using GWT RPC is a real possibility.
GWT’s RPC sheme is very nice; you can call server-side methods, and your input parameters and the server’s return are all automatically serialized and sent acorss the wire–you don’t have to worry about it at all. This is certainly a very nice feature. I also feel confident that I can get LDAP authentication and SQL connectivity down fairly quickly.
The one downside is connection other non-GWT applications to the server-side code. If I want, say, an iPhone app, or a desktop widget, to be able to connect to the server to retrieve information I have to either (1) figure out how GWT RPC sends and receives information, or (2) code the server-side logic again in another language.
It’s still up in the air for me. Thoughts?
#1 by Matthew Morgan - May 19th, 2009 at 04:00
For non-GWT stuff, what about making another server-side interface that takes GET/POST arguments and makes calls to your existing interface, then outputs XML or something similar? You could treat the new interface as the view. That would be a good test of how strong your MVC implementation is as well…if you can easily implement alternate views, that’s a good sign.
Then again, I’m really new to a lot of this stuff. I hope that made sense. ;)
#2 by BinaryMuse - May 22nd, 2009 at 14:49
The issue is that the existing (RPC) interface is not available to outside services. It’s also not stable–the GWT developers tweak with it from release to release to make it faster. So, if I implement an RPC solution, any other non-GWT apps would have to have a completely separate server-side solution.
I’ve actually made a decision–you’ll see what it is shortly. :)
#3 by Paul S - June 22nd, 2009 at 01:03
Are you familiar with Spring? Given that this is your first introduction to using GWT with Tomcat I’m not sure that this suggestion is appropriate, but a good architecture for this project would be write all your server code agnostic of how it will be served, using Spring to cut through hard dependencies and make your code more modular. Then for the GWT stuff you’d use GWT-SL (server library) to export certain functionality as GWT-RPC “servlets” so your GWT app can talk to them using the same techniques that you see in the Hello World app that comes with GWT (nice and simple to use), and furthermore other things can interface with your server code too, like you could have a basic html version or a light version for mobile phone, etc, all plugging into the exact same server code. Elegant solution, but requires an all round knowledge of Java server programming, coupled with knowledge of GWT. When do we get to see the finished product? ;)