SOA way of life: a day in the GUI Shop
|
Following my open questions series to Jazoon'08, I will abandon |
![]() |
The GUI Shop
Asking through mailing lists and reading Internet blogs, you can
find an uncountable options to produce the front-end of J2EE
applications, including different platforms - J2ME, J2SE and J2EE - and
different technologies and frameworks on each of these platforms. It is
hard to say at first sight what is better, so let's start creating some
criteria to evaluate our options. First of all I will reduce the scope
of my search to web technologies (Desktop and Mobile technologies
deserve another blog entries).
- Price: I will only check the free stuff since
my project is open source. - SOAP 1.2 ready: the framework will consume
SOAP web-services, so it is naturall to expect some built-in feature to
communicate with soap. The minimum version that should be supported is
1.2, but a 2.0 support is a plus. - Tooling: the selected technology should allow
the automatic build of my web-application, specially using the tools I
have at home: scripts like Ant or Maven controlled by the common IDEs
like Eclipse and Netbeans. - Server friendly: the web technology should be
easily deployed in the most common open source servers, like Tomcat,
Glassfish and JBoss. Despite the candies offered by the server vendors,
I don't want to be locked in a server because they convinced me about
their fast development methodologies and proprietary frameworks.
After reading a lot of propaganda about web application
development frameworks, I finished with the following candidates:
- Grails: a very popular
framework supported by an enthusiastic community. The programming
language is groovy and it gets powered with the usage of some of the
large amount of available plugins. It works on top of Hibernate and
Spring, so be prepared for a lot of dependencies. Best if consumed with
Maven (IMHO). My preliminary attempts to run the helloworld proved the
weak support of the groovy language both in Eclipse and Netbeans. I
know there are paid plugins that can help, but to pay is not an option
- groovy seems to follow that lemma: simple things to solve
simple problems. - jMaki: Carol McDonald was also visiting the GUI Shop and brought me an impressive introduction to fast web 2.0 development based on jMaki. Good option.
- JRuby: after few years being
promoted as the prospective replacement of Java, Ruby language was ported to JVM and
for some strange reason it was not adopted as widely as we expected.
Nevertheless, the language is available in our virtual machine and
deserves a trial. The promise of very fast development of web
applications is very attractive, but I want to verify what it offers
beyond CRUD operations. - JSF: polemic
technology since it pushes the rendering of the view layer to the
server side. At first sight I would say it should perform worse than
its ultra-light competitors, but due to the good examples ( href='http://www.ibm.com/developerworks/edu/i-dw-r-jsfwebclient.html'>1, href='http://www.oracle.com/technology/products/jdev/101/howtos/jsfws/index.html'>2)
and excellent documentation on the web, I should include JSF as one of
my options. - JBoss Seam: I
included seam in my shop list because the impressive demos and natural
integration of the seam web-applications and j2ee applications. The
negative point seem to be a fear about the coupling between the
framework and the JBoss server, what matches my server friendly
constraint. I need to think better about that, because I found some
interesting articles on the Internet showing Boss Seam running on
Glassfish ( href='http://weblogs.java.net/blog/bleonard/archive/2006/06/running_jboss_s_1.html'>1,
href='http://weblogs.java.net/blog/caroljmcdonald/archive/2007/07/sample_applicat_1.html'>2).
So, if we can have the full power of Seam without locking the
application in the JBoss container, it is a first class option. - JavaFX: the
rich-client sector of the GUI Shop is full of colors and music, there
is also a big animated banner at the corner that says Applets
are back. I should confess that the idea of resurrection of my
school-time Applets is a nice dream. So I will include JavaFX and all
its open possibilities in my check list. FLEX would be another good
option, if the FLEX development tools were not paid :(
Shopping Cart - Checkout
Time to pick up a product and go home to try the new gift. As you
can notice above, there is no golden hammer in the web applications
market, but as any other buying stuff, you must select one. For today, I
will just enumerate my preference and discuss with my Jazoon pals about
that :) After the conference I plan to write a new blog entry with my
conclusions. If you ask me today, I would bet on JRuby, even more
because it comes with a nice free gift:
href='http://www.javapassion.com/rubyonrails/'>a free online course
starting on July :)
Remember: it is an open
discussion and not a formal product evaluation, it is based only on my
opinion and also on the discussion I read in my mailing lists. If you
remember some missed web-framework, please send to me and I will include
in the selection list.
- Printer-friendly version
- felipegaucho's blog
- 790 reads







Comments
by graemeroch - 2008-06-09 11:37
The first comment by jwenting is incorrect, Grails deploys onto any servlet 2.4+ container. See http://grails.org/Deploymentby rodrigolopes - 2008-06-09 04:03
I'd include FLEX (not Flash) in my list of options. Actually only the Flex Builder API is paid. And it's even free for students and non-profit projects. Although it's harder, you can use any editor to write your .mxml and .as files.by jwenting - 2008-06-09 03:52
"server friendly" would exclude Grails and possibly JRuby (not sure if that deploys at server level or will deploy within a web application). Seam works (logically) best with JBoss, may require more than Tomcat to work (mind, I've not tried it). JavaFX is unstable, and the license precludes its use unless you want to commit to the GPL (core components are GPL). Leaves only JSF, which may or may not be feasible if you want to support older application servers that might not support it (or only support older JSF implementations). It's also somewhat difficult to switch between JSF vendors/suppliers, which can make cross-server portability tricky.so you should ask yourself first and foremost where your priorities are in this. The smallest common denominator would be JSP with JSTL talking to your web services using JAX-RPC on a 1.4 JDK running Tomcat 4. Hardly interesting technology to attract developers to your project of course.
Or you could loosen your cross-server requirements somewhat and go for JSF 1.2 running on a Spring 2 layer using Spring WS. Would require a more modern server, and may not integrate seemlessly with every installation out there depending on the JSF implementations in use (and possibly other libraries).
by gkbrown - 2008-06-10 09:17
You may want to check out Pivot. We haven't officially launched yet, but we will soon:
https://pivot.dev.java.net/
Given your criteria, it may be a good fit:
by caroljmcdonald - 2008-06-13 11:18
I have an example of a JSF client calling a jax-ws webservice here http://weblogs.java.net/blog/caroljmcdonald/archive/2007/09/sample_appli... this sample app is also used in the javaone metro HOL here: http://developers.sun.com/learning/javaoneonline/j1lab.jsp?lab=LAB-3410&... The client was really easy to build , you can build a CRUD JSF client in a minute using netbeans, see this tutorial: http://www.netbeans.org/kb/61/web/jsf-jpa-crud-wizard.html I modified the generated code from Netbeans to make a prettier html table, then I modified the JSF managed bean controller to call a jax-ws to get the list of items instead of using JPA to get the list of items from the DB.