My J2EE mistakes)

I recently attended a J2EE training, and the training itself is not very fresh. However, during the training process, I found that my understanding of many J2EE concepts is not so correct or Orthodox.

The first thing is JNDI. I have always thought that JNDI is an annoying addition to compiling client Call Code such as EJB, data source, and JMS. In fact, we can regard jdni as a large-scale service locator. We can configure something we are interested in as a part of the JNDI and access it in a unified way.
With transparent access to JNDI, we can write portable distributed code.
I spent a lot of effort in fighting EJB, but in fact it was all about fighting with the JNDI-related parameters. It should be said that the code that can run properly proves that my efforts are not in vain, but in fact, my practices are superfluous.
By setting various parameters, I actually access the remote JNDI and get the EJB. This can certainly be run, but because of the parameter setting, our Code cannot be transplanted between application servers.
+ -------------- ++ -------------- +
| --- |-> | JNDI |
| Client | -------------- |
| --- |-> | EJB |
+ -------------- ++ -------------- +

The orthodox approach is that I do not have to set parameters in my own code, but only access the local JNDI, Which is mapped between the local JNDI and the remote JNDI. In this way, my code becomes a portable code. As for how to map local JNDI to remote JNDI, it is a problem with the specific application server.
+ -------------- ++ -------------- +
| JNDI --- |-> | JNDI |
| -------------- |
| Client --- |-> | EJB |
+ -------------- ++ -------------- +

What I have never figured out is that in the application, the JNDI name usually corresponds to a reference name. I always think that it is enough to have a JNDI name. It is unnecessary to use this reference name.
If the JNDI name is equivalent to a global variable, the referenced name is equivalent to a local variable. What are the benefits of doing so? Or portability issues.
When we deploy an application on a new application server, the JNDI name may have been occupied by others due to the global nature of the JNDI name. We only need to save the country by curve, change the JNDI name used by your application. If the JNDI name is used directly in the code, it is necessary to modify the code to change the JNDI name. If we use a reference name to ensure the uniqueness of the reference name in the same reference, we can still do it. In this way, we only need to modify the ing between the reference name and the jndi name, and everything will be solved.

Another major error is the JAR file of the application client. I once questioned how to export the JAR file and deploy it on the server. In fact, this is required.
Different from common web applications, if the war file is directly thrown to the relevant directory of the application server, the deployment is completed. If the ear file containing EJB is directly thrown to the corresponding directory of the application server, generally, it cannot run. As we all know, when writing session beans and entity beans, We will write two interfaces (not local) and one class. Obviously, interfaces must be implemented, however, the implementation of these two interfaces is not completed but completed by the application server. This involves the stub and skeleton discussed in EJB. We cannot expect different application servers to generate the same stub and skeleton, while the generation of stub and skeleton is usually completed during deployment. Therefore, only after deployment, then there will be a meaningful stub and skeleton, and the JAR file of the generated client is meaningful.

All in all, J2EE is too complex, not only the J2EE specification itself is very huge, but it is very difficult to write code, and deployment is also a very knowledgeable job. It is no wonder that there are dedicated deployment personnel in J2EE. In a review of the history of UNIX, Chapter 2 of "Unix programming art" said that the first system is generally not doing well, and the second system will be desperately improved in order to improve the first system, in the end, the weight of the system collapsed. Only the third system can make the whole design simple. It is estimated that the new version of J2EE, based on EJB 3.0, is still worth looking forward.