Several factors need to be considered before using enterprise-level JavaBeans

Enterprise-Class JavaBeans (EJB) is one of the most complex technologies in the Java EE platform, so some developers are unwilling to deploy EJBS in their projects.

This article is intended for developers who are still looking at whether to invest time and energy in learning and deploying EJB technology in their projects. First, we introduce the pros and cons of EJB, and then explain when you might or may not need to use EJBS.

Finally, I came to the conclusion by stating some views on the concept of EJB error.

Advantages

Specification: EJB is a technical specification technology. (This is both a major advantage and a major drawback of EJB.) The EJB specification describes almost all aspects of implementation, including data types, component lifecycles, role assignments, and many other aspects.

Close integration with Java EE: Java Java Platform has a complete set of server technology, including EJB and other very valuable technology such as Servlets,javaserver page, Java Messaging Service, the EE Connector architecture, java-based database connectivity, Java authentication and licensing services , Java transaction APIs and JavaMail. This makes Java EE and EJB an attractive solution.

Scalability: As long as you upload most of the resource management functions to the application server, the vendor can use the complex upgrade algorithm.

Accessible resource management systems: Using the EJB container, you can get thousands of lines of code to access and manage resources, including transaction management systems, security management systems, and directory services. Without EJBS, you can only implement these components yourself.

Disadvantage

A large number of complex specifications: This is normal for a specification that describes a complex distributed system, but not all of the information in it needs to be encoded, making the specification a very inconvenient tool.

Large document: You usually need to read more than 1000 pages of documentation before you start developing a project, which is one of the daunting reasons to deploy EJBS.

Increased development time: EJB solutions require more time than normal Java code implementations. Debugging an EJB code takes longer than debugging normal Java code. The main reason is because you are not sure whether the vulnerability is in your code or in a container.

EJB code is more complex: for example, to implement a session bean, you have to write three classes, a login bean, and you have to write four classes. Adding one or two deployment descriptors and one of the simplest "Hello world" applications generates 10 files instead of a single file.

Risk of duplicate design: This is the consequence of regulatory complexity. If you don't have a good understanding of the EJB concept, you won't be able to use it effectively, and you may be more complex than you really need to be.

Specification change: EJB is a new technology, your code is potentially outdated, which requires additional work and effort to make it compatible with the new EJB container.

when you might want to use EJB

Let's say you have a simple servlet Web application that uses a database. You use JDBC to access the database from your application. As a result of a SQL query, you get a result set resultset that has some data that represents your business object.

This method is not very convenient to use data. You need to create a Java class that represents a database structure, and your code might look like this:

Myobjectobj = new MyObject ();

Obj.setxxx (rs.getstring ("XXX"));

OBJ.SETYYY (rs.getstring ("YYY"));

After you have replaced the result set with an object representation and return, you need to consider how to transfer this logic to MyObject. To isolate the servlet from the JDBC access details and not to use the class directly in the Java.sql.* package, you should let the object find itself in the database and then modify or delete it.

Now there's another question: How do you find an object in a database with some queries? If you need to find it through the primary key, then you need to pass the primary key to the class constructor. If you need to search through certain criteria, this will require a lot of dedicated static methods. If necessary, you may also need to support transaction processing and rollback methods.

When your application is widely used, the percentage of uptime and availability will become very important, and you will need to replicate, fast object persistence, object caching, database connection pooling, security services, and so on.

All of these problems can be resolved by the entity enterprise-class Java beans. You will not make the same mistakes that many programmers have already done. If your bean is a container-managed persistence bean, you only need to implement one or two interfaces without having to consider the database that must be accessed. If you don't fully meet your needs, there's no problem, you can use the Bean Management Persistence (BMP) entity to achieve your own persistence.

In your application business domain, objects not only save data, but also some behaviors. These behaviors represent business logic. When you start writing applications, all of the business logic is stored in the servlet, so your application needs some servlets support.

You can choose whether to copy and paste the business logic code, or to put it in a separate class. Finally, some users may require interaction with your application on different Web pages, and you need to save session information between each user request. The solution to this problem is called the session Bean, which encapsulates all the business logic in your application, which can be stateful or stateless.

when you might not want to choose an EJB

EJB is really a good technique, but it is not a common solution. Many of the features provided by EJBS (like security, persistence, and transactional support) are not required by every application.

In addition, you may not want to use EJBS in a non-distributed application because the speed of the program may be more important than security and transaction processing. Because of the distributed nature of EJBS, in order to facilitate communication between the client and the EJB component (or server), the data must be processed (serialized) before it is processed (serial data parallelization). This leads to a lot of overhead and performance degradation, which is why it may be better to use the local classes in the JVM (Java Virtual machine).

some misconceptions about EJB

EJB is an expensive technique: this is partly true. Recently, however, several low-cost or free application services have been released that have all the functionality of a commercial server. In a large enterprise application project, the cost of the application server is only a small part of the overall project overhead.

If you use CMP beans, you don't need SQL knowledge: This is not true.

EJB applications facilitate porting between different containers: This view is partly true. EJB code can only be ported if it is written in a portable way. Session beans and BMP beans can be easily ported, but porting CMP beans requires a lot of work.

Entity beans is slow to work: basically right. Entity beans do run slowly, and in many cases it is best to convert them to session beans.

Conclusions

Before you decide whether to use EJB technology for your project, you need to understand all the requirements of your application, its evolution, and the main goals and pitfalls of EJB.