EJB maintains its dominance

22 Comments

EJB was created almost 10 years ago to solve the component needs of application developers. Since then thousands of successful applications have been written and deployed using this technology. Although I don’t do much with EJB nowadays as I have other responsibilities at JBoss, I still wonder how it is doing in the industry. Recently, I became privy to various bits of knowledge that EJB is still going strong and maintaining its dominance in Java application development. Consider this job trends graph from indeed.com:

EJB job graph

Over 3 years EJB jobs have remained pretty much constant. This is very encouraging news considering recent Rod Johnson propaganda. EJB really did not have an alternative in the Java space until 2004/2005 when Spring started to be known and popular. It is very interesting to see that although EJB has had a serious competitor, it has maintained its dominance in Java application development over the years. You could even extrapolate from these numbers that EJB is an upper bound on the number of Java component jobs out there and that Spring has only recently matched this. This is proven by the fact that the Spring and Java graph trends are the same since they converged 6 months ago.

This trend pretty much correlates with download numbers I posted on our EJB implementation awhile back on TSS in June 2007.

I can give you a few from two perspectives:

downloads on sf.net for JBoss and Hibernate projects related to EJB3 and JPA:

* Downloads of a standalone distribution of the JBoss EJB3 project since 10/2004: 183199

* JEMS installer which bundles EJB 3.0 (not same as JBoss Appserver download): 201923

* JBoss 4.2 which bundles EJB 3.0: ~65000

* JBoss 5 betas which bundles EJB 3.0: ~80000

* Hibernate’s JPA implementation: 135269

* Hibernate Annotations (which is JPA based): 202561

So, total downloads solely related to JPA: ~337K
Total downloads solely related to EJB3: ~550K
Total EJB3 + JPA related downlaods: ~ 887K

Compare that to Spring 2.x downloads: ~600K
Spring 1.x downloads: 946K
Hibernate 3.x downloads: 1445K
Hibernate 2.x downloads: 495K

Now that’s just JBoss. You also have Glassfish, Open JPA, Oracle, and now Geronimo communities not included in these numbers.

Also, my EJB 3.0 book has been out a year and has sold ~12K copies +/- a thousand (haven’t gotten check yet from last quarter).

So, all and all I think there is pretty compelling evidence that EJB3 and JPA has momentum.

Its hard to continue any analysis on JBoss specific download numbers as we basically encourage our user base to download JBoss 4.2.x or 5 as it is bundled with our EJB3 implementation.

There’s some other encouraging numbers as well. In 2005 I was offered by O’Reilly to take over Richard Monson-Haefel’s EJB series.  “EJB 3.0, 5th Edition” was published in May, 2006. Even after being out for almost a year and half, sales are still going strong. Just last quarter we sold 1700 copies, very good for a technical book. When I went to Krakow in October, I also found that my book had been translated into Polish. I believe its also been published in Chinese. All indicators of broad adoption by the technology.

So, as you can see, even after almost 10 years, EJB is still going strong and maintaining its dominance. With the emergence of Seam and Web Beans being incorporated into EE 6, I predict this trend to continue.

Guaranteed Execution in jBPM

2 Comments

Was thinking a bit about jBPM today. One thought crossed my mind: How can you guarantee that a specific state transition happens in jBPM? We’ll talk about guaranteed state transition in this blog, but first of all, before we even think of jBPM, how could you guarantee that *any* event happens in a general application? There are few things you have to think about here:

  • You want to be guaranteed that the event is scheduled to be processed
  • You only want the event to be scheduled if your business logic succeeds
  • You want to be guaranteed that somebody processes the event

Being as stupid and slow as I am, took me a few minutes to realize that JMS provides guaranteed delivery of messages. This is obvious to many people, but let’s walk through what you would have to do in JBoss to have the guaranteed processing of an event.

First things first is to write the sender code. Let’s do this in an EJB 3.0 stateless session bean. I know this is basic stuff, but you may not be familiar with a) EJB 3.0 or b) the JBoss specifics:

@Stateless
public class BusinessLogicBean implements BusinessLogic {
   @Resource(mappedName="java:/JmsXA") ConnectionFactory factory;
   @Resource(mappedName="queue/mylogic") Destination destination;

   public void doSomething() {
      ... do some logic ...
      Connection con = factroy.createConnection();
      ... do all the JMS sugar ...
      messageProducer.setDeliverMode(DeliveryMode.PERSISTENT);
      messageProducer.send(message);
   }
}

The doSomething() method is a transactional unit of work. We want every piece of business logic to have succeeded when we deliver the message. In other words, we want the message delivered as part of a transaction. To use a transactionally aware sender, we injected the “java:/JmsXA” connection factory into our SLSB. We also set the delivery mode of the producer to be PERSISTENT. So, we both guaranteed that the message would only be sent if the business logic succeeded and that the message has been scheduled for processing. On to the server:

@MessageDriven(activationConfig= {
      ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
      ActivationConfigProperty(propertyName="destination", propertyValue="queue/mylogic"),
      ActivationConfigProperty(propertyName="DLQMaxResent", propertyValue="5")
})
public class MyMessageConsuomer implements MessageListener {
   public void onMessage(Message msg) {
      ... do the work ...
   }
}

Typical message driven bean in EJB 3.0. Since this bean is using the container to manage transactions and being invoked inside of a transaction, the receipt of the message will not be sent back to the JMS provider if the business logic is rolled back. So, if there is a system failure, or some other reason for abort, the message will be redelivered, thus guaranteeing its processing. The “DLQMaxResent” property is JBoss specific and tells the JMS adapter how many times the message should be resent before it is sent to a “dead letter queue” and put to death. There’s other configuration items around dead-letter queues. Go read our documentation for additional DLQ settings.

Guaranteed State Transitions in jBPM

Guaranteed state transitions with jbpm is all about using asynchronous continuations and the Enterprise Archive. In jBPM if you mark a node as asynch then jBPM will use its configured messaging system to transition to that state in another thread and transaction. If you have deployed jBPM through the Enterprise Archive, JMS is used to do the transition. Here’s example .jpdl

<process-definition>
   <start-state>
     <transition to='guarantee'/>
   </start-state>
   <state name='guarantee' asynch='true'>
     ...
   </state>
...
</process-definition>

So, starting a process instance of this definition will generate a JMS message that transitions to the ‘guarantee’ state. By default, jBPM is configured to use transactional connection factory, “java:/JmsXA”, describe earlier in this blog. So, when the start-state transitions, it will create a persistent JMS message and deliver it to the queue transactionally. Now, the ‘guarantee’ node will be triggered by an MDB that receives the message sent by the jBPM message layer. This MDB uses container managed transactions. This means that if there is a failure within the execution of the state, the message will be redelivered until the transaction completes successfully. This MDB is configured to use JBoss’s old EJB 2.1 container which does not use JCA message inflow. The default message redelivery count is 10. Chapter 5 in the JBoss AS documentation shows how you can define the max redelivery as well as dead letter queue configurations. You’ll need to open up the Enterprise Archive, jbpm-enterprise.ear, to get to the file, jbpm-enterprise.jar. This file contains the ejb-jar.xml and jboss.xml files you need to modify to change the jbpm configuration of the message driven bean.

The only thing missing with this JMS transitioning in jBPM is that the node receiving the transition does not have knowledge on whether the message was redelivered or not. Future versions might incorporate this knowledge. I have pinged the jBPM team and there is some discussion on the jbpm forum.

That’s about it! Yeah, I know a lot of this stuff is basic, hope I didn’t bore you too much. I just wanted to set down some foundation for other topics I want to discuss that may use these JMS and jBPM features.

Co-existence with Hibernate, JPA, and EJB3

15 Comments

How can you slowly migrate existing Hibernate apps to JPA? How can you use Hibernate features and unique mapping capabilities with a JPA deployment? How can you take advantage of EJB3 injection and persistence context management with Hibernate? In this blog I want to show how Hibernate, JPA, and EJB 3.0 can co-exist and compliment one another. This information is fully documented between the Hibernate and JBoss EJB3 projects, but I thought I’d highlight them in this blog to make the community aware that they exist.

Mixing and matching JPA annotations within Hibernate

Using the standard JPA annotations helps out greatly in cutting down the amount of XML metadata you have to type. This annotation metadata is an exact replacement for much of the metadata in hbm.xml. Using them does not require you to use the JPA EntityManager interface. You may still use SessionFactory and Session objects to interact with your database. After downing the Hibernate Anotations project, setting things up is fairly easy:

SessionFactory sessionFactory =
                  new AnnotationConfiguration().buildSessionFactory();

You use hibernate.cfg.xml to specify which exact classes you want mapped by this SessionFactory:

<hibernate-configuration>
 <session-factory>
    <mapping class="com.acme.Flight"/>
    <mapping class="org.jboss.Sky"/>
    <mapping resource="org.acme.orm.xml"/>
 </session-factory>
</hibernate-configuration>

You can mix hbm.xml mapping files with new annotated classes. XML resources can also either be JPA-based XML or Hibernate based. This mixing and matching allows you to quickly prototype new mappings using JPA, but allows these mappings to co-exist with older Hibernate 3 applications.

There are a few more options for configuration. Check out the Hibernate Annotations documentation for more information.

Use Hibernate to configure JPA

If you want to use the JPA Entity Manager API to code a portable application, you may still want to use Hibernate metadata to map your beans. Although the JPA orm mapping is pretty rich, it is still a subset of Hibernate’s functionality. The Hibernate Annotations project provides additional Hibernate-specific annotations to elaborate a persistence mapping where JPA leaves off. If you prefer XML, you can use hbm.xml files to define the mappings for your entity beans. When loading a persistence archive, Hibernate Entity Manager will automatically scan the .jar file for any *hbm.xml files and add them to its mapping information.

Hibernate specific configuration is defined in the properties element of the persistence.xml file. You can configure any hibernate property within this XML blob

<persistence>
 <persistence-unit name="manager1" transaction-type="JTA">
    <jta-data-source>java:/DefaultDS</jta-data-source>
    <properties>
       <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>
 </persistence-unit>
</persistence>

You may also define all your hibernate configuration in the usual Hibernate way: within a hibernate.xfg.xml file. You must tell the JPA implementation to use this configuration file through the hibernate.ejb.cfgfile property.

<persistence>
 <persistence-unit name="manager1" transaction-type="JTA">
    <jta-data-source>java:/DefaultDS</jta-data-source>
    <properties>
       <property name="hibernate.ejb.cfgfile" value="/hibernate.cfg.xml"/>
    </properties>
 </persistence-unit>
</persistence>

EJB 3.0 managed persistence sessions

EJB 3.0 has some nice integration with JPA. You can have your EJB session beans manage persistent sessions for you, freeing you from having to create, destroy, and clean up your persistence sessions. It can manage your persistent sessions in two ways:

Transaction-scoped persistence contexts

Transaction-scoped persistence contexts can be injected into your stateful, stateless, or message driven beans. These transaction-scoped contexts only live for the duration of the JTA transaction they are invoked within. When you first interact with an injected transaction-scoped EntityManager within a transaction, an underlying persistence context (in other words, a Hibernate session) is transparently created and associated with the transaction. This associated context is propagated automatically to an nested EJBs that invoke on entity managers of the same persistent unit type. This means that any EJB that invokes on an entity manager will be using the same underlying Hibernate Session.

@Statelesspublic class MyBean implements MyInterface {

 @PersistenceContext(unitName="custDb") EntityManager manager;

...

Extended persistence contexts

In Hibernate terminology, an extended persistence context is one particular Hibernate session. This session may live beyond the duration of a JTA transaction. In EJB 3.0, you can inject an extended persistence context into a stateful session bean. Unlike transaction-scoped entity managers, these persistence contexts are not created and destroyed in a transaction, but instead have their lifecylce tied to that of the SFSB session. This allows you to have conversations with your database that span multiple JTA transactions.

@Statefulpublic class ShoppingCartBean implements ShoppingCart {
{
 @PersistenceContext(unitName="custDb", type=EXTENDED) EntityManager manager;
...
}

Using EJB 3.0 injection annotations with Hibernate

The JBoss EJB 3.0 implementation allows you to use Hibernate Session and SessionFactory as types for targets of the @PersistenceContext and @PersistenceUnit annotations. The injected Session or SessionFactory will behave exactly as if you were instead using the JPA counterparts EntityManager or EntityManagerFactory:

@Statelesspublic class MyBean implements MyInterface
{
 @PersistenceContext(unitName="custDb") org.hibernate.Session session;
 @PersistenceUnit(unitName="custDb") SessionFactory factory;
...
}

Just like with the EJB 3.0/JPA integration, the Hibernate Session will be associated with the JTA transaction and propagated to nested EJB invocations within the same transaction. It is also ok if these nested calls use the EntityManager API instead. The same underlying Hibernate session will still be used for both.

Hiberate Sessions can also represent extended persistence contexts:

@Statefulpublic class ShoppingCartBean implements ShoppingCart
{
 @PersistenceContext(type=EXTENDED) org.hibernate.Session session;
...
}

Again, the EJB container will manage this Hibernate Session the same way it would manage an EntityManager instance.

Obtaining Hibernate objects programmatically

You can always get access to a Hibernate Session object from an EntityManager instance through the standard EntityManager.getDelegate() method. This is a JPA specification feature.

  @PersistenceContext EntityManager manager;
  ...
{      org.hibernate.Session session = (Session)manager.getDelegate();  }

The specification, however, does not provide a way to get at the underlying implementation of a Query. Hibernate should provide most of its extended functionality through JPA query hints. For example, lets say you wanted to enable a query cache:

  javax.persistence.Query query = manager.createQuery(...);
  query.setHint("org.hibernate.cacheable", true);

Conclusion

Hibernate and the JBoss EJB 3.0 project provide multiple ways in which you can mix and match Hibernate and JPA annotations and XML metadata. JBoss EJB 3.0 can manage Hibernate typed objects the same way it can manage JPA objects. Finally the specification provides programmatic ways to get at the underlying Hibernate connection. With the features you should have the flexibility to get at the HIbernate features you need while staying as portable as possible under the JPA specification. Or conversely, you can use well-defined JPA mapping annotations within your Hibernate deployments to make coding simpler and easier.

Disclaimer 😉 This blog was meant to make you aware of certain integration features that exist between JPA, Hibernate, and JBoss EJB 3.0. You should not use it as a reference guide, but rather dive down deeper into each project’s docoumentation. Have fun.

<span>%d</span> bloggers like this: