Swing for Web?

java Open Source AJAX-based Web frameworks. Evaluation Results

We specified the requirements for the Open Source Java Web frameworks used in presentation layer of Enterprise Web Applications:

1. Performance.

2. Modal dialogs.

3. Partial page refresh.

4. Component-based and event-driven.

The philosophy should be: a Web application should behave like a desktop application, and it should be developed like a desktop application.

Is it possible to satisfy all those requirements? How much will we have to pay for the convenience and flexibility - with performance loss (which translates into higher hardware cost)?

For example, explicit representation of the complex UI state on the server should affect performance and scalability. Partial page refresh means busy traffic between the client and server, which also should affect performance.

To answer those questions, we performed evaluation and performance tests of the existing Web frameworks.

To meet our performance and usability requirements, a Web framework has to be AJAX-based, e.g. all components have to use AJAX for partial page refresh. Most Web frameworks are AJAX-enabled, e.g. only part of the framework components use AJAX for partial page refresh.

We evaluated the following component-based frameworks: SwingWeb, WebOnSwing, Wicket, wingS, Echo2, Oracle ADF Faces, ZK. For evaluation reports, see our previous posts.

SwingWeb, WebOnSwing, Wicket, wingS are not AJAX-based.

Oracle ADF Faces: for 30 simultaneous active users, Tomcat reported an error (consequence of the thread contentions).

ZK: the zkdemo-all.war application can not handle 40 simultaneous active users (CPU overload, max response time is too big). Multiple thread contentions reported.

Echo2 is AJAX-based, supports modal dialogs, is component-based and event-driven. Echo2 also has a very good performance. So, Echo2 is so far the only framework which passed our requirements.

Does this mean that Echo2 will eventually become de-facto industry standard for Web frameworks (replacing Struts)?

We don't think so.

There are several problems with Echo2. They are all related to one issue: Echo2 has a Swing-like API. Or let's refrase it: it does not have Swing API, although it could. This brings us to a very important evaluation criteria: tools support. NextApp, Inc. (a company behind the Echo2) sells EchoStudio2, which is a plugin for Eclipse. EchoStudio2 is not a WYSIWYG tool. Since Echo2 API is not standard, and the framework is not widespread, tool vendors are not developing visual editors for it. Also, using Echo2 API means for a developer one more API he has to learn.

If Echo2 would use Swing API (like SwingWeb, WebOnSwing do), it would bring the following advantages:

- developers could use many existing commercial or free java IDEs to visually develop dialogs (every java IDE has Swing editor);

- it would be possible to have a single code base for desktop and Web applications. This is a dream for many ISVs who have both desktop and Web applications with the same forms. It would make possible tricks like dropping Swing application JAR file into Web container and rendering it as a Web application (like SwingWeb does).   

- familiar API: if you know Swing, you can develop Web applications. For java developer, that would also help to answer positively on another evaluation question: "If you know this framework, will it help you to find a job?".

We understand that NextApp makes money selling EchoStudio2, and if they changed Echo2 to use Swing API, nobody would buy EchoStudio2. So, it is not in their business interests.

If Echo2 is not an ideal Web framework, then is it possible to create one?

Yes!

SwingWeb and WebOnSwing proved that it is possible to render Swing application as a Web application, but have a poor performance. Echo2 proved that Swing-like Web application with explicit representation of the complex UI state on the server can have a very good performance.

The task is to merge those frameworks. After all, they are all open source frameworks. No need to write anything from scratch. I would estimate that it would take three man-year (pessimistic) to do this.

Who could do this?

1. A big ISV/ERP vendor with existing vertical applications (Oracle, SAP?).

2. A big java tool vendor (Oracle, IBM?).

3. A big AJAX-tool vendor (Yahoo, Google?).

The upshot for such a vendor would be to have a growing ecosystem around their products/services, fulfilling the whole product requirement: thousands of developers would use their framework and components to customize their applications, to develop third-party applications and extensions, to access their services. 

The winning framework might become a part of the open source software stack (JBoss?).

The easiest way for them to do this would be to have the NextApp developers modify Echo2: buy NextApp or license Echo2 (remember Oracle licensing JBuilder and developing JDeveloper?).

If someone prefers defining UI using XML, they should use JAXX + Echo3 (Echo3 = Echo2 with Swing API). Using JAXX for UI definition is similar to using Windows resource files for dialog templates, menus, images, strings etc.

Well, if you need to choose a Web framework now, what should you do?

Our suggestion: use Echo2; make sure your business logic is well separated from the UI code, so that when a new winner with Swing API emerges, you can migrate without a big pain. Isolating the rest of your code from UI should be fairly easy: since Echo2 is event-driven, most of the interaction happens in event handlers.   

There are also more questions to be answered regarding Echo2:

1. Is it possible to optionally support non-sticky clustering?

2. Server Push is required for workflow applications. How will it affect the performance of the application? Do we need to develop a custom Echo2 component (see How server push should NOT be used)?

3. How Echo2+Spring+Hibernate combination will perform? We need to test performance of the HSE framework.

Related links:

Java Web Frameworks by Matt Raible

Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers (Paperback) by Geoffrey A. Moore

Permalink