Java - J2EE

What is J2EE ? Well, at the most basic its the acronymn used to describe the Java 2 Enterprise Edition software development kit. It differs from J2SE, the Standard Edition that you may already be familiar with, by including more technologies as standard, is more oriented at distributed services, and, most importantly, defines a container standard that helps support these services. A Framework The major thrust of J2EE is the provision of an architectural framework into which components can be placed that communicate using Java specific, or standards based, protocols. The framework is supported at its core by servers that conform to the J2EE container standard. These are usually called J2EE application servers. Handily, a reference implementation of a J2EE application server is included in the J2EE SDK, so it is possible to experiment without having to download anything further. The framework components that are directly contained by an application server are termed Enterprise JavaBeans, or EJBs. The application server has a relationship with the EJBs much like that between servlets or JSPs and a Java web server, that is, it controls their lifecycle and provides various services to them. Development Using J2EE it is possible to create multi-tier, component based, distributed solutions more quickly and robustly than it would be using just the capabilities of J2SE. Some of this is due to the almost forced separation of data access, business and control logic and presentation code. The services provided by the various parts of the framework, plus use of the J2EE technologies, can also reduce the amount of bespoke coding needed for a system, thus reducing the overall development time, but at the same time increasing robustness. However, having said this there is a lot to learn when tackling a J2EE project for the first time. A load of new APIs and XML document schemas need to be learned, plus an understanding of the new technologies. This can make the initial projects a group tackles slower to develop than with J2SE. A good IDE should help with API completion when code bashing, and the application servers usually have packaging and deployment tools to help with this part too. Not a Panacea The main aim of J2EE appears to be to facilitate the development of systems that are to be split over multiple machines. Copious use of remote interface and messaging techniques are encouraged, and in some cases, mandated. If misused however they could lead to systems that are actually slowed by the use of J2EE. Strangely then, writing a bad system in J2EE is easier than writing a bad system in J2SE in my opinion. It is far more important for developers and architects to know what is actually happening when they use some of the J2EE specific technologies than it is with J2SE technologies, because more is happening in the background than one may think. This is particularly true with Entity EJBs that are entirely managed by the application server. These are the CMP, or Container Managed Persistence, Entity EJBs, whose database access is entirely at the mercy of the application server. One can imagine that if these were exposed to components not hosted on the same machine, or JVM, or were implemented entirely using remote interfaces, the amount of communications traffic could be overwhelming. If not carefully designed, J2EE systems can quickly become overly chatty and spend more of their time communicating than actually doing. Also, because they are almost always distributed over a network, they can generate lots of traffic and suffer from latency problems. So, a well thought out system will have a good split between remote and local interfaces, with special attention paid to the size and flow of communications between the components.