Replacing Flex frontend with Vaadin

I am investigating tools for converting a legacy web application that is fairly large and currently uses a Flex UI that talks to a J2EE backend (servlets) using JSON messages over AJAX which then uses JDBC to access a MySQL database. It is what you’d call a very traditional Java web application built with the MVC framework in mind but using Adobe’s Flex for the client interface for a consistent look and feel across browsers, screen sizes, etc.

For several business reasons (like loading speed and iPad support), we’ve decided to replace the UI with a more standard plugin-free architecture. Vaadin is the first framework I’ve seen that has a similar look and better speed. From my preliminary tests, it also runs fine on the iPhone which is also a plus.

My question is how to get it to talk with our existing server-side code. I understand Vaadin is different in that it is written as if it’s all on the server like a desktop app, but technically client-side code is generated and run within a browser. So it can, it would seem to me, work in a J2EE servlet-driven environment as a client interface. There is a lot of investment in the server Java code already that we’d rather not rewrite due to time and cost. Am I barking up the wrong tree?

If this is all possible, how do I call the servlets passing JSON data asynchronously and retrieve and process their JSON responses? If that is impossible, how do I query and update our MySQL data from Vaadin directly? I’d like to do so without yet more tools and libraries like Hibernate or JPA - or at least know that it is possible.

Thanks for any help you can share!

We did a
recent study
about how Vaadin components work in mobile Safari.

A Vaadin application consists of two parts: the code you write runs in the server in a regular servlet that’s managed by Vaadin, and the client-side part (implemented by us with GWT) is only used for rendering your UI “behind the scenes”. Generally you just call your business logic from the UI structures and events in the Vaadin application, and let Vaadin handle all RPC stuff, Ajax etc. Take a look at the
architecture diagram in the book
, perhaps it clarifies the matter.

It depends from the architecture of your current server-side logic how easy it is to convert into a Vaadin application, but generally the more modular the current logic is the easier the conversion will be.

I suppose, is should not be very hard to call your backend business methods from the new, Vaadin based UI. As the Vaadin UI logic code runs on the server, you’ll be able, I think, to directly call your EJB’s or DAO/etc business classes, without having to use AJAX and JSON layer (latter will be handled automatically by VAADIN to transfer UI updates to a client transparently for you)

Thanks for this link. It proved very valuable and useful. The reader’s posted comments about the 2-finger scroll trick is helpful as well.

The architecture is very much what I’d call a “traditional” servlet-based J2EE web app except the client side interface is written using Flex instead of standard JSPs with JavaScript. By this I mean the server side code is just a collection of servlets, all based on a common base class servlet that does some application session housekeeping, for each set of tasks.

So there is a servlet called SaveRecordServlet that takes a set of request parameters with the data to be updated and a type to be saved. All HTTPS requests are made via POSTs. So the servlet’s doPost method gets the session object from the request then goes through an if…else if…else structure to determine which private method to call for saving the correct record type using JDBC to speak to a MySQL database. It builds a response containing a JSON object with a success status and any message the client may need to display.

Obviously, there is also a GetRecordServlet and a GetListServlet. They take a type request parameter and an other pertinent info needed to get the correct info and also call internal private methods for the corresponding type to retrieve info from the MySQL DB using JDBC and package the results into a JSON structure that is sent back in the response for the client to parse and use.

Of course, I’m simplifying a lot of details, but just want to illustrate the basic architecture and the simplicity with how it works and that no other frameworks or data abstractions are used. The UI used to be just JSPs. It was rewritten with Flex for more powerful components and a common look and feel across browsers. Apple has messed us up by refusing Flash support and the client wants iPad support. So I was looking into Vaadin for now replacing Flex for the UI but maybe it requires too much backend “server-side” changes to meet our timeline? Or maybe it is still possible with some “tweaks” in the servlet framework?

I was hoping this to be the case, but it may not be. See my earlier reply about our current server code. The use of JSON is already heavily coded in the servlets to speak with the UI through standard AJAX requests/responses. This may interfere with Vaadin’s architecture? I really like what I’ve seen of Vaadin and have enjoyed coding some proof of concept interfaces for the boss, but unless I’m really missing a piece of the puzzle, it appears to be meant more for a ground-up design of a new application for the web instead of a purely UI layer to update a legacy one. Please tell me I’m wrong. :open_mouth:

So your current servlets speaks directly to JDBC/MySQL, not with some DAO objects which hides all the low-level JDBC work ?

Yes. Sorry. :*)

There are a lot of libraries for Java to access JSON and you can of course access the business logic server over HTTP from your UI -server. With Vaadin the “JSON servlets” are of course quite unnecessary, but can be used until you want to reduce the extra complexity in the future.

Another way of doing the same would be just cut-n-pasting the code from Servlets to business logic classes with native Java API:s to avoid extra JSON coding-decoding and http.

Thanks for your help. Three questions:

  1. How would I access the current backend servlets over HTTP from a Vaadin app, even though I know this is grossly inefficient? It would at least give an interim working product until the rewrite is complete.

  2. As for cut-pasting the servlet code into business classes in the Vaadin app, is there a standard “right” place for these business classes to go in the application package structure or is it entirely up to me? Since right now the interface to these methods are the J2EE doPost with parameters on the request and they “return” a JSON object on the HTTP response, any suggestions for the “best” way to convert them to a native Java method call?

  3. Are there JSON-handling classes in Vaadin or should I just use the json.jar I’m already using to encode the objects in the current servlets to also decode them for the new interface? Currently the decoding is done by Flex constructs. I know JavaScript can evaluate JSON objects but wasn’t sure if that is the preferred method in Vaadin or not.

Thanks again!

1 - you can use any http client library, say, “httpclient”, and perform a connections from your vaadin app to your old servlet by a address, then parsing JSON requests. Another way is simulate web contaoner and instantiate and call doPost/doGet methods of your old servlet classes directly. You’ll have to generate a fake http request, but this will be more efficient than doing full http request as stated above.

and as for points 1 and 2 - maybe it is a good place to refactor your old code a bit and create a front-end independent dao classes ?

3 - AFAIK, there are no public JSON classes in Vaadin (maybe internally, in client-server communcation layer). But there are several good JSON java libraries which do parse/generate JSON, so you can use one of them.

Great suggestions! I’d love to refactor things to be more “standard” but am afraid that time constraints and my lack of understanding of DAO may prevent this. I naively thought I had made the server code UI independent by using a standard req/resp interface and using JSON to pass data. The server doesn’t care what technology the client is using as long as it passes the request parameters and can parse JSON responses. Oh well. I’ve been humbled to say the least.

I know it’s not the forum’s job to teach me how to write a modern web application, but can you at least point me in the right direction for getting started with a Vaadin-accepted DAO framework or how to go about this refactoring with the least intrusion to the large amount of working backend code?

I’m already currently using a JSON library on the backend so I can use this same one in the new frontend unless the refactoring is possible and negates the need for it.

Actually, DAO pattern is quite easy, and does not depend to particular framework, its goal is to separate data access and low-leel management from other tirers, such as UI and give a possibility to change the data storage subsystem later without touching other tiers.

In some quick description, you create an interface which publish your data management methods, say:

public interface GuestbookDAO
   List<GuestbookEntry> getEntries();
   void deleteEntry(GuestbookEntry entry);
   GuestbookEntry createEntry(String name, String email, String message, int rating);
   void updateEntry(GuestbookEntry entry);
   GuestbookEntry findEntryByID(int id);

Then you create an interface implentation, which, for instance, works with MySQL database:

GuestbookDAOMysqlImpl implements GuestbookDAO { ... }

But in all your other tiers, you do work with the base dao interface, so later, when you decide to switch from SQL database to, say, locally stored xml files, you simply write another implementation of your interface and uses this implementation in your app - any other code - other tiers, ui, etc remain untouched.

So that’s why Im thinking, that making a dao could take if not the same but very near time than copy-pasting and resolving local JSON communication emulation issues, but in result you’ll get more portable and maintainable code, which will be the extra benefit


Thank you for your incredible patience and good explanations! I understand completely what you’ve been saying now and do agree that moving to a better DAO-based design is worthwhile and a good start for a solution.