These days it seems to me that everyone blabs about the blessing of microservices and the new architectural style. In most articles about the new glory architecture of microservices, it’s generally assumed, that Java EE is slow, dull and scales poorly. There seems to be a big misunderstanding about what Java EE really is. And I even assume that not many of the young believers in the new world of microservices have engaged much with the concepts of Java EE. I’m taking here three examples each developer is confronted with. And perhaps you will rethink of these scenarios in the light of Java EE.
Database Pooling
If you are developing an application, in most cases, you will access a database, to read or store data. This can be done in Java by using a JDBC Database connection. Every database has a JDBC driver and it’s quite easy to use them. But opening a new JDBC connection, select some records from the database and finally closing the connection is a little bit of work in your code. And because those connections are expensive it’s a good idea to reuse them for multiple select or update statements if it is possible. This is called ‘connection pooling’. And if you are familiar with those concepts and know how to handle a pool of JDBC connections you may be happy to implement your own connection manager. But if you are not so familiar with these concepts you should take care. Or you can take a look on Java EE. A Java EE application server decouples the JDBC database connection from your code. If you need access to a database, you simply inject a JNDI database resource. This database resource is totally managed by the application server in a connection pool. Take a look at the following screen from the admin interface of Wildfly:
You can not only manage the pool but also the validation, timeout settings or the internal cache of shared prepared statements. So you can control in a fine grained way how your database connections should scale. I don’t believe that the new practice “let’s start a new instance of tomcat” will be a comparable solution.
Services
The next use case is a simple code block implementing some business logic. Let’s assume, that this block of code performs a complex calculation which can take sometimes more and sometimes less time. Thus, we have the problem that one call with a long execution time blocks other calls. So what can we do? Yes of course we can start again some more instances of our tomcat server. But this is a expensive solution just for the case, that sometimes some calls may need longer execution time. The other solution would be to build and manage a pool of services, where each service is implementing our business logic (we call this a factory pattern). We would be able to share those services between several calls without the need to re instantiate them. And that is exactly why EJBs were invented. An EJB is a simple piece of code which is pooled and shared in a multithreaded runtime environment. Again take a short look at one of the configuration pages of Wildfly:
The EJB Container of an application server can be configured in various ways. You can configure the Bean pools and thread pools and how these pools should work in a cluster. And there are several kind of EJB types to fit for various problems. So if you have a complex business logic, a simple stateless session EJB can solve a lot of your problems of scalability – even if you are running only one instance of an application server.
Transaction
The last use case which I want to discuss here, is the transaction management. This is one of the most complex problems in software development. If you have a HTTP request which needs one or more database connections, and has to perform different code blocks of business logic it can become very hard to tie all things together in one isolated transaction. Transaction management is one of the core concepts of Java EE. It doesn’t matter which kind of service EJB you need or what kind of JNDI resources are necessary. Every request can be managed by the server in one or many transactions also among different containers. For most software projects it is nearly impossible to address all the issues of isolation and atomic transactions and implement them in the right way. Again take a look of one of the configuration pages of the transaction subsystem from Wildfly.
Conclusion
So what is the message that I want to convey here? The development of a business application is a complex matter. Many small things must be respected in terms of performance and scalability. But this is known since the beginning of software development and it was not detected in the past two years. Java EE provides a platform to capture a large part of these problems. So just in case that you are not the architecture for Amazon, Netflix or Facebook it is not automatically the best way to adapt their strategies. Microservices are a great idea. I believe that it is worthwhile to package business logic into a single service. But this can happen in most cases also with the help of Java EE.