J2EE is Java, optimized for enterprise computing. Officially J2EE stands for Java 2 Platform, Enterprise Edition. Unlike the traditional Java, which is often used to build client enhancements, J2EE is designed to build server applications. Officially, the J2EE platform is "a set of coordinated specifications and practices that together enable solutions for developing, deploying, and managing" such server applications.
As an enterprise platform, the J2EE environment extends basic Java with tools that "provide a complete, stable, secure, and fast Java platform to the enterprise level."
One goal often stated by developers is that by using J2EE, they're reducing the cost and complexity of creating large-scale solutions. Because Java is a strongly typed language (meaning that it requires data types to be used as specified), use of the language is often inherently more secure in Web applications than Web applications built with less strong typing (such as C or even PHP and Perl).
According to Sun, the gurus of Java, there are four main benefits to working with J2EE.
Complete Web services support
J2EE supports SOAP (Simple Object Access Protocol), a form of RPC between applications. The Java version of this is called JAX-RPC, which is the Java API for XML-based RPC. The idea with SOAP, JAX-RPC, and XML-RPC (one of the fore-runners of SOAP and still very actively in use today -- including here at ZATZ) is that applications on the Web and on servers can communicate easily across the network and between applications, regardless of what the originating and receiving environments may be. This means, for example, that a J2EE application might talk to a Domino application, which could talk to a Frontier application, which could talk to a PHP application, all seamlessly. It's very cool, although a bitch and a half to debug.
Faster solutions delivery time to market
Sun claims faster time to market, but my experience over the last 20+ years of dealing with development environments that every new environment claims the same thing. That said, J2EE does have some cool structural tools to make development more effective.
One area is the use of what the Java world calls "containers." According to Sun, "J2EE containers provide for the separation of business logic from resource and lifecycle management, which means that developers can focus on writing business logic -- their value add -- rather than writing enterprise infrastructure."
One example often cited is the Enterprise JavaBeans container, which can handle (when implemented correctly) distributed communication, threading, scaling, transaction management, and so on.
Freedom of choice
Because J2EE is a published standard, many vendors (such as IBM) are implementing to that standard. That said, your freedom begins and ends with your platform choice. Like all development environments, once you've chosen one and built into it sufficiently, you're in, dude. You're in.
The key to getting certified by Sun as compatible is that vendors can build whatever implementation (the internal guts) they want, but the standards and the APIs must remain absolute. This, of course, is where Microsoft is managing to regularly tick off the Java community, and where many other vendors find themselves trying to keep standard, while supporting diverging implementations.
To be sure, true, standard J2EE is a locked-in spec. So if you're building to J2EE, theoretically, your code can be moved from any one J2EE implementation to any other. This is theory, however, because once you start knitting in other custom implementations, systems, add-ons, hacks, and what-not, you're staying pretty much on platform.
SOAP, JAX-RPC, and XML-RPC notwithstanding, J2EE has a pile of services for talking to other systems, such as Web clients, cell phones, PDAs, and other devices. I'm still not sure there's a future for the Java ring, and Java apps running on my Tungsten T3 are spectacularly crappy, but there is something to be said for solid, spec'd out connectivity to other systems.