When we discuss enterprise applications we always talk about thesame topics-scalability, maintainability, security,interoperability, reliability, and so on. These are all criticaland should enter into any discussion about enterprise computing,but they are not the only relevant considerations. There are somebetter ways to look at Sun Microsystems's Java 2 PlatformEnterprise Edition (J2EE).

J2EE defines a standard architecture for creating enterpriseapplications based on existing (and new) Java technologies. Beingrooted in Java, it espouses the Sun “write once, run anywhere”philosophy. And Java, in all its different flavors, is a force tobe reckoned with in enterprise application development.

Programmers are Expensive

Software development is an expensive process, and the singlebiggest expense in that process is people. In comparison, hardware(even that state-of-the-art server your alpha geeks are demanding)and off-the-shelf software are cheap. The local video rental storemay be able to get by with a standard accounting and inventorypackage, but Fortune 1000 companies don't have that luxury.

At National Underwriter (parent company of TechnologyDecisions), we purchased a standard e-commerce “storefront” for ouronline catalog, but there are thousands of lines of custom codesupporting that catalog. When we wanted to integrate that catalogwith a different vendor's system to maintain inventory control,more custom code and server-side components had to be created. Somy first point is this: You need to use internal staff to createsome of your enterprise applications.

Given that, it is extremely important that your criticaldeveloper resources are used in the most productive ways. You don'twant to waste the time of your best and brightestprogrammers-primarily because it is expensive, and because youreally don't want these guys getting bored. That means that yourbest programmers should be working on code and systems that have todo with business logic and business requirements-not infrastructurecode.

Computing is now at a state where good systems can providevirtually all the infrastructure support needed. By infrastructureI mean the basic requirements of any computer system, before anybusiness logic is applied. This would include functions such asdatabase access, control of system resources, security, interactionwith other systems, network access and protocols, and so on.

Free your best people from infrastructure code-use them to writebusiness applications that can make your organization moreprofitable. There are only two ways to accomplish this: have ahorde of “second level” programmers working to maintain connectionswith your proprietary infrastructure, or use an applicationarchitecture that already provides all the plumbing. I know mychoice: Let the platform take care of the housekeeping; let thedeveloper 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 thepieces in place. J2EE provides an integrated system on multipletiers that will handle the “basic” functions of an enterpriseapplication. That leaves your developers free to work on thebusiness logic. Software development at the business levelshouldn't be that difficult. Well-architected systems provide asolid foundation on which to build your business models. J2EE iswell-architected.

Another Point of View

Ever since the release of Windows 3.11, Microsoft has beenworking to provide a unified platform for application development.It now has a sophisticated suite of back office and databaseapplications, as well as a model for distributed n-tierapplications development. In its .Net initiative, it has moved intoa Web services architecture that holds great promise. ItsDistributed Internet Architecture (DNA) model, based on COM+ andMTS, provides a solid backbone for its enterprise architecture.Nevertheless, Microsoft's approach to enterprise software istotally different than Sun's.

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

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

J2EE: What Is It?

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

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

Part of the underlying philosophy of Java is based on“containers.” For example, if you have an EJB (Enterprise JavaBean)-compliant container, you can deploy an EJB component on thatsystem. This concept not only makes the J2EE platform portable andextensible, it offers third party vendors an unprecedentedopportunity to be part of the enterprise development picture. Arelatively small player can develop a needed Java component (forexample, an EJB to access a DB2 mainframe database) and rapidlybring it to market. This encourages growth of the standard by wayof mutual cooperation, not exclusion.

Below are the principal components used in building a J2EEapplication system. Most have been around a while-most are stillevolving.

EJB: Enterprise Java Beans are already extensively used and haveproven their value. They are components that can be “dropped” ontoa client application and expose properties and methods than canused by that client application to perform whatever particularfunction they were created for. The 1.0 specification for EJBsexperienced some difficulties with beans compiled on one serverrunning in another; it was often necessary to recompile a bean fora particular server. In a bold move to alleviate that problem, Sunprovides for no backward compatibility with the 1.1 specification.What it has done, though, is make the deployment descriptor XMLbased, which will provide for increased compatibility in thefuture.

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

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

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

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

This all looks good for Sun. But keep in mind that not all ofthis is operational and fully functional-some is still underdevelopment. J2EE is a massive undertaking and there are doubtlesspitfalls yet to be uncovered. Given all that, if you need to buildmulti-tier, scalable business applications that must link to legacydata systems, you should take a hard look at J2EE. It may not bethe panacea, but it is definitely a step in the rightdirection.

It's Not Your Father's Java

J2EE takes all of these types and combines them into a standardarchitecture for enterprise development. Sun claims four elementsto the J2EE platform.

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

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

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

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

Battle Grounds

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