Although Java has played a major role in Web development over the last few years, weıre already at the point of questioning its viability and its ability to solve enterprise-class problems. Words such as these are blasphemous considering the mediaıs love affair with Java, but I for one believe itıs time to figure out what Java can and cannot do for us.
Make no mistake. Iım not saying that Java is not good technology. It is clearly changing the look of Web-based applications. What I am saying is that Java, like other technologies, has its place. This month letıs examine the hard facts and figure out where that place is.
When looking at Java, you have to consider its architectural characteristics (the Hot Java architecture). As is the case with all architectures, Java has its strengths and weaknesses.
Clearly Javaıs strength is its portability. Java is able to run on most client platforms where you can find the JDK, and it can do so through the same sets of bytecode (although Iıve not been able to prove this, and platform-specific problems are still out there). This makes Java, at least in my book, one of the first truly successful "write once, run anywhere" application development technologies. You have to remember that weıve done this before. The difference here is that Javaıs value proposition puts the Web first, portability second.
Now itıs time for the tough love. As with portable application-development technologies, Java cannot be all things to all platforms. As we saw in the world of standard client/server, portable application-development tools only support a subset of features on each client platform. This means that the application developer may only exploit few or no native features to maintain portability. While this may seem like a reasonable trade-off to most application developers when they hear the sales pitch, most lose interest once they realize that youıre no longer able to take advantage of all native features such as COM, MAPI, threading subsystems, or calls to native middleware.
Many developers head down the road to portability but soon see the need to exploit the power of native features and functions. Then they build the native calls in applications, making them nonportable using a portable language such as Java. Not very smart, but Iıve seen this more often than you would think. This was the argument against the Microsoft JDirect technology. By placing native Windows 95 and Windows NT calls within the applet or application, suddenly those Java solutions become nonportable, but able to exploit the native features of Windows. Whatıs more, Microsoft is looking to rebuild the Java virtual machine to make accessing native Win32 features easy. JavaSoft, of course, is fighting back with its "100 percent Pure Java" campaign and a pile of attorneys. The battle rages on.
The inability of Java to support native features on all platforms brings up some performance issues as well. Java is able to remain portable by placing a layer between the applet or application bytecode and the native features of the platform. (See Figure 1.) This layer, the Java Virtual Machine (JVM), translates the requests of the applet or application into native calls. If this smells like an interpreter to you, youıre right. And as an interpreter, Java canıt run as fast as native compiled applications. Donıt count on getting native performance out of your Java applet or application unless you embed many native calls in the program, and that will cost you the portability and Web compatibility that made you turn to Java in the first place.
Innovative Java development companies want to solve the performance problem. However, in order to keep the core Java architecture intact, this is going to be a difficult problem to solve on all supported platforms. Just-in-time compilers are great technology, but they donıt take you anywhere near native performance.
The Java performance issue is going to become even more important in the ActiveX vs. Java debate. ActiveX, at its core, is a native Windows application (a 32-bit DLL, really, and an in-process Automation server), and as such it runs at the native speeds on Windows 95 and Windows NT. JavaSoftıs argument is that ActiveX is not portable (keep in mind that there are implementations on non-Windows platforms now). However, with the majority of people running Windows, portability may no longer be an issue for the masses. Stay tuned for more debates on this issue.
Putting the performance and native-features issues aside for the moment, the real concern for Java is its use ı and more important, its misuse ı for enterprise application development. Many IT managers out there, managing by magazine, see Java as a strategic rather than tactical technology. Clearly, Java is forced into application-development projects where it is used to process a large transaction and user load. Java seems to be a good development approach for some workgroup-sized applications, especially those applications that use the Web. But Java, when standing alone, falls down quickly if challenged to scale to the enterprise level.
So how do you make Java scale? Java is effective when teamed with traditional middle-tier technology such as TP monitors and distributed objects. You simply use Java as the presentation layer connecting to back-end application processors. However, there is a minority out there seeking to use Java as a server-side technology as well. Even server-side Java fails to scale because of the same issues I raised already: the use of an interpreter and the lack of direct access to native platform features.
IBMıs implementation of Java on the 390 platform is the best example of this scalability issue. Although IBM is promoting Java on the 390 as an enterprise-class solution, there is still no evidence that IBM will provide the scalability within its Java implementation (JVM for the 390) on its new minimainframe. However, IT managers all over the globe are banking on IBMıs Java as a means of "Javatising" their existing and new enterprise-class applications. For those of you in this boat, I suggest you do some performance and load testing before you throw that application out there. My guess is that youıre in for a surprise.
There are some Java-enabled enterprise solutions out there. Products such as Netscapeıs recently acquired Kiva technology can provide a transaction processing-like environment for Java to provide scalability. Other traditional client/server application servers are looking to play with Java as well, including BEA Systems Inc.ıs Tuxedo and the Microsoft Transaction Server (more on these later). But Java for the enterprise, at least today, is not a good idea unless youıre willing to mix and match technology. Java can add value to enterprise application development, but it cannot yet scale by itself.
Netscape, however, could be going soft on Java. At press time, the San Jose Mercury News reported that Netscape is pulling back from its Java commitment. Netscape is finding that itıs difficult to make Java applets run well in Netscapeıs heterogeneous Web browsers. When Netscape began to support Java in 1995, it had to support Java on 17 different platforms and update each platform with new software as JavaSoft changed Java. This kind of work was too resource intensive, and Netscape will now rely on operating system vendors such as Microsoft and Sun to enhance Java over time. Netscape is not only canceling its Java projects but releasing people as well, with 400 people marching out the door after a disappointing $89 million loss this quarter. You can count on other companies taking a similar stance as the hype of Java butts its head against technology and business realities.
Things, however, may be looking up for Java in the enterprise. The Enterprise JavaBeans specification defines a server-side component model for JavaBeans. Enterprise JavaBeans, simply put, are specialized JavaBeans that run on a remote server ı distributed objects, really. Using the same architecture as traditional JavaBeans, Enterprise JavaBeans can be clustered together to create a distributed application with a mechanism to coordinate the processing that occurs inside of the JavaBeans.
The Enterprise JavaBeans model supports the notion of implicit transactions. Each Enterprise JavaBean does not need to specify the transactional demarcation point to participate in distributed transactions. This feature is key. The Enterprise JavaBeans execution environment automatically manages the transaction on behalf of the Enterprise JavaBeans. The transaction policies can be defined during the deployment process using standard procedures. Moreover, transactions may be controlled by the client-side applications.
The Enterprise JavaBeans model defines the relationship between an Enterprise JavaBeans component and Enterprise JavaBeans container system. Enterprise JavaBeans do not require the use of a specific container system. Furthermore, any application execution system, such as a TP monitor, can be adapted to support Enterprise JavaBeans by adding support for services defined in the Enterprise JavaBeans specification (see www.javasoft.com for more information). The services in the specification define relationships between Enterprise JavaBeans and a container, and they provide a portability layer as well. Thus, any Enterprise JavaBeans can run in any execution system supporting the Enterprise JavaBeans standard.
The Enterprise JavaBeans execution system is called the Enterprise JavaBeans Server, which provides a standard set of services to support Enterprise Beans components. Enterprise JavaBeans and the Enterprise JavaBeans Server are analogous to traditional transactional systems. Thus, an Enterprise JavaBeans Server must provide access to a standard distributed transaction-management mechanism. An Enterprise JavaBeans container implements the management and control services for a class of Enterprise JavaBeans objects. In addition, this system provides lifecycle management, transaction control, persistence management, and security services. The idea is to allow a single vendor to provide both the Enterprise JavaBeans Server and the associated Enterprise JavaBeans container.
Enterprise JavaBeans are a step in the right direction; however, the specification does not give detailed definitions of the exact nature of the technology, such as thread pooling, concurrency control, and resource management. Although this provides vendors with an excuse to differentiate their products, it also allows them to stray in different directions using different proprietary mechanisms. My guess it is that traditional TP monitor environments will be the best place for Enterprise JavaBeans. For example, count on seeing Enterprise JavaBeans together with TP monitors such as IBMıs CICS or BEAıs Tuxedo. New component transaction servers such as Sybaseıs Jaguar CTI or Microsoft Transaction Server are also logical environments for Enterprise JavaBeans. I also see other CORBA-compliant distributed object platforms, such as Borlandıs VisiBroker/ITS (which Borland acquired as part of the Visigenic acquisition in November 1997) or Ionaıs Orbix/OTM working with this technology as well.
Technology such as Enterprise JavaBeans has great potential, but it also has its drawbacks. In order to maintain portability, Enterprise JavaBeans needs to place a layer between the executing code and native operating system. This is not so much of a problem when creating presentation layers, but transactional layers need all the help and all the native resources they can get. Thus far I see only native applications and components playing in this arena. This does not mean that there is not a future for Enterprise JavaBeans, only that itıs going to be yet another trade-off in the of world Java. There are always trade-offs; you just need to know where they are.
Figure 1. Java is able to remain portable by placing a layer between the applet or application bytecode and the native features of the platform. This layer is the JVM.