Ninety Percent Pure Java

Going forward, only two platforms matter for building new enterprise applications. One is Microsoft Corp.'s environment, particularly Windows 2000. The other is the Enterprise Java environment defined by Sun Microsystems, IBM and others. I believe both of these platforms have a good future: Both will succeed, and both will provide a reasonable foundation for enterprise applications.

If you’re an ISV or in-house software developer, you must make a choice about how to build your products. There are three options. First, you can bet solely on Microsoft, writing code as if the Java Enterprise world doesn't exist, and exploiting to the max the services Windows 2000 provides. In this case, your developers can assume Active Directory is present, build MMC-based management tools, expose developer APIs using COM and rely completely on Windows 2000 security services. In many cases this is the right choice, and lots of code will be written this way.

Another alternative is to do the reverse: Act as if Windows 2000 doesn’t exist, and create a 100 percent pure Enterprise Java application. This is what Sun and some of its cohorts would like you to do, and it has some attractions. Your application could assume the same services are available everywhere -- the Enterprise Java services -- and write to them. To access a directory, for instance, the app would use the Java Naming and Directory Interface (JNDI). Management interfaces would likely be Web-based, security would rely on SSL and developer APIs would be exposed using Java. No matter what platform your app is deployed on, it would look the same, providing a consistent approach to management, security and other services.

I don’t think many ISVs or in-house organizations will take this route. Windows NT and, someday, Windows 2000 are just too popular. Applications that don’t feel natural to developers and administrators working on Microsoft systems won’t be welcomed by a significant part of the end-user population. Instead, software developers who would ideally choose the pure Enterprise Java route will likely be forced into the third approach, something we might call 90 percent pure Java.

In this approach, developers build their application to run on many operating systems. Accordingly, the application has all the hallmarks of an Enterprise Java application: It exposes developer APIs using Java, provides Web-based management tools, can use various directory services and so on. To developers and administrators looking for a consistent look and feel across all operating systems, this product will fit the bill.

Critically, however, this application also exploits Windows 2000 features. Along with its Web-based management interfaces, for example, it also provides MMC snap-ins. Alongside its Java APIs, it exposes COM-based APIs to developers. And rather than always assuming the generic directory and security services of the Enterprise Java world, the application takes advantage of Active Directory and Kerberos, the Windows 2000 solutions to those problems. Instead of building a pure Enterprise Java application, developers who wish to be successful will add features that make this application fit well in the Windows 2000 environment. To do anything else is to give up on the large market the Microsoft world represents.

Whether you’re a creator or consumer of enterprise software, you have a choice to make. Are you willing to bet solely on Microsoft? If so, build or buy products that take the first route, completely exploiting the features of Windows 2000. Plenty of ISVs and end user organizations are already on this path. I expect it to become the majority position over time.

But it’s not right for everybody. If you want applications that run on multiple platforms, look to the Enterprise Java world. It’s much newer than the Microsoft world, but due especially to IBM’s strong backing, it looks like a safe bet. Make sure, though, that the applications you build or buy aren’t purely focused on Enterprise Java. If Windows NT/2000 is a significant part of your environment -- and it must be or you wouldn’t be reading this publication --insist on multiplatform Java applications that include customizations for the Microsoft environment. Some software developers may resist this, since it means significantly more work for them. Yet given the size of the Microsoft market, insisting on developing 100 percent pure Enterprise Java software looks like suicide. --David Chappell is principal of Chappell & Associates (Minneapolis), an education and consulting firm. Contact him at