The Source for Java Technology Collaboration
User: Password:



Felipe Gaucho's Blog

June 2008 Archives


SOA way of life: a day in the GUI Shop

Posted by felipegaucho on June 09, 2008 at 03:08 AM | Permalink | Comments (5)

Following my open questions series to Jazoon'08, I will abandon my server roots for a moment and I will visit the the GUI programming - a joy I usually delegate to other people but I must confess that also has it goodies. Preparing for the conference, I am applying an extra effort on my open source Cejug-Classifieds, a J2EE application that uses a JAXWS SOAP WebService as business facade. You can visit our home-page to check the complete information Cejug-Classifieds, but its main components can be illustrated in the collaboration diagram below. I have a EJB J2EE component that encapsulates the business logic, and I have a set of JAXWS web-services that expose the Session Facade methods of the EJB module in format of SOAP messages. The first two components are under development and some features can already be tested through the available functional tests. The problem is we don't have anyone working on the end user GUI - the web-services client - and that's why we decided to visit a GUI Shop.

collaboration.PNG

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).

  1. Price: I will only check the free stuff since my project is open source.
  2. 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.
  3. 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.
  4. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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 (1,2) and excellent documentation on the web, I should include JSF as one of my options.
  5. 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 (1, 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.
  6. 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: 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.



Should I use EJB3 as web-services?

Posted by felipegaucho on June 02, 2008 at 01:49 AM | Permalink | Comments (4)

More than a community and business event, Jazoon'08 offers you a chance to discuss technology free of pressure. You can meet the top evangelists and share with international developers your technical issues and questions - a pervasive brain storm about the Java platform. Excellent opportunity to validate your ideas on how to do better software - and if they don't survive the community's scrutiny, you can always blame the beers and back home with good learned lessons :).

I have my own set of (Not So) Stupid Questions, and the first one I want to discuss with you is about web-services and EJB3.

glassfishday-jazoon-button160x64.png

Is it a good design to expose EJB3 Session Facade as web-services?

Reading patterns and examples on the Internet, EJB3 + @WebService seem to be a fast and furious way to go straight to SOA with few lines of code and a good container. Despite the simplicity of annotations, I started designing an Open Source Classifieds system based on J2EE technologies and I have some observations about that.

Instead of replicating here all discussions about web-services design and its technology support, I prefer to bring you a few design options and get your feedback live during Jazoon.

  1. Web Client -> JAXWS SOAP web-services -> Session Facade -> Domain Model Facade -> @Entities
  2. Web Client -> @WebService Session Facade -> Domain Model Facade -> @Entities
  3. Web Client -> @WebService Session Facade -> @Entities

Some considerations about the above design options:

  • If I use annotations, I am assuming SOAP web-services, right? And what about REST?
  • If I do expose my Session Facade directly, how can I change later my interface from SOAP web-service to something else ?
  • What about validation and security? My business component should care about data input validation and authorization and authentication?
  • Load balance and orchestration. Can I use a web server (Tomcat?) to expose the service interface and a j2ee container to do the business? What about service collaboration? The session beans will have references one to each other?

Using a same class to expose services interface and realizing business use cases seems a bit overlapped to me, but eventually I am missing some point here. It is up to you, see you in Zürich :)





Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds