Pages

Monday, August 27, 2012

First E2E Web App Stack (Almost)

Finally E2E Web Application using Google GWT, Apache Tomcat, Glassfish, J2EE and Web services!



In my last attempt, I tried rejiggering the GWT Designer Log-in Manager tutorial to implement my own functionality. Specifically, I planned to keep the UI elements (panels, textboxes, buttons etc) but change the labels and functions to implement a Temperature Converter web application which accepted temperature values and made calls to converter service which actually resided in the server back-end. My desire was for the service to be SOAP/HTTP service which was called by GWT server which in turned serviced the GWT client. My implementation approach was to just deal with GWT client/server aspect first before introducing the SOAP service. This is the Log-in Manager tutorial, I started with:


And this was the GWT Remote Procedure Call tutorial which I was leveraging in order to rejigger above tutorial to add RPC functionality:


I had written about completing the RPC tutorial in earlier post (Begining Web/SOA/J2EE Dev). However, this was were I as getting stuck. This RPC tutorial has a rather confusing/clumsy syntax for linnking the web service interface, its implementation, the client proxy and the async callback function. It was not helping that I was trying to learn how to apply the RPC at the same time as I was rejiggering UI tutorial which was also my first exposure to the GWT Designer (Window Builder project). So, I took different approact of first completing start-to-finnish GWT Desinger project and then returing to the RPC aspects. For a fresh start I turned to a different GWT Designer project from the Log-in Manager application. It's another StockWatcher app similar to the one I did in Begining Web/SOA/J2EE Dev but this one is done using GWT Designer/Window Builder:


I completed this tutorial painlessly and it gave me even more appreciation for GWT for web application UI over straight-up HTML/Javascript which, again, is what GWT ultimately generates/deploys. It just makes the coding/development seemingly easier/better because it allows you to develop in good old Java and uses familiar UI development constructs. So, I'm now a GWT client app developer Wizard (not exactly) but the problem still was that I had no server side implementation or link from client to server. Fortunately, I found a different tutorial which had much more straight forward approach to dealing with this GWT RPC:


First, I used the GWT RemoteService Wizard to redo the StockWatcher GWT Designer web application to remotely call the stock watcher service (rather than use client side implementation). Worked like a charm. Then I proceeded to create my very own GWT Designer web application from scratch to implement a temperature conversion application. First, I created the client side using same steps as Stock Watcher tutorial with the temperature conversion logic located in the client, then I followed the GWT Remote Service Wizard steps to transfer the conversion logic to the GWT service, finally I used eclipse webservice client generator to create client class from my web service which was a J2EE application (EAR) I had previous created deployed on Glassfish server. that experience will be covered in future blog entry. The GWT pieces are covered in the Google tutorials but the Eclipse web service client generator is not. From the GWT Window Project in Eclipse, navigate to the following:

File -> New -> Other -> Web Services - Web Service Client

Then enter the WSDL location for you web-service. Turn the dial on the client-o-creator to "Develop Client"...you can turn it all the way up to assemble, deploy, or test but then you'd need to add/configure a suitable Web Application Server to your workspace (which can be a very useful thing to test or get a feel for the Web Service operations but not something needed right this second...especially since I develeloped/deployed this particular service).


Hit Finnish...and presto !

Now, you'll see a new package with a bunch Plain Old Java Objects (pojos) in your project explorer new. Below, this new package is appopriately named com.ola.pojo (named by me when I originally created the webservice). The package contains an Interface class called TempConverter.java which shows the methods that the class provides aka as the operations provided by the service. Additionally, the package includes a bunch of supporting classes TempConverterProxy.java, TempConverterPrixy,TempConverterServiceLocator.java,TempConverterSoapBindingStub.java, all created by the Eclipse tooling from the WSDL which I had specified. All you now need to do use this service is to instantiate an obect of TempConverterProxy and you can call any of its methods/properties just like its a pojo object...pretty neat, I think.




And after all that - creating web service using J2EE, deploying that services as a EAR package into Glassfish J2EE container, Creating GWT RPC server to call/consume that web service, and then finally creating GWT client to provide UI and use the web service methods via RPC calls to GWT server - what you have is...

So, at the top of the post, I declared success of full E2E implentation of a web application stack...well,  almost the full stack. This humble app is still missing the database/persistence functionality. Next, I'll try to get a diagram together illustrating the full stack. And I'll continue work on another app to also implement persistence.




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....

Stumbling with (JSP/Servlet/GWT/SOAP)


Finally, I felt like I had all the components (Tomcat, GWT, J2EE Classfish, Eclipse) installed with a modicum level of understanding gleaned from creating/deploying working code from tutorials to piece together E2E web app. So, I boldly proceeded. However, I was met with new series of challenges or should I say, "learning opportunities"...

FIRST STUMBLING BLOCK
Figuring out how to import Web Service WSDLs for use by View or Controller (JSP/Servlet or GWT framework overaly). After much time, I pieced together that I need to create, in my project, a "web service client proxy" using the WSDL (Eclipse ->Dynamic Web Project -> New -> Web Services -> Web Service Client -> Pop-up Wizard to specify/import WSDL). This creates the plumbing including a class called MyxxxServiceProxy.Java. This class then needs to be instantiated, and its methods called, in my View or Controller…at least this is my working theory 

SECOND STUMBLING BLOCK
My Eclipse IDE would not let me import the WSDL using aforementioned wizard. I tried external internet published web services (thinking something may be wrong with my locally authored services). I tried my services running locally on both Glassfish and Tomcat. I tried pasting the WSDL file as resource direct into my Eclipse project…nothing. Google search on error - "IWAB0014E Unexpected exception occurred." - showed this was a known bug that was addressed in previous versions of Eclipse, so should be fixed in my current version (Juno 4.2) but no dice. Suggested workarounds included - restarting/changing workspaces and starting/restarting development mode web server - but none worked. Finally, I tried importing WSDL from my eclipse IDE on my Mac (as opposed to my Ubuntu VM)…success…but now I had to shift development to my Mac but I accepted this for now.

THIRD STUMBLING BLOCK

Now I could, in theory, create views and controllers to consume my web service resource. In practice, I had never actually done this step. In all my disparate tutorials, none had made this crucial connection between either JSP/Servlet or GWT(Client/Server) and Soap/HTML service. So, making this step work, demanded more stumbling, but that itself was not the actual third stumbling block. That, came with my Apple Eclipse IDE being unable to load my local Tomcat Server in it's dev mode. 

"Could not load the Tomcat server configuration at /usr/local/apache-tomcat-7.0.29/conf. The configuration may be corrupt or incomplete.

Reason:
Could not load the Tomcat server configuration at /usr/local/apache-tomcat-7.0.29/conf. The configuration may be corrupt or incomplete."

Clearly, the "Reason", which was just a repeat of the error, was very helpful…not. I tried changing, in config/server.xml, apache tomcat port#s from 8080 currently used by my Glassfish server running in my Ubuntu vm which is networked with Mac via Virtualbox (though did not think that was source of error as previous port conflict errors in Eclipse have been more explicit). I also tried tomcat-users.xml configuration. Thinking that the users/roles that I added to manage tomcat from browser, where causing problems for IDE…nothing. Then, as I was typing this journal entry it just hit me "try google !" (dooooh)and I did. This time, unlike with STUMBLE#2, I met with success. Results indicated that there was an OS (not Tomcat) permissions issue with Eclipse being able to read/write configuration files in tomcat config directory. So, taking the blunt mallet solution approach, I promptly chmod rwx * in /config…even though, something (i.e., common sense) tells me that universal rwx on any folder…especially your web server folder…is generally not a good thing. But I'll come back to it later. For now, glad to be back in business…sorta. 

RESOLUTION TO STUMBLE#2 
Downloaded/installed new instance of eclipse. That means, also had to reinstall Glassfish plugins and GWT plugins. But tests show WSDL import/client proxy generation is working. Notably, there's no diffence in "Build" version between new/old eclipse versions. One just works. The other doesn't…..aaargh!

Version: Juno Release
Build id: 20120614-1722

TRYING TO CREATE JSP/SERVLET THAT CONSUME WEB SERVICES

After, getting new Eclipse JUNO installed and web service client proxy generation working, I fooled around trying to figure out if/how standard JSP/Servlet framework and Eclipse JSP editor could be used to provide basic/rudimentary web app UI used to call SOAP/HTTP web service. Meeehhn, I know that somehow this "should be possible" but JSP as an "easier" method to deliver client side UI from servlet (as opposed to using servlet to create/format HTML using standard printout) is whack. Maybe there are neat tools out there, besides Eclipse, to do this kind of direct Servlet/JSP formating or maybe I just have not properly wrapped my head arond JSP/Servlets. Eitherway, I was convinced direct coding of Servlet/JSP is not the answer...so, back to Google GWT. 

BACK TO GOOGLE GWT
As I journaled on 8/16, I had successfully completed the GWT Stock Watcher sample tutorial which included creating GWT Service and calling from GWT client via GWT RPC. However, available documentation stated that GWT RPC was not same as SOAP/HTTP and that SOAP/HTTP was not directly supported, instead generic HTTP calls could be used. However, since "Eclipse" and its Axis/WebToolkit modules where doing the actual generation of client proxy from WSDL which were then exposed as regular Java classes to components within project, I figured.....eeeah, why not give it a try...

Begining Web/SOA/J2EE Dev


8/16/2012 - Thursday

     

By now, its been 3 weeks ~ maybe 100 hours ~ of dog headed attempt to get broad hand's-on perspective of Web/SOA/J2EE development. So far, I've tackled:












Apache Tomcat - for Front-end/View (HTML/JSP) and Controller (Servlets) web framework













J2EE Glassfish - for "Model" or business logic served up via Soap/HTML


Eclipse IDE - with all the plugins to make "stuff" for all of the above
Plus all the Operating System and Browser specific quirks of developing with each of above platforms

Now I was attacking Google Web Toolkit (as an alternate Front-end and Controller web-framework)


I actually started with GWT few days back on Sunday (8/12/2012). And  I had triumphantly completed the first section of Google Web Toolkit Tutorial:

BUILDING A SAMPLE GWT APPLICATION


And I had moved on to the next section

COMMUNICATING WITH SERVER


And that's were I got stuck (again) .

I had completed the server side implementation and the client side updates to call the server method (using GWT RPC) to get the (fake) stock quotes being used to populate the browser view.

Everything worked EXCEPT for a bit of code functionality designed to mimic catching and reacting to a GWT RPC exception. Code was functional but the simulated exception throwing/catching was not happening. That Sunday, after working through the tutorials ALL WEEKEND, all I could manage was to review my code, staring and comparing with tutorial for easy mistakes...Nothing. At this point, I was too brain-dead to go into discipliened/debug mode. 

Today, I finally picked it back up and I started setting breaking points to step through the code but bewilderingly, breakpoints where not working. The Eclipse IDE was just not doing anything with them. Google search on "eclipse breakpoints not working gwt" showed me that others had the problem but there was no clear RCA. I tried restarting browser, IDE, VM, server, application, and changed my eclipse Properties -> Java Build Path -> library -> JRE System Library from "java-6-openjdk-i386" (base Ubuntu JRE install) to "jdk1.6.0_33" (which I had recently downloaded from Sun to try to solve some other issue on some other project at some other point), also fixed my $JAVA_HOME environement variable to point to the "jdk1.6.0_33" folder (export JAVA_HOME = usr/lib/jdk1.6.0_33)....I'm not sure exactly which combination of advice/actions cured the problem but something worked. Actually it worked two fold...the breakpoint debugging functionality worked and so did the apparent bug with the non-functioning exception trying/catching....phew