Due to our first blog about JBoss EJB 3.0 successes and the fact that TSS picked up that blog, the success stories are starting to pile in. This particular testimonial is from Ron Hatcher of the Millfield Group in the UK. Look for more testimonials to pop up here in the next few weeks. If you have your own EJB 3.0 testimonial, please bill@jboss.org

The Millfield Group plc. is a financial services company with over 1500 advisers, including independent financial advisers, independent mortgage advisers and other specialist advisers in our regional offices throughout the UK. We have adopted JBoss as our strategic platform for enterprise development and have now begun releasing EJB3 based applications into production.

Our recent EJB3 implementation is the first application to take advantage of our evolving service delivery platform - Jupiter. It is based on a three tier physical architecture with Windows/IIS web servers, Solaris/JBoss application servers, and Windows SQLServer database servers. This structure is quite common (and has been for some time). The difference now is the effectiveness that the JBoss EJB3 implementation brings to the whole development process.

Our Jupiter platform provides a core set of services and business objects that are generic across our business domain. These services and objects are then used by applications that 'orbit' around it. Currently these applications invoke the core services by accessing stateless session beans, but these will expand to include web-services and Message Driven Beans in the future.

The first application - Leda - is a mortgage referrals system. Estate agents use it to refer their home buying clients to mortgage selling financial advisors. We use the Front Controller/Dispatcher mechanism to manage the presentation tier, and use a single dispatcher for each use case in the system (there are approximately 12). Our initial user group has been restricted to 250, however we are planning to bring an additional 750 users online in the very near future.

While building the application, I was very pleased with the ease of implementation of the entity model. Although we have built hibernate based applications in the past, the EJB3 entity beans really take all the headaches away from the persistence mechanism.

We did encounter a few issues during the initial build -

• Lazy Loading - The lazy loading mechanism is very awkward in the context in which we use our entity beans. Although there are many ways to solve this, we opted to have different methods on the session bean facade to load children as required.
• Integration - We found that integrating the EJB container into the JBoss application server was a manual job. Even as late as 4.0.3.RC2, we had some issues with the integration 'out of the box'. Presumably this has been resolved now, but we keep our JBoss version in CVS, to ensure any configuration can be easily rolled out across the development team and out into the environments.
• Tomcat - We have had to simulate EJB session bean access in servlets as described in the EJB3 documentation. This wasn't difficult to do, but may present a problem when the specification is finalised. Also, we needed to patch the tomcat server to allow us to use generics and Java 5 style for loop iterators.
• SQL-Server - Lastly, SQL-Server seems to have minor issues in the JDBC world - these are not specific to EJB3 or JBoss. We are now using the Jtds JDBC driver, and with a small amount of 'tweaking' it is working very well.

There has been much written recently about EJB3 persistence, annotations, and dependancy injection from an implementation perspective, but I feel the real benefit here is in the whole development file-cycle. In the EJB2.1 world, we adopted the many of the Sun Architectural patterns to get the performance and usability we required from the platform, but these mechanisms required a translation from the business requirements and business model to the implementation. Our current development aims to solve this problem by using JBoss Jbpm.

As a financial services company, we are required to implement and use many regulatory processes. These can be quite complex, and code to implement them quickly becomes complex and hard to maintain.

Our first regulatory application - Callisto - uses Jbpm to manage the business process, and invoke our EJB services as required. This allows for the implementation code to be narrowly focused on a specific step in the business use case, and moves any process related code out of the equation. Using this technique, we effectively automate our business process with very little interpretation between the business spec and the final implementation.

Our initial testing has shown this approach to be extremely effective in quickly building applications, and keeping the code very clean and maintainable. Again, we experienced a few issues so far with Jbpm.

• Process archive - the Jbpm process archive extension has collided with the EJB3 persistence archive (.par) this is not a major issue, but should obviously be addressed.
• Documentation - we found the documentation for Jbpm to be a bit fragmented, but with a few experiments, we managed to get it going fairly quickly.
• API stability - As we are implementing Jbpm 3.0, we are currently concerned that the API changes for 3.1 may be problematic for us.

All in all, I am very pleased with our success to date using EJB3 and Jbpm, and am confident that this will support our platform development efforts for some time to come. Our current plans involve implementing two more modules in the next 12 months, and expanding the user-base of the platform to 10,000. I would like to take this opportunity to thank all of the JBoss contributors for providing a great environment, and also to our EJB developers Richard King, David Oliver, and Victoria Weston.