The Great Migration

Evolving Standards

Moving toward J2EE will present fewer problems for experienced Java developers, as Java's Enterprise Edition essentially builds on familiar ground. For example, J2EE features like EJBs and entity beans extend the basic JavaBean functionality in new and network-centric ways. The consistency of thought in the design of the Java APIs lets Java programmers build on their existing knowledge base and grasp new concepts quickly.

However, when you consider the entirety of the J2EE specification, its complexity can be intimidating. Version 1.3 comprises no less than thirty-two separate APIs; and with the release of J2EE 1.4, the total number of specifications that J2EE developers must track is slated to grow by more than 50 percent. The training costs to keep a development team up to speed on such a complicated technology are not insignificant.

Compounding the problem is the fact that the extant Java APIs are constantly evolving as well. On the one hand, this is a good thing. It's important that problems and shortcomings with previous versions of the J2EE APIs be addressed if the platform is to remain a viable technology for enterprise development. On the other hand, the frequent alterations to the J2EE specifications makes it difficult to keep actively deployed applications up to date with the current standards.

For example, EJBs, a core J2EE technology, already exist in three major forms. Beans written for the EJB 1.0 specification were not automatically compatible with EJB 1.1-compliant servers. Beans coded for version 1.1 can run in an EJB 2.0-compliant container without change; still, a company that has been developing applications on EJB version 1.x might be too tied to that architecture to begin coding new components to EJB version 2. It's difficult to assess which is greater: the risk introduced by rewriting existing components to suit the EJB 2 model, or the risk incurred by maintaining components written to a standard that soon may be obsolete.

Similarly, businesses with considerable investments in Microsoft's earlier COM and COM+ technologies should deliberate carefully before migrating those applications to the .Net. Technically, you don't need to discard your existing COM components when writing for the new framework. But .Net's COM support takes the form of a wrapper for legacy interoperability, rather than true integration. COM objects will be the weakest link in any .Net application design, because they must be run as unmanaged code outside the CLR. Though it's possible to get up and running with .Net using existing components, it's a good idea to plan on a thorough upgrade down the road.

In this regard, .Net is really no different from Java or any other software platform. Code rewrites are inevitable as standards and specifications grow and change. But in the case of .Net, a wholesale migration to the new platform seems particularly imprudent. The .Net technologies are fairly immature and still largely untested in mission-critical environments. Many organizations will wait for the specifications to mature further before staking critical business applications on them.

Single-Vendor Relationships

One common criticism of .Net (particularly from the Java camp) is that adopting Microsoft's platform will tie any new projects to the Windows platform. This is largely true, though it may change once Ximian's Mono project (www.go-mono.com) an open source port of the .Net Frameworkmatures. Even Microsoft has thrown a bone to developers on other platforms, with the release of the "shared source" version of its Common Language Infrastructure, codenamed Rotor. It remains to be seen how committed Microsoft is to welcoming Unix developers to the fold, however.

Still, lest J2EE developers get too smug, it's important to note that Java's "write once, run anywhere" ethos doesn't necessarily hold true for real-world projects, either. True, the portability of the Java language itself is probably better than that of any other compiled language. But for server-side code, problems arise at the level of the J2EE application server itself.

While the J2EE platform is technically "open," app server vendors like BEA, IBM, and Oracle routinely enhance their products with additional APIs that build upon Sun's J2EE specifications. When developers code to these vendor-specific APIs, they can tie a Java project to a single app server just as surely as .Net ties your applications to Windows.

"Just look at any job posting," says Jason Weiss, chief software architect for Personified Technologies, a Sugar Land, Texas-based development house. "You see phrases like 'WebSphere developers only, please,' or 'three years WebLogic experience at a minimum.'" Thus, no matter whether you choose J2EE or .Net for your projects, you can count on buying into heavy reliance on a single platform vendor.

One side effect of this is that the market for J2EE development talent is actually considerably narrower than the Java language's popularity may suggest. "As developers, we may have spent years learning J2EE, only to be out of a job because we don't know the idiosyncrasies of a different application server," says Weiss, adding that the search for qualified .Net developers is likely to be even more difficult. "There isn't anyone with three years of .Net experience in the world, not even at Microsoft."

A New Kind of Code

The proliferation of distributed systems is inevitable, particularly for enterprise integration, grid computing, and edge computing applications. Looking forward, the Semantic Weba vision of a future Internet where information is given structured, machine-interpretable meaning—will usher in an almost complete transition to network-centric computing. Companies that adopt J2EE and .Net are in a good position to begin developing these types of systems today.

Still, just because you can do something doesn't necessarily mean that you should. Distributed systems present unique problems, in and of themselves. Any distributed software project will be inherently more complex than doing the same task on a discrete system. In particular, traditional debugging tools are often ill-suited to working with applications that exist as components on several network-connected servers. Again, this can lead to longer development cycles and code that is potentially less reliable than that written for centralized systems.

Security is another top issue cited by most companies working with J2EE, .Net, and Web services in general. By virtue of their design, distributed applications must pass a variety of messages over the network, and protocols like SOAP offer no inherent security mechanism to prevent eavesdropping on sensitive application data. You should give careful thought to routing, firewalling, and encryption issues before deploying any .Net or J2EE application on the open Internet.

Also, don't overlook the hardware requirements of these complex software architectures. Your organization's existing hardware may not be suitable for running complex applications in a managed-code environment like the JVM or Microsoft's CLR. Server processing power is available at lower cost than ever before, but significant hardware upgrades always introduce risk. This in turn calls for additional lead-time before deploying an application.

How to Proceed?

Holy wars aside, it's hard to argue with either J2EE or .Net as a development platform. Each represents leading thinking on the best future direction for software development, and the weight of Sun and Microsoft behind their respective platforms is enough to ensure that they'll remain the market leaders in this space for the foreseeable future. Still, don't get railroaded into thinking they're the only games in town. Web services, for example, are based on open standards like HTTP, SOAP, and XML. There's nothing to keep you from implementing services using ColdFusion, Python, or any number of other solutions.

More importantly, don't confuse technological advancements with the needs they're meant to address. Migrating to J2EE or .Net shouldn't be your goal. Instead, you should focus on the specific business challenges that you face, and on finding the best solution for each task.

Some decisions are no-brainers. For instance, traditionally Windows-based shops launching new projects should probably start coding to .Net now. In other cases, the choice is more difficult. Even experienced Java shops may have a hard time deciding which version of the JDK to use for new projects. Should you start coding with the current J2EE specifications immediately, or wait for the forthcoming 1.4 release and the inevitable changes it will bring?

No matter what your situation, don't be lured into hasty action by vendor hype, particularly when migrating existing, critical applications. The decision to adopt leading-edge technologies for your projects is not without its hidden risks. Before you commit to any one platform vendor, ask plenty of questions and talk to other customers about their experiences.

Unfortunately, many companies are reluctant to reveal specific details about their projects, and hard data on the ROI of these platforms is virtually impossible to come by. In many cases, the best you can do may be to plan and manage your resources carefully. Be realistic in your assessments of the time, budget, and labor requirements of a large-scale .Net or J2EE rollout, and leave plenty of room for unforeseen developments. If, when all is said and done, the risks seem to outweigh the rewards, the best advice may be to wait. After all, whether or not you decide to go with the latest technological advancements, the best solution will be the one that works best for your business.