This document discusses the author's experiences using various technologies like EJB, Spring, Hibernate, GWT, JBoss, and others in a research environment. It outlines some of the ups and downs of each technology, including limitations of EJB for long-running computations, challenges stretching the limits of Hibernate's ORM capabilities, and difficulties migrating applications between versions of JBoss. The author also shares experiences developing the UI with GWT and ExtJS and issues that can arise from bugs in translated JavaScript code. Several figures are referenced but omitted due to prior publication.

1. The ups and downs of EJB, Spring,
Hibernate, GWT, JBoss and more
Experiences from a research
environment
by Csaba Toth

2. Used technologies
• Java language, Eclipse IDE, JUnit testing
• Based on OpenEMPI (Open Enterprise Master
Patient Index) so far:
– Maven make/build system
– EJB3 (Enterprise Java Beans 3)
– UI: GWT (Google Widget Toolkit) + ExtJS
– Spring for dependency injection and other
– ORM: Hibernate
– DB: PostgreSQL
– JBoss application server (based on Tomcat)

3. 3 tier architecture
• I had to remove the figure, because it was
submitted to a peer reviewed conference.
• Sorry 

4. GWT ExtJS UI and MVC
• I had to remove the figure, because it was
submitted to a peer reviewed conference.
• Sorry 

5. Pluggable Architecture
• I had to remove the figure, because it was
submitted to a peer reviewed conference.
• Sorry 

6. SOEMPI in action 1
• I had to remove the figure, because it was
submitted to a peer reviewed conference.
• Sorry 

7. Multi party protocol
• I had to remove the figure, because it was
submitted to a peer reviewed conference.
• Sorry 

8. More SOEMPI
• I had to remove the figure, because it was
submitted to a peer reviewed conference.
• Sorry 

9. Ups and downs: Hibernate ORM
• Binds existing schema to an existing class
• Covers SQL differences between different
RDBMS
• Natural handling of data with Java
• Widely accepted and known
• Drawback: fixed schema and existing classes
• Configuration can come from xml file or
source code annotations

10. Stretching the limits: Hibernate
• Problem 1: even if there is an existing class with a schema, if we
have multiple instances of DB tables which matches the schema, we
can only bind one of them to the class (so if we’d force one schema
to all incoming dataset, we still have this problem)
• It is possible to load data from any table to a certain class which
fulfills a schema; showed by James Cowan:
Query q =
hibernateTemplate.getSessionFactory().getCurrentSession().createSQL
Query(sql1).addScalar("entryDate",
Hibernate.DATE).addScalar("dataType",
Hibernate.STRING).addScalar("description",
Hibernate.STRING).addScalar("value",
Hibernate.TEXT).setResultTransformer(Transformers.aliasToBean(Custo
mViewBean.class));
List<CustomViewBean> list = q.list();
• Problem: it only solves the read problem, how will we write?
• We’d still force one fixed schema

11. Stretching the limits: Hibernate
• Hibernate configuration can come from xml file or
source code annotations
• Then Hibernate builds it’s internal structures
• What if we try to manipulate these data
– Can be dangerous
– But certainly possible. Should look at Spring Grail’s
source, they must do such thing
– What advantages we get from Hibernate that we want to
stick that much to it? Platform (RDBMS) independence
– Even if we fiddle the internal configuration, we won’t have
a corresponding class. Should we write a corresponding
class file, compile it and than classload it?

12. Stretching the limits: Map
• Going “totally dynamic”
– Use Spring JDBC layer
– Use a DynaBean/Record like infrastructure: Map<String,Object>
collection of attributes, totally dynamic
– Probably Spring JDBC wrapper will be good
– We won’t be as RDBMS independent as Hibernate
– Record class will have performance impact opposed to a totally regular
and native class
• Cons
– An own maintained Map won’t be compatible with other techniques
like JavaBean or DynaBean
– Performance impact of the Map

13. Stretching the limits: persisting
dynamic Beans
• Is there any persistence support for JavaBeans in
Hibernate? How is it done?
• Pros:
– Would be compatible solution
– We could still leverage Hibernate in full
– Ideally uses reflection instead of Map => faster
• Cons:
– Experimental, according to Hibernate doc
– DynaBean got ripped out from Hibernate
– Doubts about BLOB field support

14. Ups and downs: EJB (and some Spring)
• Best suited for stateless web queries
– Each call is well isolated for the other one (this is
extremely important in case of banking software)
– Queries usually return within a reasonable time
• Record linkage:
– Requires long computations
– Co-operation between parallel EJB calls

15. Limits of EJB: long running
computations
• Asynchronous EJB
– Container (EJB/EAR container like JBoss) specific for earlier
versions of EJB standard – and couldn’t get to work
– For newer standard you need fairly new containers
• Java Messaging: probably not secure enough for our
purpose
• Periodic polling
– Kind of anti-pattern
– But it works
– Also important with respect to EJB thread collaboration
(see next): until the EJB call returns the DB calls are not
persisted

16. Limits of EJB/Spring: collaboration of
simultaneous calls
• Two calls should be paired and matched at some
point: they should share some information
– Spring Global context: anti pattern – and couldn’t get
to work
– Persisting the data we want to share
• Would be needed anyway
• Can raise security concerns with crypto protocols (persisting
a nonce for e.g.)
• It won’t appear in the DB anyway until the call returns, plus
there’s the Hibernate caching too

17. Ups and downs: Spring
• Dependency Injection – OK
– But what if you don’t know at configuration time
how many services you’ll need. You want to
spawn a new instance of a service =>
– Running into another anti-pattern

18. Ups and downs: GWT + Ext JS
• You can write all your GUI in Java
• Don’t have to deal with any JavaScript or HTML or
CSS
• Still looks like the most modern UI (see Sencha
examples)
• Problem can come if you have some bug:
– The client side Java code is translated into JavaScript
=>
– You’ll have the NullPointer exception in the obscure
compressed JavaScript library

19. Ups and downs: JBoss
• Said to be much lighter weight than other
containers like WebSphere
• One would expect to simply migrate the EAR
from JBoss 4.2.3 to JBoss 5.1.0 – Nope
• Important to secure consoles, JMX console
– XML configuration file mangling
• Securing EJB communication with SSL
– XML configuration file mangling