Ups and downs of enterprise Java app in a research setting

1,308 views
1,215 views

Published on

SOEMPI's experiences for NJUG

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,308
On SlideShare
0
From Embeds
0
Number of Embeds
63
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ups and downs of enterprise Java app in a research setting

  1. 1. The ups and downs of EJB, Spring, Hibernate, GWT, JBoss and more Experiences from a research environment by Csaba Toth
  2. 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. 3 tier architecture• I had to remove the figure, because it was submitted to a peer reviewed conference.• Sorry 
  4. 4. GWT ExtJS UI and MVC• I had to remove the figure, because it was submitted to a peer reviewed conference.• Sorry 
  5. 5. Pluggable Architecture• I had to remove the figure, because it was submitted to a peer reviewed conference.• Sorry 
  6. 6. SOEMPI in action 1• I had to remove the figure, because it was submitted to a peer reviewed conference.• Sorry 
  7. 7. Multi party protocol• I had to remove the figure, because it was submitted to a peer reviewed conference.• Sorry 
  8. 8. More SOEMPI• I had to remove the figure, because it was submitted to a peer reviewed conference.• Sorry 
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×