Recently, I have recently participated in J2EE training. There is not much new thing in training itself, but in the process of training, I found that my understanding of many concepts in J2EE is not that correct or orthodox.
The first thing is JNDI. I have always thought that JNDI is to write the EJB, data source, JMS and other client calling code and attach things. In fact, we can use JDNi as a large-scale service Locator, we can configure some things that you are interested in JNDI, using a unified manner to access. It is a transparent access to JNDI, we can write the portable distributed code. In "Dabu EJB", I spent the power of nine cows, actually fighting with JNDI-related parameters. It should be said that the code that can be run is proved that my efforts have no whitepets, but in fact, my approach has some paintings. By setting various parameters, I actually access the remote JNDI, then get EJB, which can be running so, but because of the reasons for setting the parameters, our code is definitely unable to migrate between application servers. -------------- ------------ | --- | -> | JNDI | | | ---- ------------------ ---------- ---------------------------------------------------------------------------- -
Orthodox approach is that I don't have to set parameters in my own code, but only access to local JNDI, mapping between local JNDI and remote JNDI. So my code is a portable code, as for local JNDI and remote JNDI how to map, that is, the specific application server problem. ------------ ------------ | JNDI --- | -> | JNDI | | ------ ------------------------------------- - --------------
Another one I have not figured out is in the app, JNDI name usually corresponds to a reference name. I always think that there is a JNDI name is enough, and this reference name is redundant. If the JNDI name is equivalent to the global variable, the reference name is equivalent to a local variable. What is the benefit of this? Still portability. When we deploy the app to a new application server, due to the globality of JNDI name, this JNDI's name may have been occupied by others, and we only have a curve to save the country, and change the JNDI name used by his application. If you use the JNDI name directly in your code, change the JNDI name to modify the code. If we use the reference name, in the same reference to the uniqueness of the reference name, we can still do so, so we only need to modify the reference name and the map of the JNDI name, everything will be solved.
There is also a big mistake in understanding about the application client's JAR file. In "Dabu EJB", I have questioned the exported JAR file and I have to deploy it to the server. In fact, it is necessary to do this. Unlike common web applications directly throw the WAR file to the application server related directory, even if the deployment is completed, if you directly throw the EAR file containing the EJB to the application server, it is usually not possible. We all know that when writing session beans and entity beans, we will write two interfaces (here, it is local) and a class, obviously there is an interface to be realized, but the implementation of these two interfaces is not our completion However, it is done by the application server, which involves the discussion of STUB and SKELETON that EJB often said. We can't expect different application servers to generate the same STUB and SKELETON, while STUB and SKELETON buildings usually do when deployed, so after deployment, there will be meaningful stub and skeleton, at this time The client's JAR file is meaningful. All in all, J2EE is too complicated, not just J2EE specification itself is very large, writing code is very hard, and deployment is also a very learning work, no wonder J2EE is also specially responsible for deployment. The second chapter of "UNIX programming art" reviews the history of UNIX, the first system is generally not made, the second system will be desperately improved in order to improve the first system, and finally leads to itself. The weight is collapsed, and only the third system will return to simple. This is calculated that the new J2EE mainly based on EJB 3.0 is still looking forward to.
