Hello everyone, Pavel is here. Today I would like to talk about the good old technology - EJB - and tell you some considerations about why EJB does matter in the XXI century even.
As everyone knows, EJB is a part of Java EE specification. It's responsibilities are the business logic organization, persistence, declarative security and global transactions management, multi-threading, the distributed objects relationship, clustering and messaging. The purpose of the standard is the developer should not be concerned with low-level things.
The main competitor is the Spring Framework. But the truth is the Spring Framework can't gain no one of the above purposes by itself. Exactly, you know there are Spring's branches for modules (Spring DM), security (Spring Security) and so on, but there are no Spring's Single Sign-On (SSO) implementation as well as Spring's global and distributed (XA) transactions manager (the framework can involve a provided by an application server transactions manager). Clustering is another interesting topic. You can deploy your application on two or more Apache Tomcat copies exactly but Spring Framework brings no value here. Session replication will be provided by the application server as well as load balancing. So, it's no matter whether the Spring Framework is leveraged or not. But if EJB is taken into account our applications aren't tight bounded up with the HTTP protocol and don't have to pay for an internal or external load balancer because an EJB client is the balancer and a more quickly protocol is used.
There is a very popular in Russia folk story about how a soldier made axe porridge. The hungry soldier asked an old lady to share some food with him, but the lady was very greedy and she tried to fire him. The soldier was very smart and sly he just proposed to the lady a new dish - the porridge only needs an axe (I mean it is cooked just boiling an axe in a pot, sorry for my English). But in the end, the oatmeal, a big piece of beef, the salt and pepper as well as other ingredients were put in the pot. So, as you get, the axe was used only as an excuse. As I know, in English the story is called Stone soup. The Spring Framework looks like the axe from the story. The solution is very good and interesting but you must put a lot of libraries in your pot. To bring a lot of jars with different and sometime conflicting versions in your WEB-INF/lib is a not good idea. I'm sorry.
It is popularly believed the main weaknesses of EJB are verbosity, baffling complexity, the necessity of large XML-descriptors and so on. Each of the above "disadvantages" is over. Starting from EJB 3.0 it looks like a new annotation based, concise technology. The Spring Framework, Google Guice, Tapestry IoC and a lot of other Inversion-of-Control frameworks are no longer needed. Exactly, some time ago they were leveraged for low-level services access without EJBs but now the problem is not longer actual. Each modern application server provides an IoC-container, a global and distributed transactions manager, declarative security options, a lot of security providers (LDAP-, DB-, or third-party stores-based, password- and digital certificate-based authentication, SSO, the digital certificate revocation chain support and more, more on), thread pools, clustering and messaging as well as the external Enterprise Information Systems communication with, out of the box. EJB is the most elementary way how to leverage the wealth.
As we can see, the code keeps be POJO and is valid to use JPA or JDBC and be called from your favorite web-framework.
So, it is my opinion why EJB does matter!
Would you like to give a 'Like'? Please follow me on Twitter!
As everyone knows, EJB is a part of Java EE specification. It's responsibilities are the business logic organization, persistence, declarative security and global transactions management, multi-threading, the distributed objects relationship, clustering and messaging. The purpose of the standard is the developer should not be concerned with low-level things.
The main competitor is the Spring Framework. But the truth is the Spring Framework can't gain no one of the above purposes by itself. Exactly, you know there are Spring's branches for modules (Spring DM), security (Spring Security) and so on, but there are no Spring's Single Sign-On (SSO) implementation as well as Spring's global and distributed (XA) transactions manager (the framework can involve a provided by an application server transactions manager). Clustering is another interesting topic. You can deploy your application on two or more Apache Tomcat copies exactly but Spring Framework brings no value here. Session replication will be provided by the application server as well as load balancing. So, it's no matter whether the Spring Framework is leveraged or not. But if EJB is taken into account our applications aren't tight bounded up with the HTTP protocol and don't have to pay for an internal or external load balancer because an EJB client is the balancer and a more quickly protocol is used.
There is a very popular in Russia folk story about how a soldier made axe porridge. The hungry soldier asked an old lady to share some food with him, but the lady was very greedy and she tried to fire him. The soldier was very smart and sly he just proposed to the lady a new dish - the porridge only needs an axe (I mean it is cooked just boiling an axe in a pot, sorry for my English). But in the end, the oatmeal, a big piece of beef, the salt and pepper as well as other ingredients were put in the pot. So, as you get, the axe was used only as an excuse. As I know, in English the story is called Stone soup. The Spring Framework looks like the axe from the story. The solution is very good and interesting but you must put a lot of libraries in your pot. To bring a lot of jars with different and sometime conflicting versions in your WEB-INF/lib is a not good idea. I'm sorry.
It is popularly believed the main weaknesses of EJB are verbosity, baffling complexity, the necessity of large XML-descriptors and so on. Each of the above "disadvantages" is over. Starting from EJB 3.0 it looks like a new annotation based, concise technology. The Spring Framework, Google Guice, Tapestry IoC and a lot of other Inversion-of-Control frameworks are no longer needed. Exactly, some time ago they were leveraged for low-level services access without EJBs but now the problem is not longer actual. Each modern application server provides an IoC-container, a global and distributed transactions manager, declarative security options, a lot of security providers (LDAP-, DB-, or third-party stores-based, password- and digital certificate-based authentication, SSO, the digital certificate revocation chain support and more, more on), thread pools, clustering and messaging as well as the external Enterprise Information Systems communication with, out of the box. EJB is the most elementary way how to leverage the wealth.
As we can see, the code keeps be POJO and is valid to use JPA or JDBC and be called from your favorite web-framework.
So, it is my opinion why EJB does matter!
Would you like to give a 'Like'? Please follow me on Twitter!
No comments:
Post a Comment