Seam and Flex by Shashank Tiwari
Wednesday 11 July 2007
JBoss Seam and Adobe Flex are two promising technologies. Seam makes it easy to build stateful web applications. It integrates the Java EE frameworks together. Flex is a great rich application development framework. The question is can they and should they be used together?
Seam till its 1.x versions used JSF as the main UI framework. This implied that it was built around a server side UI model. Flex on the contrary is a client side UI framework. Oops! so we have a big disconnect right away! Not really, there possibly are some viable options to make them work together. In the latest version of Seam 2.0.0 BETA the coupling with JSF has been loosened. Also, in the past its been demonstrated that JavaScript UIs (built on frameworks like DOJO or any other) could directly remote to Seam server side components. Remember though that JavaScript runs within the browser whereas Flex applications runs within the Flash VM. Does that matter?One option is to have Flex as the front end and make Flex components remote to Seam? Technically this is a possibility and may be good in situations where Flex is used as a pure view description technology. In fact has anybody wondered writing a JSF render kit for Flex? That would be one nice looking but ugly under the hood hack. The state and event management would be all mixed up and one would end up writing more wiring to save the two together than use in isolation. I know some of you may oppose this thought and may cite cases where you have used Applets as a face for Servlets or similar server side technologies. Yes it works, is it elegant though? And what were the big wins of making them work together anyway? This the same question I ask when I read articles that claim that Spring MVC can work smoothly with Flex and Java Portlets can work effortlessly with Flex. Is it better to make complicated applications by spending more time and energy as opposed to building clean applications faster? In other words is it better to do the right thing or focus on making everyone happy?
So what does it mean in the context of our main exploration of making Seam and Flex work together? We have looked at the dry option of remoting a Flex face to a Seam server side. We could possibly liven it up by managing state on both sides - client and server - and introduce something that could be called a State Transfer Object (STO) to transfer the state information back and forth. Doesn’t sound good! It reminds me of the pain of using DTOs. Is there any other option? My answer is that I don’t know of one yet. I am trying to write a bridge between the two, following the principle of delegation and inclusion of common contexts wherever possible and ofcourse cheating (oh sorry! drawing inspiration) from the JavaScript remoting integration and the GWT integration in the Seam code base. If and when its ready, it would show up as an open source tool for everybody to play with and I will annouce its arrival. BTW, if anyone else here is interested in hacking that with me, you are most welcome to join in. In the meanwhile I would certainly like to hear your experiences in making these two work together. Both real life experiences and armchair musing are welcome.
Before I end this post, it may be important to discuss the “should they be used together” part of the question. Seam integrates the parts that make up Java EE very well. EJB3 components and POJOs are available as transactional components within stateful contexts. The programming model is simplified with the use of annotations. Integration with persistence architectures is really cool - I wish like with JSF, I could validate my form input on the Flex screen using Hibernate Validators or directly bind Flex component and control properties or instances to EJB3 entity beans.
With Seam there are lesser number of those XML files and template configurations to handle, as opposed to others, say Spring, where they are in abundance. Plus the biggest benefit is that you don’t have to learn a new framework really, most of what Seam uses is standard Java EE - EJB3, expression language, annotations, etc…..
Flex creates really elegant user interfaces. The best part is one can create them really quickly. Last week I hacked a fairly functional prototype for a reporting and charting application in 2 days - I can never do that with any other technology - not even with Ruby on Rails. Even if I can it would never look so nice and be functional. Part of the speed is surely attributed to the FlexBuilder eclipse plugin and it takes a lot more effort before such an application can go to production.
To summarize, both are great technologies. Also, though they overlap in many places they clearly have their strengths in different areas.
Theoretically bringing them together implies a beautiful face and smooth controls to a powerful engine — Tell me who would not want to drive such a machine?
Posted on O'Reilly Blog
Posted byEugene at 02:08