The ups and downs of EJB, Spring, Hibernate, GWT, JBoss and more

Experiences from a research environmentby Csaba Toth

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 tier architecture

• I had to remove the figure, because it was submitted to a peer reviewed conference.

• Sorry

GWT ExtJS UI and MVC

• I had to remove the figure, because it was submitted to a peer reviewed conference.

• Sorry

Pluggable Architecture

• I had to remove the figure, because it was submitted to a peer reviewed conference.

• Sorry

SOEMPI in action 1

• I had to remove the figure, because it was submitted to a peer reviewed conference.

• Sorry

Multi party protocol

• I had to remove the figure, because it was submitted to a peer reviewed conference.

• Sorry

More SOEMPI

• I had to remove the figure, because it was submitted to a peer reviewed conference.

• Sorry

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

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().createSQLQuery(sql1).addScalar("entryDate", Hibernate.DATE).addScalar("dataType", Hibernate.STRING).addScalar("description", Hibernate.STRING).addScalar("value", Hibernate.TEXT).setResultTransformer(Transformers.aliasToBean(CustomViewBean.class));

List<CustomViewBean> list = q.list();

• Problem: it only solves the read problem, how will we write?• We’d still force one fixed schema

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?

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

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

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

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

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

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

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

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