GWT VS Wicket

Posted by: Eelco Hillenius on janvier 30, 2008 in response to Message #246495 (www.theserverside.com)


First of all, I feel the frameworks or close to each other because they are good options for scaling your development effort. They both focus on providing a pure OO Java programing model. Imho, both are a good choice, and you should look what works best for your particular situation.

GWT is Ajax only, keeps state on the client and works with layout managers. Wicket supports both Ajax and a traditional model (mix however you like), keeps state on the server and works with templates rather than layout managers (though you could completely abstract this and hide the markup if you really wanted).

Plenty of pros and cons to both.

For instance, keeping state on the client obviously makes clustering easier. But you won't take advantage of locality, run into problems (or at least inefficiencies) when using ORM tools like Hibernate, and you'll have to very thoroughly think through the security implications of having state on the client and communicating that with the server.

Layout managers... On the one hand it is nice to have that ugly HTML and CSS abstracted for you. On the other hand, your design mockups are more removed from your end-code, and it will be more difficult to hire separate designers to do the layout part for you. Also, customizing layout managers may be more painful than just writing straightforward markup yourself.

You have to decide whether Ajax-only works for you. For the site that I'm building, which targets tens of thousands of users in very diverse environments, we choose not to take the risk of running into problems with old browser versions, zealous administrators, etc. Also, if you need your site to be indexed and have parts of it bookmarkable, Wicket is a better choice. But if you're going Ajax all the way, GWT might be better at certain things.

Another thing Wicket is very good at - better than any other framework I know - is support for localization. In GWT this was implemented as an afterthought, though it might be good by now (I haven't looked at GWT for over a year).

This comparison can go on for a while, but I'm out of time :-) Like I said, I think both frameworks are good choices, so if you have time to look at them both, you should (buy GWT In Action and Wicket In Action :-) ). And don't forget to ask around for people who actually worked with the frameworks and ask how they liked it.

Eclipse SOA: Project SwordFish

Submitted by mog on Thu, 2008/01/17 - 6:33pm.(JavaLobby)

Eclipse is trying to develop an open source Service Oriented Architecture (SOA) framework based on technology contributed by Deutsche Post World Net.
Nicknamed Swordfish, the Eclipse project is meant to result in widgetry used in developing and deploying a wide swath of software from embedded programs to enterprise applications.
In this respect, its goal is different from existing SOA environments most of which are targeted at just the enterprise environment and require a good deal of memory and processing resources.
The Swordfish Project takes a different approach and figures all components could be potentially replaced by alternatives with smaller footprints as good for the enterprise as for resource-restricted embedded and mobile devices.
Anyway, Swordfish 1.0 is supposed to be out by the end of Q3. But other than the base code, the project has so far only come up with a logo and little else. And there’s a lot left to do.
Deutsche Post kick-started the project by contributing its Service Backbone code for the initial framework as well as a messaging plug-in, a service discovery plug-in and a management plug-in.
It is being moved to Eclipse’s Open Services Gateway Initiative (OSGi) so it can also take advantage of Eclipse’s Service Component Architecture (SCA) and Java Business Integration (JBI).
These technologies will make Swordfish usable for server-side applications.
Swordfish will be the first attempt to implement both the SCA and JBI SOA standards, which have to date been politically competitive, the first advanced by IBM and the second by Sun. Swordfish could use them for complementary purposes.
The project, which pushes Eclipse further into the server side, was initiated by a German SOA start-up called Sopera GmbH.
Sopera co-managing director Ricco Deutscher remarks that the Deutsche Post code is mature, having been used for the last six years by the huge logistics company.
Swordfish could be a complete SOA framework with the addition of either open source or commercial messaging, BPEL, security and registry.

Why are we not using Java EE 5?

Submitted by agoncal on Tue, 2008/01/29 - 4:53pm. (JavaLobby)

Believe it or not, in a few months the Java EE 5 specification will be two years old (Final Release on the 11 May, 2006). And nobody is using it.
We have all read about how easier the development model is in Java EE 5 compared to J2EE 1.4. Complexity reduced, less XML file descriptors, less code, injection and so on. Despite all these good things, Java EE 5 projects are not taking off. Here are some reasons why :
Java EE 5 is a rupture more than a continuity. J2EE 1.4 and Java EE 5 are really different. That means development teams have to be trained to something new and develop new projects leaving behind years of EJB CMP or JAX-RPC. Some teams have invested a lot in J2EE 1.4 and are willing to wait a little bit more and see. And what if Java EE 6 is another big rupture again ?
Java EE 5 is based on Java SE 5 (heavy use of annotations). But JDK 1.4 is still widely use in projects, making it impossible to migrate to Java EE 5
Even if Java EE 5 is much simpler than its predecessors, it is still too complicated and has many specifications. With profiling in Java EE 6 the number of specs will be reduced, but until now, to be Java EE 5 compliant, application servers have to implement 23 specifications.
Today the application server race is completely different from few years ago.Websphere is the number one for big projects and, as usual, is late and is still not Java EE 5 compatible. On the other hand, just when companies had started to use open source with JBoss, JBoss has left the race and version 5 is still in beta.Weblogic, the very innovative company (you should look at Weblogic Virtual Edition) has been bought by Oracle. God knows what will happen. GlassFish is by far the best open source Java EE 5 app server. But people still don't know it well. And if some do, they immediately remember the previous reference implementations made by Sun (the ones used to play with the Java Petstore) that were not usable for real life project. GlassFish is.
Many simpler frameworks arrived before Java EE 5 and took over. Of course there is Struts. JSF came after with a different development model but it is so different from Struts that projects don't want to invest on it. Axis and XFire brought a nice way to develop web services while J2EE was still struggling with JAX-RPCand JAXR. JAX-WS with JAXB 2 are great but arrived too late. Hibernate while we were mesmerised by EJB 2.1 CMP complexity. And of course, Spring which has become a serious Java EE competitor. It is lightweight, lets you do plenty of what Java EE does, so why make the move?
To make it more blurred in developers' minds, most of these open source framework are now implementing some Java EE 5 specifications. For example, Hibernate implements JPA now (even if it does more). And because Hibernate was here before JPA, a developer using annotation and an EntityManager will still say that he/she develops with Hibernate, not JPA. Same thing for Axis implementing JAX-WS now. How frustrating is that ?
Some words have become evil. “EJB“ for example. No matter how much easier EJB 3 is, it‘s still called an “EJB“ and that reminds us of bad memories because we remember Home/Remote interfaces, Bean classes with empty methods, XML files and JNDI lookups with narrowing, difficulties with testing… Another word issue is the “Entity Bean“ one. We all remember the Entity Bean 2.1 nightmare (heavyweight and over complicated). Unfortunately, JPA kept the name “Entity“ when talking about a persistent object. The word “Entity“ is too close to “Entity Beans” and that scares developers.
Talking about how words can have an impact on you, the naming used by Sundidn't help either. Nobody knows what they are talking about and they get confused with J2EE 1.4, Java EE 5, JDK 1.5, Java 5, Java SE 5. So when you arrive at a job interview and say “I‘m a Java EE 5 expert”, one will turn to you saying that you are not up to date because they use Java 6 and not Java 5.
The definition of Java EE has been completely twisted. Tomcat is seen as Java EE. Look at the job ads and you will see : "looking for a Java EE expert who knows Tomcat, Spring, Hibernate"... hum, no Java EE in there. Again, EE 6 profiling will make these things clearer, but until then, Tomcat is not a Java EE 5 app server.
Testing a Java EE 5 application is definitely not as easy as a Spring application. We live in a world where everybody talks about test, but nobody really does it. Java EE 5 doesn‘t help in this aspect.
Conclusion : some aspects of Java EE 5 are still not at their best (testing, injection could be better, JPA still has to get richer, JSF model is a bit complex..), but the overall is that Java EE 5 is definitely much easier than its predecessor, J2EE 1.4. Projects that are using Spring might not see the benefit of Java EE 5. Except that these big projects are all using Spring within an app server (for clustering and performance issues). Upgrade your app server and start developing some EJB 3.0. You‘ll see how easy it is (and you can even combine Spring and EJB). For projects in J2EE 1.4, well, if you use Websphere, you are stuck, for the others, upgrade your app server (Weblogic 10, GlassFish 2…) and develop your new projects with Java EE 5. It is backward compatible and you can call an EJB 3 from an EJB 2.1. Do not migrate yet, just let both versions co-exist.
And you, why don't you use Java EE 5 yet ?