Schlagwort-Archive: gwt

Session: GWT – JSF done right?

I just finished my GWT session at the Jax India 2008 conference. I had to switch notebook because I have forgetten my micro-DVI to VGA adapter at home (Germany). How bad, I was really looking forward to test drive my Macbook Air here.

I had about 50 listeners in a very nice auditorium. We had about 10 minutes of Q & A after the session, awesome. It gives me the impression that GWT is beeing accepted as alternative web framework for the Java EE stack.

GWT – JSF Done Right ?

GWT’s mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser. This session shows what this mission statement means for the Java developer and for the Java Enterprise industry.

PDF:
GWT – JSF done right?
JAX India 2008, Papick G. Taboada

Make the Web a better place

GWT Artikel Bild

Mit dem Google Web Toolkit (GWT) soll ein Java- Entwickler schnell in die Lage versetzt werden, JavaScript/Ajax-Anwendungen zu schreiben. Die Nachfrage ist groß, und immer mehr Projekte sollen mit JavaScript im Browser dem Trend des Web 2.0 folgen: von intelligenter Validierung ĂŒber Drag-and-Drop bis hin zu Mashups mit Google Maps. Der Browser hat sich zur beliebtesten Anwendungsplattform entwickelt, die User Experience ist hier das SchlĂŒsselwort.

Seitdem das Google Web Toolkit [1] auf der JavaOne 2006 vorgestellt wurde, erfreut sich das Projekt immer grĂ¶ĂŸerer Beliebtheit. Was aber ist GWT? Kurz: eine Technologie bzw. ein Framework, mit dem JavaScript-Webanwendungen erstellt werden können. Das Besondere am GWT-Entwicklungsprozess ist nicht das Ergebnis, sondern die Vorgehensweise: Der Entwickler schreibt die gesamte Webanwendung in Java (kein HTML, kein JavaScript). Der Trick besteht darin, den Java-Quelltext nach JavaScript zu ĂŒbersetzen, sodass die Vorgehensweise das Nutzen aller FĂ€higkeiten der IDE wie das Refactoring und Debuggen im clientseitigen Code ermöglicht. Das GWT Framework bietet ein grafisches UI-Komponentenmodell, ein Modularisierungskonzept, eine fragmentarische Java-Runtime-Emulation, ein API zur Manipulation der Browser-History, eine eigene RPC Implementierung, Internationalisierung und noch einiges mehr. Hier Googles Leitspruch fĂŒr GWT:

„GWT‘s mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser” [2].

Frei ĂŒbersetzt bedeutet das eine radikale Verbesserung bei der Verwendung von Webanwendungen (fĂŒr den Endanwender). Bestehende Java-Werkzeuge sollen eingesetzt werden, um ohne EinschrĂ€nkungen AJAX-Anwendungen auf beliebigen Browsern zu entwickeln.

Es ist schon beeindruckend, was sich hinter dieser neuen Technologie verbirgt. Aber es ist von Google 
 Schon seit einiger Zeit hat Google das Image des sauberen kleinen Start-ups verloren. Google ist groß, Ziele und Mittel teilweise umstritten. An dieser Stelle erst einmal eine Entwarnung – auch wenn Google drauf steht, ist kein Google drin. Durch die Verwendung von GWT werden keinerlei Dienste von Google (außer GWT selbst) verwendet. Google hat natĂŒrlich nichts dagegen, wenn sich immer mehr Produkte bei anderen Google-Technologien bedienen – zum Beispiel Google Search oder Google Maps. Wenn die Hemmschwelle hier bislang bei den nötigen JavaScript-Kenntnissen lag, so ist diese mit GWT letztendlich behoben worden. Auch fĂŒr JSF gibt es bereits Komponenten, die das Verwenden von Google JavaScript APIs erleichtern:

„Naturally, GWT is also a great way to easily take advantage of the latest and greatest Google APIs and browser enhancements, such as Google Gears” [3].

GWT ist heute einsatzbereit: Es ist seit Version 1.3 unter der Apache License 2.0 veröffentlicht und seit Version 1.4 trĂ€gt GWT nicht mehr den Zusatz „Beta“ im Namen. Die aktuelle Versionsnummer lautet 1.4.61 und kann von der
GWT-Homepage in Google-Code heruntergeladen werden. Das GWT-Team
arbeitet gerade an der neuen Version 1.5. Wichtigste Neuerung, an der aktuell gearbeitet wird, ist die UnterstĂŒtzung der bei Java 5.0 neu eingefĂŒhrten Sprachelemente wie Annotations und Generics, denn aktuell wird lediglich der Sprachumfang von Java 1.4.2 unterstĂŒtzt. Die unterstĂŒtzten Browserplattformen des Projekts sind im Augenblick die aktuellen Versionen des Microsoft Internet Explorers, Firefox, Opera und Safari.

Artikel weiterlesen:
PDF: Make the Web a better place

Non invasive GWT and Spring integration

[update]
If you are working with GWT 1.6, you probably would like to have a look at this here:
http://52.90.157.123/2009/07/17/non-invasive-gwt-and-spring-integration-reloaded/
[update]

Obviously I am not the only one looking for a way to integrate my Spring backend into some GWiT application. After searching for a while I didn’t find any suiting solution. There are some interesting approaches (like GWT Widget Library SL and using the maven plugin), but being new to GWiT I did not want to give up the GWiT Development Shell neither the embeded Tomcat. I wanted the integration to be less invasive as possible.

So here is what I did


First problem I had to solve was how to get my configuration elements into the tomcat configuration. I needed to add some listeners to the web.xml (e.g. to start the Spring container and Acegi security):

Here is a snippet from my web.xml showing how to use the listeners provided by the Spring Framework to start an application context and to configure log4j properly:

GWiT does not provide any extension point for custom configuration, so I had to add the configuration elements directly to the provided Tomcat web.xml. I cannot make changes to the web.xml in the ROOT web application, since this web.xml is re-generated by GWiT every time the Development Shell is started. Fortunately, the default web.xml stored in the “conf” directory of the embedded Tomcat is generated only one. So I found some place to add my configuration elements. Unfortunately the configuration there is not reusable, so I am having double configuration here: configuration for the development and configuration for the deployment.

Next, I wanted to easily have access to my Spring beans. JSF developers have a variable resolver and have access to their Spring beans for free. I wanted that too. Again, being new to GWiT, I didn’t want to loose the features provided by the IDE (Eclipse + GWT-Designer in this case). It is nice to simply say “add new remote service” in the IDE and get everything wired out of the box. For different reasons I do want to expose my Spring beans automatically to the GWiT application. JSF developers have the services for free at the SERVER SIDE: the services do not get exposed via RPC automatically. I wanted something similar: my GWiT remote service implementation should have access to the Spring backend for free without exposing anything automatically.

I wanted some sort of dependency injection. Since the servlets are managed by the servlet container and the servlet container does not know anything about dependeny injection of Spring beans into servlets I had to do it myself.

First, I needed some sort of markup to identify what to inject. I was using JDK 5 syntax on none client sources, so I used an annotation. I could also have used some marker interface for my services, but I found this to be to invasive, I did not touch my backend files.

All I wanted to do is to add this annotation to my setter methods in my GWiT remote service implementations. So I extended the RemoteServiceServlet provided by GWiT and implemented the auto injection.

In short: in the initialization of the servlet I pickup the Spring application context and do the injection for all setter methods annotated.

In the following GWiT remote service implementation I use this injection to get access to my Spring login service (that itself uses acegi, the user DAO and a session scoped bean):

While this leads to a lot of delegation code, I am still happy with the layer separation and the easy usage.

When playing with GWiT 1.5 (build from the trunk) a few weeks ago, I noticed that GWiT started overriding the web.xml in the embeded Tomcat configuration directory. I just thought “oh no!”, but next thing I noticed was that it stopped overriding the application web.xml in the ROOT webapps folder. Let’s see if it stays this way


GWT deferred binding tutorial

I just found a very good tutorial for the undocumented deferred binding featureof GWT. In this example the deferred binding is used to create a databinding framework for GWT.

While introducing deferred binding, it shows a very interesting data binding idea for GWT. Instead of solving the binding to the UI elements at runtime, this approach solves the problem during the compilation. This saves ressources at the client and even simplifies the development.

Using Acegi to secure a GWT application

I am on the train to Munique on my way to the OOP 2008. Today I spent some time refactoring a GWT application (we are moving to GWT 1.5 built from the svn trunk) and thought I could use the travel time to post about GWT and Acegi.

GWT changes the way we develop internet applications. The web application is not only rich, but it also runs standalone in the client browser. Shortly spoken, a GWT application is a statically loaded set of html, css and javascript files. No serverside web technology gets touched in this process. The webserver delivering the files does not count here
 Once the application starts running on the browser, it will start loading data from the server using http requests. This data will further on be displayed in the browser by the GWT application. An application delivered in Javascript is a security nightmare, since the code on the client side is readable and can be easily manipulated.

There are mainly two aspects in a GWT application scenario that might be secured:

– the GWT application
– the RPC services offered by the server

Securing the GWT application is an impossible task. It is possibe to only give access to the Javascript application after the user has identified itself, but once the Javascript code gets transfered to the client there is nothing that can be done to avoid manipulation.

Securing the RPC services offerend by the server is by far much more easier. Assuming the server is written in Java, there are many ways to secure the services offered: services in the GWT are RPC are implemented by Servlets. Restricting access to the servlets would do the job quite efficiently.

The approach described here does not try to hide the GWT application from the world. The application cannot be secured in the browser and, in many cases, it is the data and the serverside actions that must be secured. A GWT application that cannot connect to its RPC services because of bad credentials is useless. If the application algorithm is worth securing, then hiding the application is the best option available. Unfortunately, this cannot be done with GWT, it would be like a dog trying to bite it’s own tail. After all, the user must identify itself before, and then the application can be dowloaded to the browser. GWT does not known anything about lazy loading parts of an application at runtime. A simple way to implement hiding the application is to host the application in a JSP page ahd have this page secured. Not only the JSP must be secured, but also all static files composing the GWT application. Only after authentication succeeds, the JSP page can be accessed, bootstraping the Javascript application. The JSP should create a server session with the provided credentials, the GWT application would use RPC to gain access to this information and to know who has logged in. This is a server side approach, and here is where I tend to use Acegi.

Acegi is a very interesting Java security framework. It is often used with Spring and with web applications, but it also can be used standalone (without Spring) and to secure any kind of Java application. With AOP techniques its usage can be non invasive to the application code.

In our project we did not hide the GWT application. First, it is an intranet application. Second, the application is useless without the RPC services and the provided data.

The idea on our approach is to download the GWT application to the browser and let the application display a modal login dialog box. The information provided by the user will then be sent to a unsecured login service on the server. The server performs the authentication through acegi, creates a server side session with the appropriate credentials.

Een if some user hacks the Javascript to bypass the login dialog, nothing will happen. The navigation tree is populated by RPC: each user has a different navigation tree, depending on user preferences, stored searches and security roles.

The login RPC call returns the login information required by the GWT application to know that a successful or unsuccessful login has occured. On a successful login, the GWT application starts loading the data needed through the secured services in the server. The server allows this services to be called because the client has created a valid server side session with apropriate credentials. Acegi will secures the services based on this information.

Finally, our GWT application checks regularly if the session has not been invalidated (or if the server is respoding at all) and performs a client-side logout if needed.

Feedback is welcome!