Is SpringSource Working On EJB 3.1 Container?

It seems like SpringSource is working on EJB 3.1 implementation. This makes EJB 3 technology even more interesting and proofs its adoption. The Spring framework then would be "Just Another EJB Container On Steroids" (JAEC :-)) - it would make, however, the integration between EJB 3 and Spring easier, than even now. This lowers the entry barrier for EJB 3 as well: the migration to pure Spring environment, in case EJB 3 wouldn't be sufficient for functional, or non-functional requirements, should be not that hard.

This is actually the second EJB-container implemented by SpringSource. Pitchfork can be used right now, I'm already curious about the new one. So EJB 3 became interesting enough to be supported by ... the spring container. EJB 3 could be deployed then on: Glassfish, JBoss, Geronimo, WebLogic/Oracle, WebSphere SAP, and Spring as possible deployment platform.

EJB3 - annotations vs xml - And Probability Driven Decision, Best Practices

EJB 3 beans can be configured with annotations in Java Code, Deployment Descriptors in ejb-jar.xml and a mix of both of them. An interesting post tries to answer the question for which case what option should be used. In my Java EE 5 projects, however, I went another path and thought about probability of change and worse case scenarios. If something is not likely to be changed, I put it into an annotation. Rather instable configuration was extracted into ejb-jar.xml. Some examples:

1. JPA-DataSource - no problem here, it is already configured in persistence.xml - this is a good idea.
2. Injection of EntityManager with @PersistenceContext: in bigger project it is a good idea to specify the unitName explicitly, because it is likely to have more than one persistence-units. Otherwise the introduction of an additional EntityManager would break the code. It isn't a huge problem, but can cost some hours. I wouldn't resolve the unitNames in ejb-jar.xml in addition - the names are stable enough.
3. Dependency Injection between Beans: in 99% of all cases I'm relying on annotations and conventions - except the DI is used as a "configurable factory", where different implementations of the same interface has to be injected. This is not the common case.
   
4. Transaction: it is a good idea to configure them with code - this documents the principle in code - there should be no surprises.
5. Security roles: even security roles were in my projects either not existent (because the EJB 3 security model wasn't flexible enough), or statically configured in security. The roles were stable, but the association between the roles and the users varies in general.
6. Interceptors: I configured them mostly with annotations, except for interceptors which were only relevant for the development cycle, like debugging or tracing. It is better to document the interceptors with annotations, rather than with JavaDoc :-).
   
7. Injection of JMS, JDBC resources etc: this depends on the operations. If the application server is in your control, I would even use mappedNames / JNDI-names in code - there is actually no reason to introduce another level of indirection. In case your application is deployed by operations (another department), XML-configuration is better idea. The biggest problem here: collision of JNDI-names on multi-project servers.
8. General configuration with primitive values: it doesn't makes sense to hardcode them. If you need to configure some primitive attributes - use ejb-jar.xml. I didn't used this feature, and used mostly the database for configuration purposes.
   

In vast majority we relied on annotations - which saved us a lot of time. We used XML-configuration only in few projects for configurable monitoring and additional "nice to have" services. It worked really well - most of the applications are already in production, there were no problems so far. But it really dependends on your projects / situation. In EJB 3 you have all options, from very lean and pragmatic, to flexible but more work intensive. The most important questions are:

1. What happens, in case you hardcoded your decisions and it will change in worst case?
2. Is it worth to protect a certain variation externalizing it into XML?
3. How likely are changes in certain areas? What's your experience in the last projects?
   

Do JPA Entities Have To Be java.io.Serializable?

It's a kind of unwritten wisdom to mark all JPA-entities as java.io.Serializable. This is fine, but absolutely not required by the specification. You can implement Serializable but you don't have to. Actually under some conditions implementing java.io.Serializable would be an anti-pattern. In a SOA-like environment the visible service layer boundary have to be decoupled from the the domain or persistence layer. In such a case you will probably use dedicated Data Transfer Objects to decouple the service boundary from the internal realization. In that particular case marking the domain objects as Serializable (=JPA-Entities) would be counter-productive and would violate the "encapsulation".

On the other hand, in more pragmatic architectures, the domain objects could be exposed directly to the presentation layer. So instead copying the data from domain objects into DTOs, which is not DRY, you could just pass the detached JPA-entities as value holders to the web application or even rich clients. In both cases it is better to implement java.io.Serializable because:

1. The implementation of java.io.Serializable is simply required for transfering data via IIOP or JRMP (RMI) between JVM-instances.
2. In case of a pure web application the domain objects are sometimes stored in HTTPSession for caching / optimization purposes. A http-session can be serialized (passivation) or clustered. In both cases all the content have to be Serializable.

Thanks to Jacek Laskowski for the idea for the post!.

Remote (IIOP) EJB 3 / JPA 1.0, No Think Time, 100 Virtual Users, 4-Way Machine, Glassfish v2u2 Clustered - ...and What is The Performance?

I just completed some load tests with Glassfish v2ur2 on Linux, Clustered, a 4 way, Intel based machine and JDK 1.5 (JDK 1.6 would be better, but was not available in this case). I used a simple CRUD application as load generator, without think-time, and almost empty database, just to stress the appserver as much as possible.

The two load-generators ran remotely (via IIOP, standard EJB 3 client), each with 50 virtual users. Glassfish passed all tests without any problems, the response times and transaction / seconds were very stable. We just increased the number of connnections in the JDBC-pool, and set the -Xmx to 512m: no further tuning was performed.

The performance was impressive: 250 - 500 Transactions / second (we weren't alone on the machine :-(). We performed the tests with another, commercial, application server as well. The results were similar.

I actually performed similar, but not comparable, test several years ago (around 2003) with EJB 2. / CMP 2.0. We had more load generators (250 - 300 virtual users) available and were able to execute 800 transactions / seconds.

Conclusion: The performance of even remote (IIOP!) EJB 3 rocks :-), and Glassfish performs well, even without any further tuning.

In real world, however, most of the performance gets lost in contention / locks and synchronization issues... But you should not blame your server / framework / platform for it :-).

Netbeans 6.5 beta - Useful Productivity Enhancements For Java EE, Missing Some Features As Well

 I spent some more time with Netbeans 6.5 Java EE functionality. First feedback:

1. Field Level Access is generated now for Entities. However the Entities are still marked as Serializable - which is actually not necessary.
   
2. Call Enterprise Bean, Use Database, Send JMS Message wizzards are available from the ctrl+enter "popup". This is really nice - it doesn't disturb the workflow. For strange reasons "Use Entity Manager" is not included into the pop-up and is only available via the usual menu.
3. "Deploy On Change" feature works surprisingly well. On every save all your changed EJBs are incrementally deployed to the application server. I testet it with Glassfish v2ur2, it works really well so far. This feature can be activated or deactivated in "Properties" -> "Run" and checkbox "Deploy On Change".
4. ...the splash screen is nice :-)
   

What I'm missing or what would be nice:

1. There was already a "design query" functionality in the SQL-explorer. I never actually used it for design a query, but it was very useful to visualize the tables with it's relations. It should be reintroduced (I think it is no more available since 6.0). [a killer feature]
   
2. The support for ejb-jar.xml deployment descriptors could be better. There is no code completion in XML for Java Code etc. so it is easy to misspell class names etc. [especially useful for e.g. tracing interceptors]
   
3. There is no support for orm.xml. So it is not vey easy to transform existing annotations into XML-deployment descriptors  [nice to have]
   
4. Drag And Drop of JavaBeans (e.g. JPA-entities) into JSF visual editor with default generation of a form should be possible (not that hard...) -  this would be a killer feature.
   
5. Sometimes Netbeans 6.5 is not able to reopen an existing EJB in the editor. It works, however, in the EJB-view (obviously a beta bug - it worked perfectly before)

EJB 3 - Dead Or Alive ...very alive, See Quickvote Results

JavaMagazin, one of the biggest, German Java related magazines, started an online survey (quickvote)  with the question EJB - Dead Or Alive. The result really surprised me:

What surprised me: the small percentage of EJB 2.X. In Germany there is still huge amount of EJB 2.0 projects. Most of them will be ported to Java EE 5 next time. The second surprise was the EJB 3 adoption. I'm using EJB 3 in several projects but the amount of 58% (in this context) is huge. I actually thought, the aggregated amount of the alternatives will be greater, than EJB 3 and 2 together, but the opposite is true.

Hopefully this survey was not sponsored by the "EJB-Mafia" :-). So if you would like to keep your job and learn more about EJB 3 start here :-).

An award-winning heating hack - GreenFire Interview @Ericsson Mobilityworld

Absolute Beginner EJB 3 / JPA Series - the Essential Bootstraps And Background Information

The EJB 3 / JPA series are really popular (several thousands views). I was asked to provide an overview, so here are the posts so far:

1. EJB 3 plain intro 
2. Dependency Injection intro
3. JPA intro
4. Interception / "AOP" intro

I answered some frequently asked questions during the the inception phase of my Java EE 5 projects in my blog as well:

1. So if you have EJB 3, are "Plain Old Web Containers" still viable?
2. What happens, in case EJB 3 turn out to be not powerful enough?
3. Are POJOs lot faster, comparing them to EJB 3?
4. What's about the memory consumption?
5. Are EJB 3 threadsafe? Do they run well on multi-core, multi-CPU machines?
6. Are EJB 3 actually lightweight or heavyweight?
7. How fast is the deployment of several hundred JPA-Entities and Session Beans?
8. Monolithic Or Modular?
9. Integration Of "Legacy" POJOs - why not to inject a DefaultTableModel into an EJB?
   

JShot - Useful Screen Capture Utility - Works With Java6u10, WebStart, Swing and Nimbus

TimeLines, KeyFrames, Tweening - Useful JavaFX Screencast For Beginners