Pages

Sunday, August 19, 2012

Google Web Toolkit Expedition (Cntd.)













TRYING TO USE GWT CLIENT TO CALL SOAP SERVICE (CONTINUED)

The unfortunate thing for me about the process of trying to get GWT client to call SOAP service was that as I tried to execute my "brilliant" idea, neither Eclipse or GWT, where giving me any warning/error signs as I blissfully created/compiled/tested/deployed my modules. It also did not help that I spied a Google article which seemed to indicate that this was possible.

https://developers.google.com/appengine/articles/soap

I was not the only one drawn into this tempting (but fruitless) prospect. Excitingly, there was even a lenghty/current bug thread in which the Google developer who authored the GWT-RPC/SOAP article was actively defending his article and why it should be possible for GWT client to call SOAP service.

https://groups.google.com/forum/?fromgroups#!topic/google-web-toolkit/6AI19vFN6go%5B1-25%5D

After hours of research/trial&error, I've concluded that it's not possible.  My reasoning (which I only vaguely understood and I only half heartedly put it forward here) is that the web service client proxy generated by eclipse, and all its related Java plumbing, can not be run by the browser which has only limited Java Runtime Environment (JRE). And, for the browser to make a call to a Web Service that is not provided by the GWT Service (servicing the GWT client), there is some kind of violation of the  browser's Single Origin Policy (SOP) which I only vagurely read about. Anyway, all this was more than enough to get me back to more standard approach to use Client GWT to call Server GWT (which in turns call SOAP service)....

USING SERVER-SIDE GWT TO CALL SOAP

I was hoping to avoid this so that I did not have to create new/additional GWT client and GWT server components in order consume SOAP Web Service (which I'm also largely planning/expecting to author for my applications). It's probably a fair time to ask/answer the question: Why not create all server side components in GWT (and avoid SOAP/HTTP service altogether)? This is just a pedagogical decision to allow me to get broad perspective of Web/SOA/J2EE architerctures. For now, I'm committed to implementing generic/universal SOAP/HTTP web service using J2EE components deployed in J2EE Application Containers like Websphere, Glassfish, JBOSS, Weblogic (actual implementation is Glassfish) which could be consumed by any SOAP/HTTP client (anywhere on the internet...or connected network). 

Back to trialing GWT Client/Server to consume SOAP/HTTP. The GWT Stock Watcher tutorial, uses %100 code to generate its UI elements. Panels, buttons, labels were all added/formatted using Java code (onjects were instantiated from classes that represented UI elements, then the objects' methods where called and attributes set). Also, formatting was done using CSS which was described in XML docs that where referenced by the UI Java code. This seemed a whole heck of a lot better than the JSP/Servlet syntax but still this all-code approach is tedious. I knew there had to be a better way.This GWT business was supposed to be EASY after all. So, I dug into "GWT Designer" but Guess what, that's another toolkit with its own plug-in module and its own project type called "Window Builder" project (as opposed to standard GWT which is "Google Web Application" project)...sigh. Somehting else to download/learn. 

GWT DESIGNER CHALLENGES OR "OPPORTUNITIES"
The Google developer site seems to have conflicting information as to whether GWT designer is loaded in the GPE "GWT Plugin for Eclipse" which I already had. Furthermore, The Ecliplise "installed software" screen shows "GWT Editor/Designer" installed. However, I did not seem to have the option to create "Window Builder" project which was called for in one of the tutorials. Google showed that others seemed to have this frustration too. I tried installing the GWT Designer plug-in separately anyway however the kicker was that it was not available for the latest Eclipse release Juno. Which made me believe (or "want to believe") that is must already be included in the GPE which I had installed. But after much fretting and hours of frustration, I concluded that the full GWT Designer (with Window Builder and other neccessary dependencies) where not available for Juno. So, I had to download Eclipse yet again. This time I had to back-rev to release Eclipse Helios reliease 3.7....and get all my Glassfish, GWT plug-ins all over again.



FINALLY RUNNING WITH GWT DESIGNER 

True to the promise, it seems the UI development is much "easier" with this tool. So, I bravely started yet another march up yet another learning curve starting with the Login Manager Tutorial.

https://developers.google.com/web-toolkit/tools/gwtdesigner/tutorials/loginmanager

However, instead of doing a clean word-for-word sweep of the tutorial, I opted to directly replace the tutorial functionality with mine. The Login manager took user data 'Name' and 'Password', and did some rudimentary client-side validation once a submit button was clicked. It did not actually communicate with any backend service. My version was going to accept user entered numeric value 'Temperature in Celsius'. Then on button click, it was going to update a label on the screen to show Temperature converted to Fahrenheit which was to be calculated by calling SOA/HTTP web service which I had already implemented and deployed to my local Glassfish J2EE application server. I'm getting stuck at the syntax/implementation/integration of GWT's asynchrounous client RPC call, the GWT's RPC service wrapper and the SOAP/HTTP service itself....

No comments:

Post a Comment