Computing is now at a state where good systems can provide virtually all the infrastructure support needed. By infrastructure I mean the basic requirements of any computer system, before any business logic is applied. This would include functions such as database access, control of system resources, security, interaction with other systems, network access and protocols, and so on.

Free your best people from infrastructure code-use them to write business applications that can make your organization more profitable. There are only two ways to accomplish this: have a horde of “second level” programmers working to maintain connections with your proprietary infrastructure, or use an application architecture that already provides all the plumbing. I know my choice: Let the platform take care of the housekeeping; let the developer take care of business code.

If you agree with my logic, you should be thinking about J2EE. It is an architecture designed with all (well, almost all) of the pieces in place. J2EE provides an integrated system on multiple tiers that will handle the “basic” functions of an enterprise application. That leaves your developers free to work on the business logic. Software development at the business level shouldn't be that difficult. Well-architected systems provide a solid foundation on which to build your business models. J2EE is well-architected.

Another Point of View

Ever since the release of Windows 3.11, Microsoft has been working to provide a unified platform for application development. It now has a sophisticated suite of back office and database applications, as well as a model for distributed n-tier applications development. In its .Net initiative, it has moved into a Web services architecture that holds great promise. Its Distributed Internet Architecture (DNA) model, based on COM+ and MTS, provides a solid backbone for its enterprise architecture. Nevertheless, Microsoft's approach to enterprise software is totally different than Sun's.

Sun has developed an enterprise architecture that will run on a variety of servers and operating systems. Microsoft has developed an enterprise architecture that will only run on Microsoft servers and operating systems. That's not to say that the Microsoft model is flawed. I will suggest, however, that maybe that model is nearing the end of its useful life.

An operating system has enough to do just marshalling system resources, handling basic input-output functions, interacting with users, devices, networks, etc., without the added burden of providing an enterprise application infrastructure. The NT/2000 platform has evolved into a relatively stable, robust enterprise model. J2EE takes a different approach.

J2EE: What Is It?

Java started out rather modestly as a software standard for client-side applications. With a Java VM (virtual machine) a Java applet could run on virtually any platform. Early Java implementations (circa 1995) consisted of a little animation in a Web browser with a Java VM. Java has since grown into some dozen distinct component-types designed for different segments of a multi-tiered architecture. (See the box, “It's Not Your Father's Java.”)

That said, J2EE architecture is based on established and developing Java technologies and runs on any J2EE-compliant server. Existing compliant servers include BEA's WebLogic Server, iPlanet's J2EE server, Sybase EAServer and others. Major database vendors are promising or have delivered J2EE compatibility. J2EE integrates with CORBA. J2EE has hooks to COM+. Sun wants to work with everyone on this one.

Part of the underlying philosophy of Java is based on “containers.” For example, if you have an EJB (Enterprise Java Bean)-compliant container, you can deploy an EJB component on that system. This concept not only makes the J2EE platform portable and extensible, it offers third party vendors an unprecedented opportunity to be part of the enterprise development picture. A relatively small player can develop a needed Java component (for example, an EJB to access a DB2 mainframe database) and rapidly bring it to market. This encourages growth of the standard by way of mutual cooperation, not exclusion.

Below are the principal components used in building a J2EE application system. Most have been around a while-most are still evolving.

EJB: Enterprise Java Beans are already extensively used and have proven their value. They are components that can be “dropped” onto a client application and expose properties and methods than can used by that client application to perform whatever particular function they were created for. The 1.0 specification for EJBs experienced some difficulties with beans compiled on one server running in another; it was often necessary to recompile a bean for a particular server. In a bold move to alleviate that problem, Sun provides for no backward compatibility with the 1.1 specification. What it has done, though, is make the deployment descriptor XML based, which will provide for increased compatibility in the future.

Java Servlets. These are server-side components that require no user interface. The presentation layer will typically use servlets to access the business layer and vice versa (a Java Servlet may produce HTML dynamically in response to a client query). Think of a servlet as a JSP without the HTML.

JDBC: Java Database Connectivity 2.0. This is the hook to standard industry databases; this is what it's all about folks-data is the name of the game. These components handle interaction between the business logic tier and the enterprise tier.

JMS: Java Message Service. Just what it says: The specification provides an API for asynchronous communication between the different components of an enterprise application.
JNDI. For J2EE we get a new specification (1.2) for the Java Naming and Directory Interface. The latest iteration provides support for LDAP extensions and native directory service support for Sun, BEA, Netscape, Novell, and SCO servers.

JSP: Java Server Pages. Move over Microsoft. Why use ASP (Active Server Pages) when you can use Java? JSPs are simply server-side HTML pages with embedded Java code. The server executes the code when requested by the client. In a typical scenario of a multi-tier application, a Web browser may access HTML generated dynamically by a JSP whose Java code would in turn access an EJB that would access a database on the enterprise tier.

This all looks good for Sun. But keep in mind that not all of this is operational and fully functional-some is still under development. J2EE is a massive undertaking and there are doubtless pitfalls yet to be uncovered. Given all that, if you need to build multi-tier, scalable business applications that must link to legacy data systems, you should take a hard look at J2EE. It may not be the panacea, but it is definitely a step in the right direction.

It's Not Your Father's Java

J2EE takes all of these types and combines them into a standard architecture for enterprise development. Sun claims four elements to the J2EE platform.

J2EE Application Programming Model: A standard programming model for developing multi-tier, thin-client applications.

J2EE Platform: For hosting J2EE applications, specified as a set of required APIs and policies.

J2EE Compatibly Test Suite: Verifies that a J2EE platform product is compatible with the J2EE platform standard.

J2EE Reference Implementation: Demonstrates the capabilities of J2EE and for providing an operational definition of the J2EE platform.

Battle Grounds

There is some irony in the recent Sadmind/IIS Internet “worm” attack. During the first week of May, a security hole on Sun Solaris servers was exploited to launch an attack on a security hole in Microsoft IIS servers. The more paranoid Redmondians will undoubtedly see a conspiracy behind this attack. The Solaris servers suffered no damage while the Microsoft servers were defaced with a vulgar anti-government message. Some 200 Solaris servers were infected and they launched an attack on thousands of IIS servers. Looks like a clear winner in this battle.