Flexible persistency – SQL or NoSQL

The reference application that I am building, supports both relational database or document database persistency.

The object model of my application consists of classes that are used in both. A factory determines dynamically whether to use a SQL or a NO-SQL database.  Or to be more precise, MySQL or MongoDB.

Java EE JPA is used to make it fit almost any SQL database, while MongoDB specific API is used to operate on MongoDB. Alltough JPA stands for Java Persistency API and is therefore not necessarily related to SQL databases, the use of specific annotations more or less assume that SQL databases are used.

In my application the domain objects do have JPA annotations and are used by an entity manager for persistence in MySQL and a bespoke document manager for MongoDB. All implementing the same interface.

The interface looks like:

public interface BankAccountManager {

	public List<BankAccount> getBankAccounts(User user);
	public List<MoneyTransfer> getMutations(BankAccount bank);
	public void storeMutations(BankAccount bAccount,List<MoneyTransfer> transfers);

The factory for getting the right implementation looks like:

public class BankAccountManagerFactory {

    private BankAccountManager docManager;
    private BankAccountManager entityManager;
	private BankAccountManager expManager;
	private boolean isDoc = false;      
	public void initEM() {
		if (isDoc) {
			expManager = docManager;
		} else {
			expManager = entityManager;
	public BankAccountManager getBankAccountManager() {
		return expManager;

In this example, the choice for using one or the other is hardcoded, but merely used as an example that you can switch based on something in your code path. The names of the EJB’s will be matched to the correct implementations of the EJB’s for this same interface. The names must be specified otherwise the correct implementation cannot be determined by your container.

A sample class that uses the BankAccountManager then looks like:

public class UploadSwift extends HttpServlet {
	private static final long serialVersionUID = 1L;
	@EJB private BankAccountManagerFactory bankAccountManager;

So in my application I could have chosen to use @EJB(beanName=”BankAccountEntityManager”) in my servlet, but that would make it really hardcoded. Using the factory I can determine it by some other rule. It’s still a hardcoded boolean at the moment, but could also be an environment variable or such thing.

In a future post, I will explain more about the differences in schema design and differences between relational and document oriented data.

Database independent JPA

Java EE 6 contains the JPA 2.0 specification. This means that applications that are built using this interface can be run using application servers that have their own implementation of the JPA 2.0.

Using JPA 2.0 in a Maven enabled Java project would require only this single dependency at provided scope:


Does this also mean, that your code can run on any database? No, it does not. It depends for instance on the capabilities of your database. A simple example is the use of auto generated numbers for primary keys. Oracle 11g does not support this, while Derby and MySQL databases do understand this.

The following code therefore, is only applicable to databases that understand and support the concept:

public class User {

    private int id;

Oracle 11g users may need to use values taken from sequences:

public class User { 

     @GeneratedValue(strategy=GenerationType.SEQUENCE, generator="USER_SEQ")        
     @SequenceGenerator(name="USER_SEQ", sequenceName="USER_SEQ", allocationSize=10) 
     private int id; 

Again, this is not a bad thing. Using the capabilites of a particular database has real benefit. However, it is wise to keep this in mind while developing and testing your solution. Once you start using functionality of a database that goes beyond simple SQL operations, you really should have such a database available in your development and test environment.

Platform specific resource binding

One of the most obvious problems of running your application anywhere is determining how your Java EE application can use application server resources.

Always use resource references is the best choice to start with. Not only will you prevent a hard link between application and runtime configuration, but jndi namespace bindings can typically cause problems. 

Binding deployment descriptors are a way to facilitate easy deployment in your IDE environment. Both JBoss as well as Glassfish and WebSphere make use of these binding files. This also implies that if you want to develop applications on JBoss as well as WebSphere, that you will need to supply both sets of binding files.

So that’s what I did to get my jdbc datasources up and running for both JBoss and Liberty.

In order to get it working on the Bluemix cloud, I had to choose to set the IBM specific binding files to use the resources according to Bluemix.

In IBM Bluemix, you can deploy applications in containers, VM’s as well as Liberty profiles on Cloudfoundry.

I user the latter approach. Then when you bind a ClearsDB MySQL, the name of the service will be bound to jdbc/servicename in the Liberty profile.

All information to connect is allready available and configured in that Liberty instance based on the bound service. You only need to bind your application resource reference to that specific resource.

That’s a Java EE app using a real datasource which is bound dynamically to your database as a service.

Write once, run anywhere?

Is it feasible to write enterprise applications in Java once while still being able to run them ‘anywhere’?

Yes, no, maybe, it depends…

The idea of the Java software development platform is based on this WODRA concept. Developers build an application using a standardized set of platform independent API’s and once the Java code is compiled to byte code it is the Java runtime environment that will make sure it runs everywhere.

In real life, it turns out to be very difficult to move applications from one environment to another. In the past I have worked on some of the replatforming projects.

Usually it involves different versions of the Java Runtime Environment, different versions of Java EE, different vendors of the former. As well as applications that have been build to use the bespoke features of the platform of choice. Something that isn’t necessarily a bad choice, but will make the effort of replatforming somewhat more difficult.

I have decided to create a Java EE 6 reference application. The goal of the reference application is to demonstrate that it is possible to create truly portable applications. Even at an advanced enterprise application level. But also to illustrate which design principles to take into account and to share my experiences in lessons learned about what to do and not to do for portability of applications.

I am allready confident that building a Java EE reference application will mean more work than building a solution for a target platform. However, I do beleive that it will help to determine best practices and design guidelines as well as insight in the portability and replatformability of Java EE enterprise applications.

I will use the following environments:

  • Windows, Linux CentOS, MacOS
  • Java JRE 6, Java JRE 7
  • Redhat JBOSS 7.1,  IBM WebSphere Liberty, IBM Bluemix
  • MySQL, Derby SQL databases (portability of JPA e.g.)
  • MongoDB (with and without application server support)
  • Java Security vs. OAUTH