Developing Java applications and more specifically, developing Java web applications should be fun. Instead, most projects are a mess of sweat and toil, pressure and delays, costs and cost cutting. Web development has lost its appeal. Yet, among the many frameworks available, there is one in particular that draws our attention because of its ease of use and its original stance. It has been around since the past decade and has begun to grow in importance. The name of this framework is Vaadin. The goal of this book is to see, step-by-step, how to develop web applications with Vaadin.
Vaadin is the Finnish word for a female reindeer (as well as a Finnish goddess). This piece of information will do marvels to your social life as you are now one of the few people on Earth who know this (outside Finland).
We are going to see Vaadin in detail in later chapters; the following is a preview of what it is:
A component-based approach that really works, and provides a bunch of out-of-the-box components as well as extensions
Full web compatibility, in addition to Google Web Toolkit
All development is made completely in Java
Most of the code can be run server-side, taking advantages of Java static typing, with the full power of dynamic update tools such as JRebel
Integration with Eclipse and IntelliJ IDEA IDEs
Available with no charge under a friendly Open Source Apache license and much, much more
Before diving right into Vaadin, it is important to understand what led to its creation. Readers who already have this information (or who don't care) should go directly to Chapter 2, Environment Setup.
In this chapter, we will look into the following:
The evolution from mainframe toward the rich client.
The concept of application tier
The many limits of the thin-client approach
What stands beyond those limits
Why choose Vaadin today?
The state of the market
Vaadin's place in the market
A preview of what other frameworks Vaadin can be integrated with and what platforms it can run on
Vaadin is often referred to as a Rich Internet Application (RIA) framework. Before explaining why, we need to first define some terms which will help us describe the framework. In particular, we will have a look at application tiers, the different kind of clients, and their history.
Some software run locally, that is, on the client machine and some run remotely, such as on a server machine. Some applications also run on both the client and the server. For example, when requesting an article from a website, we interact with a browser on the client side but the order itself is passed on a server in the form of a request.
Traditionally, all applications can be logically separated into tiers, each having different responsibilities as follows:
Business Logic: The logic tier is responsible for controlling the application logic and functionality. It is also known as the application tier, or the middle tier as it is the glue between the other two surrounding tiers, thus leading to the term middleware.
This categorization not only naturally corresponds to specialized features, but also allows you to physically separate your system into different parts, so that you can change a tier with reduced impact on adjacent tiers and no impact on non-adjacent tiers.
When computers were mainframes, all tiers were handled by the server. Mainframes stored data, processed it, and were also responsible for the layout of the presentation. Clients were dumb terminals, suited only for displaying characters on the screen and accepting the user input.
Not many companies could afford the acquisition of a mainframe (and many still cannot). Yet, those same companies could not do without computers at all, because the growing complexity of business processes needed automation. This development in personal computers led to a decrease in their cost. With the need to share data between them, the network traffic rose.
This period in history saw the rise of the personal computer, as well as the Client server term, as there was now a true client. The presentation and logic tier moved locally, while shared databases were remotely accessible, as shown in the following diagram:
Big companies migrating from mainframes to client-server architectures thought that deploying software on ten client machines on the same site was relatively easy and could be done in a few hours. However, they quickly became aware of the fact that with the number of machines growing in a multi-site business, it could quickly become a nightmare.
Enterprises also found that it was not only the development phase that had to be managed like a project, but also the installation phase. When upgrading either the client or the server, you most likely found that the installation time was high, which in turn led to downtime and that led to additional business costs.
Around 1991, Sir Tim Berners-Lee invented the Hyper Text Markup Language, better known as HTML. Some time after that, people changed its original use, which was to navigate between documents, to make HTML-based web applications. This solved the deployment problem as the logic tier was run on a single-server node (or a cluster), and each client connected to this server. A deployment could be done in a matter of minutes, at worst overnight, which was a huge improvement. The presentation layer was still hosted on the client, with the browser responsible for displaying the user interface and handling user interaction.
This new approach brought new terms, which are as follows:
HTML does not support many controls, and what is available is not on par with fat-client technologies. Consider, for example, the list box: in any fat client, choices displayed to the user can be filtered according to what is typed in the control. In legacy HTML, there's no such feature and all lines are displayed in all cases. Even with HTML5, which is supposed to add this feature, it is sadly not implemented in all browsers. This is a usability disaster if you need to display the list of countries (more than 200 entries!). As such, ergonomics of true thin clients have nothing to do with their fat-client ancestors.
Web developers, on the contrary, have to learn an entire stack of technologies, both on the client side and on the server side.
On the client side, the following are the requirements:
First, of course, is HTML. It is the basis of all web applications, and although some do not consider it a programming language per se, every web developer must learn it so that they can create content to be displayed by browsers.
In order to apply some common styling to your application, one will probably have to learn the Cascading Style Sheets (CSS) technology. CSS is available in three main versions, each version being more or less supported by browser version combinations (see Browser compatibility).
Most of the time, it is nice to have some interactivity on the client side, like pop-up windows or others. In this case, we will need a scripting technology such as ECMAScript.
From a Java point-of-view and on the server side, the following are the requirements:
As servlets are the most common form of request-response user interactions in Java EE, every web developer worth his salt has to know both the Servlet specification and the Servlet API.
Moreover, most web applications tend to enforce the Model-View-Controller paradigm. As such, the Java EE specification enforces the use of servlets for controllers and JavaServer Pages (JSP) for views. As JSP are intended to be templates, developers who create JSP have an additional syntax to learn, even though they offer the same features as servlets.
JSP accept scriptlets, that is, Java code snippets, but good coding practices tend to frown upon this, however, as Java code can contain any feature, including some that should not be part of views—for example, the database access code. Therefore, a completely new technology stack is proposed in order to limit code included in JSP: the tag libraries. These tag libraries also have a specification and API, and that is another stack to learn.
However, these are a few of the standard requirements that you should know in order to develop web applications in Java. Most of the time, in order to boost developer productivity, one has to use frameworks. These frameworks are available in most of the previously cited technologies. Some of them are supported by Oracle, such as Java Server Faces, others are open source, such as Struts.
JavaEE 6 seems to favor replacement of JSP and Servlet by Java Server Faces (JSF). Although JSF aims to provide a component-based MVC framework, it is plagued by a relative complexity regarding its components lifecycle.
Having to know so much has negative effects, a few are as follows:
On the technical side, as web developers have to manage so many different technologies, web development is more complex than fat-client development, potentially leading to more bugs
On the human resources side, different meant either different profiles were required or more resources, either way it added to the complexity of human resource management
On the project management side, increased complexity caused lengthier projects: developing a web application was potentially taking longer than developing a fat-client application
All of these factors tend to make the thin-client development cost much more than fat-client, albeit the deployment cost was close to zero.
The Web has standards, most of them upheld by the World Wide Web Consortium. Browsers more or less implement these standards, depending on the vendor and the version. The ACID test, in version 3, is a test for browser compatibility with web standards. Fortunately, most browsers pass the test with 100 percent success, which was not the case two years ago.
One should be aware of the combination of the platform, browser, and version. As some browsers cannot be installed with different versions on the same platform, testing can quickly become a mess (which can fortunately be mitigated with virtual machines and custom tools like http://browsershots.org). Applications should be developed with browser combinations in mind, and then tested on it, in order to ensure application compatibility.
For intranet applications, the number of supported browsers is normally limited. For Internet applications, however, most common combinations must be supported in order to increase availability. If this wasn't enough, then the same browser in the same version may run differently on different operating systems.
In all cases, each combination has an exponential impact on the application's complexity, and therefore, on cost.
As web applications are browser-based and use HTML over HTTP, things are managed differently. In this case, the presentation unit is not the window but the page. This is a big difference that entails a performance problem: indeed, each time the user clicks on a submit button, the request is sent to the server, processed by it, and the HTML response is sent back to the client.
For example, when a client submits a complex registration form, the entire page is recreated on the server side and sent back to the browser even if there is a minor validation error, even though the required changes to the registration form would have been minimal.
Over the last few years, users have been applying some pressure in order to have user interfaces that offer the same richness as good old fat-client applications. IT managers, however, are unwilling to go back to the old deploy-as-a-project routine and its associated costs and complexity. They push towards the same deployment process as thin-client applications. It is no surprise that there are different solutions in order to solve this dilemma.
All the following solutions are globally called rich clients, even if the approach differs. They have something in common though: all of them want to retain the ease of deployment of the thin client and solve some or all of the problems mentioned previously.
Rich clients fulfill the fourth quadrant of the following schema, which is like a dream come true, as shown in the following diagram:
The following solutions are strategies that deserve the rich client label.
Ajax addresses the richness of controls and the page flow paradigm. Unfortunately:
It aggravates browser-compatibility problems as Ajax is not handled in the same way by all browsers.
It has problems unrelated directly to the technologies, which are as follows:
Alternatively, one uses an Ajax framework, and thus, one has to learn another technology stack.
The oldest way to bring richness to the user's experience is to execute the code on the client side and more specifically, as a plugin in the browser. Sun—now Oracle—proposed the applet technology, whereas Microsoft proposed ActiveX . The latest technology using this strategy is Flash.
All three were failures due to technical problems, including performance lags, security holes, and plain-client incompatibility or just plain rejection by the market.
There is an interesting way to revive the applet with the Apache Pivot project, as shown in the following screenshot (http://pivot.apache.org/), but it hasn't made a huge impact yet;
A more recent and successful attempt at executing code on the client side through a plugin is through Adobe's Flex. A similar path was taken by Microsoft's Silverlight technology.
Unfortunately, Apple refused to have anything to do with the Flash plugin on iOS platforms. This move, coupled with the growing rise of HTML5, resulted in Adobe donating Flex to the Apache foundation. Also, Microsoft officially renounced plugin technology and shifted Silverlight development to HTML5.
Java Web Start (JWS), available at http://download.oracle.com/javase/1.5.0/docs/guide/javaws/, is a proprietary technology invented by Sun. It uses a deployment descriptor in Java Network Launching Protocol (JNLP) that takes the place of the manifest inside a JAR file and supplements it. For example, it describes the main class to launch the classpath, and also additional information such as the minimum Java version, icons to display on the user desktop, and so on.
This descriptor file is used by the
javaws executable, which is bundled in the Java Runtime Environment. It is the
javaws executable's responsibility to read the JNLP file and do the right thing according to it. In particular, when launched,
javaws will download the updated JAR.
The detailed process goes something like the following:
The user clicks on a JNLP file.
The JNLP file is downloaded on the user machine, and interpreted by the local
The file references JARs that
Once downloaded, JWS reassembles the different parts, create the classpath, and launch the main class described in the JNLP.
First time installations are time-consuming because typically lots of megabytes need to be transferred over the wire before the users can even start using the app. This is a mere annoyance for intranet applications, but a complete no go for Internet apps.
Some persistent bugs weren't fixed across major versions.
Finally, the lack of commercial commitment by Sun was the last straw.
A good example of a successful JWS application is JDiskReport (http://www.jgoodies.com/download/jdiskreport/jdiskreport.jnlp), a disk space analysis tool by Karsten Lentzsch, which is available on the Web for free.
Updating software through update sites is a path taken by both Integrated Development Environment (IDE) leaders, NetBeans and Eclipse. In short, once the software is initially installed, updates and new features can be downloaded from the application itself.
Both IDEs also propose an API to build applications.
This approach also handles all problems posed by the thin-client approach. However, like JWS, there's no strong trend to build applications based on these IDEs. This can probably be attributed to both IDEs using the OSGI standard whose goal is to address some of Java's shortcomings but at the price of complexity.
Therefore, having so many solutions available, could question the use of Vaadin instead of Flex or GWT? Let's first have a look at the state of the market for web application frameworks in Java, then detail what makes Vaadin so unique in this market.
Unfortunately, there is no clear leader for web applications. Some reasons include the following:
Most developers know how to develop plain old web applications, with enough Ajax added in order to make them usable by users.
GWT, although new and original, is still complex and needs seasoned developers in order to be effective.
From a Technical Lead or an IT Manager's point of view, this is a very fragmented market where it is hard to choose a solution that will meet users' requirements, as well as offering guarantees to be maintained in the years to come.
There is no need to learn different technology stacks, as the coding is solely in Java. The only thing to know beside Java is Vaadin's own API, which is easy to learn. This means:
The UI code is fully object-oriented
It is executed on the server side
Furthermore, the IDE's full power is in our hands with refactoring and code completion.
No plugin to install on the client's browser, ensuring all users that browse our application will be able to use it as-is.
As Vaadin uses GWT under the hood, it supports all browsers that the version of GWT also supports. Therefore, we can develop a Vaadin application without paying attention to the browsers and let GWT handle the differences. Our users will interact with our application in the same way, whether they use an outdated version (such as Firefox 3.5), or a niche browser (like Opera).
Moreover, Vaadin uses an abstraction over GWT so that the API is easier to use for developers. Also, note that Vaadin Ltd (the company) is part of GWT steering committee, which is a good sign for the future.
Finally, Vaadin conforms to standards such as HTML and CSS, making the technology future proof. For example, many applications created with Vaadin run seamlessly on mobile devices although they were not initially designed to do so.
In today's environment, integration features of a framework are very important, as normally every enterprise has rules about which framework is to be used in some context. Vaadin is about the presentation layer and runs on any servlet container capable environment.
A whole chapter (see Chapter 9, Creating and Extending Components and Widgets) is dedicated to the details of how Vaadin can be integrated with some third-party frameworks and tools. There are three integration levels possible which are as follows:
Level 1: out-of-the-box or available through an add-on, no effort required save reading the documentation
Level 2: more or less documented
Level 3: possible with effort
The following are examples of such frameworks and tools with their respective integration estimated effort:
Java Persistence API (JPA): JPA is the Java EE 5 standard for all things related to persistence. An add-on exists that lets us wire existing components to a JPA backend. Other persistence add-ons are available in the Vaadin directory, such as a container for Hibernate, one of the leading persistence frameworks available in the Java ecosystem.
A bunch of widget add-ons, such as tree tables, popup buttons, contextual menus, and many more.
Spring is a framework which is based on Inversion of Control (IoC) that is the de facto standard for Dependency Injection. Spring can easily be integrated with Vaadin, and different strategies are available for this.
Context Dependency Injection (CDI): CDI is an attempt at making IoC a standard on the Java EE platform. Whatever can be done with Spring can be done with CDI. Given that CDI is a standard, we will have a look of its integration with Vaadin in Chapter 8, Featured Add-ons.
Any GWT extensions such as Ext-GWT or Smart GWT can easily be integrated in Vaadin, as Vaadin is built upon GWT's own widgets. This will be seen in complete detail in Chapter 9, Creating and Extending Components and Widgets, where we will create such new components.
Vaadin provides an out-of-the-box integration with an important third-party platform: Liferay is an open source enterprise portal backed by Liferay Inc. Vaadin provides a specialized portlet that enables us to develop Vaadin applications as portlets that can be run on Liferay. Also, there is a widgetset management portlet provided by Vaadin, which deploys nicely into Liferay's Control Panel.
Although it is okay to use the latest technology for a personal or academic project, projects that have business objectives should just run and not be riddled with problems from third-party products. In particular, most managers may be wary when confronted by a new product (or even a new version), and developers should be too.
Product is of highest quality: The Vaadin team has done rigorous testing throughout their automated build process. Currently, it consists of more than 8,000 unit tests. Moreover, in order to guarantee full compatibility between versions, many (many!) tests execute pixel-level regression testing.
Commercial: Although completely committed to open source, Vaadin Limited offer commercial support for their product. Check their Pro Account offering.
User forums: A Vaadin user forum is available. Anyone registered can post questions and see them answered by a member of the team or of the community.
API: The server-side API is very stable, version after version, and has survived major client-engines rewrite. Some part of the API has been changed from v6 to v7, but it is still very easy to migrate.
Architecture: Vaadin's architecture favors abstraction and is at the root of it all.
Full-blown documentation available:
Product documentation: Vaadin's site provides three levels of documentation regarding Vaadin: a five-minute tutorial, a one-hour tutorial, and the famed Book of Vaadin.
API documentation: The Javadocs are available online; there is no need to build the project locally.
Huge community around the product: There is a community gathering, which is ever growing and actively using the product. There are plenty of blogs and articles online on Vaadin. Furthermore, there are already many enterprises using Vaadin for their applications.
Available competent resources: There are more and more people learning Vaadin. Moreover, if no developer is available, the framework can be learned in a few days.
Integration with existing product/platforms: Vaadin is built to be easily integrated with other products and platforms. The Book of Vaadin describes how to integrate with Liferay and Google App Engine.
Others already use Vaadin
Upon reading this, managers and developers alike should realize Vaadin is mature and is used on real-world applications around the world. If you still have any doubts, then you should check ://vaadin.com/who-is-using-vaadin and be assured that big businesses trusted Vaadin before you, and benefited from its advantages as well.
In this chapter, we saw the migration of application tiers in the software architecture between the client and the server.
We saw that each step resolved the problems in the previous architecture:
Client-server used the power of personal computers in order to decrease mainframe costs
Thin-clients resolved the deployment costs and delays
Thin-clients have numerous drawbacks. For the user, a lack of usability due to poor choice of controls, browser compatibility issues, and the navigation based on page flow; for the developer, many technologies to know.
As we are at the crossroad, there is no clear winner in all the solutions available: some only address a few of the problems, some aggravate them.
Vaadin is an original solution that tries to resolve many problems at once:
It provides rich controls
It uses GWT under the cover that addresses most browser compatibility issues
It has abstractions over the request response model, so that the model used is application-based and not page based
Now we can go on and create our first Vaadin application!