|
Microsoft's .Net framework and Sun's Java 2 Enterprise Edition offer developers unprecedented capabilities, but excitement over these new platforms often overshadows the risks. Learn how to avoid hidden pitfalls when migrating your apps.
February 12, 2003
URL:http://drdobbs.com/the-great-migration/184411632
J2EE or .Net? It's a question that seems to scream from the cover of every trade magazine and conference brochure. Sun's Java 2 Enterprise Edition (J2EE) and Microsoft's next-generation .Net framework are widely regarded as the future of enterprise application development.
Together, these two platforms represent a shift away from the traditional, centralized application development model to one that emphasizes distributed, network-centric applications based on XML. This evolution is particularly significant for larger enterprises, which are often faced with the challenge of integrating a variety of disparate applications and legacy systems.
While industry debate about the relative merits of J2EE versus .Net has at times taken on the tenor of a holy war, the argument over which technology will triumph is largely moot. The .Net developer strategy is remarkably similar to Sun's Java strategy in many ways. Each has merits, and their common goal is a laudable one. There's no real reason why either platform should emerge as the sole victor; in fact, many organizations will ultimately use both. A survey of six hundred developers conducted in October by Santa Cruz-based Evans Data reported that 61 percent of developers would target .Net in 2003, while 63 percent would code for J2EE.
Though a migration to one or both of these platforms may seem inevitable, it should still raise some concerns. A technology shift of the magnitude of a move to either J2EE or .Net calls for careful consideration and planning, and the tendency of Java or Windows platform loyalists to "leap before they look" should raise a red flag for any conscientious IT manager.
The underlying ideas behind both J2EE and .Net are fairly straightforward. Often, it's not the technologies that confound technology managers when they evaluate these new platforms, but the respective vendors' marketing campaigns. Microsoft's .Net, in particular, has always had something of an image problem: Exactly what is it, anyway? Is it network-delivered, subscription-based software? Is it Web services? Or just another application for XML?
Adding to the confusion, Microsoft announced a host of new .Net-branded products since it first publicized the strategy in 2000. Some of these, such as Windows .Net Server, have yet to arrive (as of this writing). Others, like the proposed Office.Net, seem to have a tenuous relationship to the underlying development platform at best. (In fact, as this issue goes to press, Microsoft has announced that it will be removing the .Net brand from several of its products, to avoid confusion.)
Sun's J2EE branding is similarly murky. Older APIs like servlets and JSP are now grouped under the J2EE specification umbrella, even though they predate J2EE as a whole. But many third-party products offer servlet containers or JSP engines without supporting some other J2EE concepts, like Enterprise JavaBeans (EJBs).
Does this mean that any tool that supports servlets and JSP is a J2EE environment? According to Sun, the answer is no. Sun requires that any product to be marketed as a J2EE solution must first pass its elaborate (and costly) certification process. As a result, open source implementations like JBoss (www.jboss.org) and Enhydra (www.enhydra.org) typically lack the budget for J2EE certification, despite full support for EJBs and other core J2EE technologies.
In the end, the actual extent to which Microsoft's and Sun's most cutting-edge technologies are deployed in real-world applications is difficult to gauge. According to Evans Data, only 40 percent of developers surveyed were working on the .Net platform in October 2002, and less than half were working with Web services of any kind. Given the onslaught of marketing associated with both .Net and J2EE, separating the reality from the hype should remain foremost in the mind of any technology manager evaluating these products.
For the moment, let's forget about which Microsoft software has or hasn't been branded ".Net," and concentrate solely on the .Net framework itself. The portion of the platform that concerns developers consists of several main components. One is the Common Language Runtime (CLR), an environment that compiles and runs intermediate byte code on the fly, similar to Sun's Java Virtual Machine (JVM). There are also new class libraries and APIs like ADO.Net and ASP.Net, as well as Visual Studio .Net (VS.Net), the primary development tool for the platform.
There can be little doubt that, eventually, nearly every Windows programmer will write applications using some portion of the .Net framework. When Microsoft announces a strategy shift of this significance, developers have little choice but to come along for the ride. Still, the learning curve could be daunting; enough so that your organization may want to wait a while before discarding older development methods completely.
Java reinforces its development model by demanding adherence to a strict syntax and clearly defined code security guidelines. But when Microsoft designed its CLR environment, it wanted to give developers more flexibility. Unlike the JVM, the CLR lets developers write to the .Net framework using a variety of languages. The "preferred" language is C#, a sophisticated successor to Microsoft's Visual C++, but there are several others, including C++ and even Microsoft's own approximation of the Java syntax, called J#.
Microsoft also allows programmers to designate portions of their C# as "unsafe." While Java insists on a strictly defined security model in which the virtual machine controls all system resources, unsafe CLR code has access to low-level memory manipulation features that closely resemble C's pointers. (See "Unsafe At Any Speed," August 2002, for more information.)
The downside of all this flexibility is that it makes it easier for .Net developers to learn bad programming habits that traditional Windows developers haven't had to confront. While it may be tempting to let individual coders write for .Net in the language of their choice, failing to standardize on a single language can lead to code maintenance nightmares. It shouldn't take long for experienced C++ developers to get up to speed with C#, but you'll want to build some additional time into your project to accommodate the transition.
The concepts of frameworks and the managed code model may also be new ones to developers accustomed to traditional executables, DLLs, and ActiveX controls. Unless a .Net migration project is carefully managed, the temptation for developers to fall back on old ideas and training can be strong, and there is little in the design of the platform itself to discourage them from doing so.
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.
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."
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.
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.
Before You Start a New Project
—NM
|
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.