Three Advantages of EJB Development

EJBIs sun's server-side component model. The biggest use is to deploy distributed applications. Of course, there are still many ways to implement distributed applications, similar to Microsoft's. net technology. With the advantages of cross-platform java, distributed systems deployed with EJB technology can be not limited to specific platforms. The following describes three advantages of EJB development.

JAVA has gradually become one of the mainstream development languages, or has now become a mainstream development language. A variety of development models have also emerged on the JAVA platform. For beginners of JAVA programmers, they may be dazzled by so many development models and do not know how to choose. I didn't have many development models to choose when I first came into contact with the JAVA language. I also encountered this problem several years ago.

There are many available development models. The author must select a development model as his main direction in the future. Because human resources are limited, especially for program development. We need to spend our limited energy on the knife. I recommend the EJB development model here.

This EJB is essentially a managed component that exists in a J2EE container and is created, controlled, and destroyed by a J2EE container. The J2EE container has complex control over the number of existing ejbs and resources used by ejbs. In case of heavy load, even the EJB being used by the client will be returned to the instance pool. In this case, the EJB instance can be used by other clients, this improves the utilization of EJB instances.

Although EJB is also officially recommended for J2EE, this is not a mandatory measure. In addition to using EJB, program developers can also use JSP or standalone JAVA applications. However, if the application needs to be constantly upgraded and the performance requirements are relatively high, I would like to recommend the use of EJB for the following reasons.

1. You can hide the pipeline code.

Nowadays, music fountains are rapidly adopted in various places and become a representative of the high-tech landscape. Programmers need to use these pipelines when developing this application, but do not need to know the specific trend of these pipes. This is not a concern of developers. Developers need to directly use these ready-made pipelines. We call these pipelines "Pipeline Code ". In fact, program developers sometimes look like an industrial designer. Industrial designers do not need to care about water pipes when designing water pipes for bathing.

Why? Because water pipes use the same standard, water pressure is also a mandatory standard in China. For this reason, when using pipelines, designers need to directly reference these standardized parameters. In some early development models, such as the original CORBA development model, program developers had to write a lot of code to complete the interaction, connection, and registration process with the Corba environment. In fact, these codes are generally called Pipeline Code. If the EJB model is used, the compilation of these pipeline code can be minimized.

For example, by declaring attributes, a program developer can control these functions without the need to write code to specify the transaction type of the component; you do not need to write Pipeline Code to define the relationship between EJB components and the resources you need, the deployment description of a deployable J2EE application defines the relationship between multiple EJB components and the resources required by the EJB component; for example, every Bean follows a defined declaration cycle and a set of rules. For this reason, the program developer does not need to know the "Pipeline" design, but only needs to know the parameters of the pipeline interface, in this case, the system code and application code are two mutually independent contents.

Obviously, through the EJB component provided by J2EE, program developers can focus on the compilation of Business Code and minimize the compilation of Pipeline Code. This not only improves the development efficiency of the application, but also isolates the pipeline code from the application code, and facilitates subsequent debugging and maintenance. This is the first reason why I recommend using the EJB model to develop JAVA applications.

Ii. EJB predefines some complex processing mechanisms.

In the process of application development, there are more or less common content. If you need to manage the lifecycle of an application, you need to name and register the application, and you need to manage transactions. If you need to develop these functions from scratch every time you develop an application, the workload will be huge and the code reuse will be poor. To solve these problems, EJB provides some predefined services and integrates the services used in application development into the J2EE development environment. When these services are needed, the program developers need to declare them or call these services through a small amount of code to implement some complex control and management mechanisms.

For example, in application development, transaction management mechanisms must be implemented to maintain data consistency. If the transaction management mechanism is not implemented at the application layer, data consistency is easily broken when multiple records are involved in the same business. If you write the code of the Transaction Processing Mechanism from scratch, the workload will be huge. In the EJB container service, a transaction management solution is provided in advance. With this predefined solution, program developers can easily create transactions, process and control transactions.

For example, naming and registering in application development is also a very troublesome task. EJB also provides another named and registered container. The EJB container and server provide EJB with access to the Naming Service. Remote and local clients use these services to find ejbs. The EJB component itself uses these services to query the resources it needs. In other words, in application development, developers can directly call the naming and registration container in the EJB component without using code to implement the naming and registration service. The container automatically generates the relevant code to complete the required functions.

In addition, the EJB component also provides lifecycle management containers, security and access control containers, persistent containers, and so on. Through these containers, program developers can write less code, it not only improves program development efficiency, but also agrees to these basic content solutions. This will also help later people to understand the source code and facilitate subsequent upgrades of application management software.

3. user interfaces are isolated from underlying services.

The common nature and personality of enterprise management coexist, which is also reflected in the management software of enterprises. For example, if managers have different cultural backgrounds, they or many of the same businesses have different management methods. In this terminology, our program developers use different user interfaces. However, the management model behind it is the same, that is, its business functions are the same.

For example, an order management system developed in JAVA has the same order processing mechanism. It creates relevant records in the database and reviews the data validity before saving the records. However, different order types may have different processing methods. For a prepaid order, you must first receive the customer's payment before placing an order for the production department to arrange the production or warehouse department to prepare for shipment. For a warehouse order, in terms of process processing, it is not necessary to go through the production process but directly to the warehouse for shipment.

That is to say, 80% of the 10 different types of orders have the same functions, while 20% of the content varies with management methods or other reasons. In this case, do we need to write ten different codes to meet these ten different requirements?

The EJB development model does not need to be so complex, because EJB allows the development and deployment of business functions independently of the expression layer. As shown in the above Order management requirements, program developers can use the EJB model to implement underlying functions (80% of common content ), then, different user interfaces can be used to meet different user needs without re-designing or developing the entire application or sales order management module.

This is like the relationship between the parent and the child. Now we define the features of our parents, and then develop different children based on different needs (User Interface ). Because their children inherit all the features of their parents. You only need to graft some personal characteristics that users need to achieve to their children.

Therefore, the separation of such business requirements and business functions and their independent features are the biggest advantage of the EJB development model. Program developers can use EJB to implement distributed applications and isolate user interfaces from underlying business functions.