Meeraj Kunnumpurath's Blog

TSS Symposium Europe - Day 1

The symposium kicked of with a keynote session by John Davies, the CTO of C24. John’s address mainly covered the choice of technology stack in the investment-banking sector. It was heartening to hear finally Jini and JavaSpaces are being adopted as a mainstream technology for realising enterprise middleware. John also mentioned the increasing acceptance of open source software like Maven, Spring and Hibernate in the banking arena. Maven is increasingly becoming the build tool of choice, despite the criticisms by most who have never had the good fortune of using it and just want to jump on the bandwagon on whining about how complex Maven is. It was also interesting to hear how big investment banks are shying away from full-stack J2EE containers and instead using Tomcat along the lightweight persistent frameworks. We will have to wait and see whether this trend would be reversed with the adoption of JEE 5.0 and EJB 3.0. Another interesting point was that Java 5 is being adopted for the performance gains more than the new language and API features.

The next session I attended was by Geert Bevin on flow and continuations. Geert did a good job explaining continuations at a conceptual level. It is a quite powerful concept and quite affective for complex control logic that is difficult to solve with primitive control constructs available in modern programming languages. Geert , then showed how continuations were implemented in the RIFE web application framework. It was interesting how RIFE implemented pause and continuation by byte-code amendment and taking a snapshot of the stack frame. I am not sure how efficient this is. It would also be interesting to see whether a future version of Java language would have language level support for continuations.

Next session was something I was eagerly waiting for, Gavin King’s session on Seam. I was a bit disappointed with the session as a whole, as Gavin spent half of the session on how flawed was the whole concept of stateless architecture and criticising dependency injection and some of the popular DI frameworks. Al though, some of Gavin’s arguments were valid and interesting, the point on HTTP session replication and the Servlet specification mandating a call to setAttribute to enable session replication was factually incorrect. Though, I have always had the same opinion on developers being concerned about using stateful session beans, because of state replication overheads in a cluster, however having no inhibitions in dumping everything and the kitchen sink into the HTTP session. All in all, Seam appeared to be an interesting framework for integrating JSF and EJB component models with a heavy emphasis on stateful session beans.

Mike Keith presented a session on EJB 3.0. It was more on the component model rather than JPA. I am not sure I quite like this concept of being able to inject only certain kind of references into only managed components like EJBs, Servlets etc. This will encourage the developers to write everything as an EJB or a Servlet. I am looking forward to Mike’s session on JPA tomorrow.

I was really in two minds about whether to go for Gregor Hohpe’s session on SOA or Ross Mason’s session on Mule. Finally, ended up at Ross’s session because of the recent work I have been doing with Mule. The session was pretty basic, didn’t get to know much more than what I already knew. However, had an interesting chat with Ross on roadmap for Mule.

Last session for the day was by Cedric Beust on TestNG. Junit has revolutionized the way we test in the last five years or so. It has been a wonderful framework. However, it has also shaped our psychology and mindset on jow we do testing. This is more of the fault of us using JUnit for something it was not intended for. Junit is a unit-testing framework and by design has an extremely stateless paradigm for testing. This doesn’t really fit into the more complex requirements of functional, component-level and system testing. To test a complex piece of functionality you often need to execute a set of tests in a stateful context, and this is what TestNG offers. Cedric’s session was the best of the day. It was quiet relieving that TestNG annotations can use either Java 5 or Javadoc tags for JDK 1.4.

Comments

• "the Servlet specification mandating a call to setAttribute to enable session replication was factually incorrect." The servlet specification is silent on clustering and replication. However, in most actual real servlet engines, the call to setAttribute() is required in a clustered environment. In fact, AFAIK, JBoss is the only widely used server where it is not necessary to call setAttribute() to ensure replication. You can buy addon products for other servers, but to the best of my knowledge none of them implement this by out-of-the-box. I'm sure someone will correct me if I'm wrong on this. But my argument is a lot more subtle than you have made out. I am not arguing for the use of SFSBs primarily on the basis that they can be more efficient than HttpSession (though they can be) or more robust than HttpSession (though they are). Rather, I my argument is that they offer a much more elegant, more object-oriented construct than JavaBeans-in-HttpSession and that, contrary to popular belief they are _not_ less scalable.

  Posted by: gavinking on June 21, 2006 at 05:36 PM

• Ugh, let me try again with formatting:
  "the Servlet specification mandating a call to setAttribute to enable session replication was factually incorrect." The servlet specification is silent on clustering and replication. However, in most actual real servlet engines, the call to setAttribute() is required in a clustered environment. In fact, AFAIK, JBoss is the only widely used server where it is not necessary to call setAttribute() to ensure replication. You can buy addon products for other servers, but to the best of my knowledge none of them implement this by out-of-the-box. I'm sure someone will correct me if I'm wrong on this. But my argument is a lot more subtle than you have made out. I am not arguing for the use of SFSBs primarily on the basis that they can be more efficient than HttpSession (though they can be) or more robust than HttpSession (though they are). Rather, I my argument is that they offer a much more elegant, more object-oriented construct than JavaBeans-in-HttpSession and that, contrary to popular belief, they are _not_ less scalable.

  Posted by: gavinking on June 21, 2006 at 05:37 PM

• OK, someone just reminded me that Tomcat has an option to ALWAYS replicate all attributes at the end of each request. This is of course totally unscalable and unusable in practice. But it does save you from having to call setAttribute() ;-) But in any decent SFSB implementation, the container tracks dirtyness and replicates exactly when needed. Again, this is a kinda peripheral issue to my whole reason for wanting to use SFSBs, which is more to do with having an elegant programming model.

  Posted by: gavinking on June 21, 2006 at 05:59 PM

• Hi Meeraj, glad to hear that you found my talk on continuations interesting. Just a minor remark though, my name is Geert and not Geet. You forgot the 'r' several times. Best regards, Geert

  Posted by: gbevin on June 21, 2006 at 11:14 PM

This work is licensed under a Creative Commons License.