Migration from Previous Platform 

For organizations who have an existing deployment using either J2EE-based technologies or Windows DNA-based technologies, an interesting discussion is the ease of migration from the previous platform to the new platform. 

J2EE does not impose many migration problems. As previously mentioned, the Java Connector Architecture (JCA) as well as the web services support in J2EE is brand new and will require new code, but those are minor overall. 

Although Microsoft.NET is based on MTS and COM+, we are concerned that the migration to .NET will be taxing compared to J2EE. First off, .NET is based on the “managed code” framework, which steals a lot of ideas from COM+ and MTS, but it’s still an entirely new infrastructure based on an entirely new code base - CLR. Taking advantage of the most valuable aspects of the CLR impose one-time frictions. 

For example to accommodate a Common Type System (CTS) which standardizes on data types used between languages, the original Visual Basic data types have been dismissed. Consequently, code dependent upon those original Visual Basic data types will break, and there is currently no migration tool. 

Another example is the COM+ migration path. In .NET terminology, code that runs within the CLR is referred to as managed code, while code running outside the CLR is called unmanaged code. If you're a COM+ developer and want to take advantage of the new CLR, then you have two options for migration: 

Rewrite existing code as CLR code. . COM+ code needs to be rewritten to accommodate the CLR’s automatic garbage collection mechanism and its deprecation of pointers. Dependencies also need to be removed to the COM registry. 


Keep your existing code as unmanaged. To collaborate between managed and unmanaged code, special measures must be taken. 
So as you can see, migration is not free. But to Microsoft's credit, we do understand that with the innovation of the CLR, that this is a necessary step for their customers to evolve into their new platform, and with such a radical change nothing less could be expected. However, we feel obligated to warn users that the migration path will not be easy compared to J2EE migration path, as some might have you believe. Consider these statements from a recent Gartner report: 

“‘This is fundamentally a brand new platform,’ said Gartner Analyst Mark Driver, comparing the migration to .NET as more drastic than the switch from MS-DOS to Windows. ‘This is the tiger changing its stripes...the migration to .NET will be a difficult one for IT departments because it represents such a major shift from the current Microsoft platforms. For instance, developers will have to rewrite as much as 60 percent of the code for some existing Windows applications if they want them to take advantage of Microsoft's .NET platform, Gartner analysts predicted. That's a frightening prospect for companies who are currently switching to Windows 2000, or for those who still run Windows 98 and NT.” 


Portability 

A key difference between J2EE and .NET is that J2EE is platform-agnostic, running on a variety of hardware and operating systems, such as Win32, UNIX, and Mainframe systems. This portability is an absolute reality today because the Java Runtime Environment (JRE), on which J2EE is based, is available on any platform. 

There is a second, more debatable aspect of portability as well. J2EE is a standard, and so it supports a variety of implementations, such as BEA, IBM, and Sun. The danger in an open standard such as J2EE is that if vendors are not held strictly to the standard, application portability is sacrificed. CORBA, for example, did not have any way to enforce that CORBA middleware did indeed comply with the standard, and thus there were numerous problems with portability. In the early days of J2EE there were the same problems. 

To help with the situation, Sun has built a J2EE compatibility test suite, which ensures that J2EE platforms comply with the standards. This test suite is critical because it ensures portability of applications. At the time of this writing, there were 18 application server vendors certified as J2EE-compatible. There are a myriad of other vendors as well that are not certified10. 

Our opinion is that in reality, J2EE portability will never be completely free. It is ridiculous to think that complex enterprise applications can be deployed from one environment to the next without any effort, because in practice, organizations must occasionally take advantage of vendor-specific features to achieve real-world systems. However--and this is important--portability is exponentially cheaper and easier with J2EE and the compatibility test suite than with proprietary solutions, and that is a fact we stand behind through years of consulting with customers using a variety of J2EE solutions. Over time, as the J2EE compatibility test suite becomes more and more robust, portability will become even easier. 

By way of comparison, .NET only runs on Windows, its supported hardware, and the .NET environment. There is no portability at all. It should be noted that there have been hints that additional implementations of .NET will be available for other platforms. However, a question remains - how much of the complete .NET framework will be (or even can be) supplied on other platforms? History has taught us to be skeptical of Microsoft's claims of multiple platform support. Microsoft ported COM to other platforms, but never ported the additional services associated with COM that were necessary to make COM useful. We find it hard to believe that .NET portability will ever become a reality given Microsoft's historically monopolistic stance. 

So how important is portability to you? This is the key question businesses must ask themselves. When evaluating the importance of portability, there are three scenarios worth considering. 

If your firm is selling software to other businesses, or if you are a consulting company, and your customers are on a variety of platforms, we recommend specializing in J2EE architecture. Unless you can guarantee that every one of your customers will accept a Windows/.NET solution, you are restricting your salespeople from major accounts that may have solutions deployed on UNIX or mainframes. This is rarely acceptable at most ISVs or consulting firms. 

If, on the other hand, your customers are on the Windows platform, then either J2EE or .NET will suffice, since they both run on Windows. You should then ask your sales force and consultants what middleware your customers are using on that platform, and make your architecture decision from there. It's important to really be proactive and get this information--the more data you have, the better. 

If you host your own solutions, then you control the deployment environment. That enables you to pick J2EE as well as .NET. If you are willing to standardize on the Win32 platform, and live with the advantages and disadvantages of that platform exclusively, then platform neutrality is irrelevant, and you should consider other factors when deciding on J2EE or .NET. But we offer a word of caution: you can never predict the future. Business goals might change, new vendors might be introduced into the picture, and mergers and acquisitions might happen. All of these may result in a heterogeneous deployment environment. Your applications will not be portable to those platforms in this scenario. 
We offer a final opinion to end the debate about just how important is portability. Although both J2EE and .NET will each have their audiences, think about what platform you would choose if you were an ISVs or a consulting company. Most likely you'd have customers on a variety of platforms, and therefore, you'd probably adopt the architecture behind J2EE because you don't want to lock yourself out of deals. 

Indeed, we are noticing today that an incredible number of consulting firms and ISVs are standing behind J2EE, such as Vignette, Broadvision, Chordiant, Kana, NaviSys, and Versata. 

What does this mean? It's not about the platform, it's about the applications. As time goes on, customers will likely choose the solution that not only provides the web services infrastructure, but the most consulting support and ISV applications as well. 

This makes the future of J2EE very bright in our minds, and is one of the critical differentiators between J2EE and .NET. 


Web Services Support 

The future of eBusiness collaboration is undoubtedly web services. For organizations that are pursuing a web services strategy, or are preparing for the future of web services, their underlying eBusiness architecture must have strong web services support. 

Today, J2EE supports web services through the Java API for XML Parsing (JAXP). This API allows developers to perform any web service operation today through manually parsing XML documents. For example, you can use JAXP to perform operations with SOAP, UDDI, WSDL, and ebXML. 

Additional APIs are also under development. These are convenience APIs to help developers perform web services operations more rapidly, such as connecting to business registries, transforming XML-to-Java and Java-to-XML, parsing WSDL documents, and performing messaging such as with ebXML. 

A variety of J2EE-compatible 3rd party tools are available today that enable rapid development of web services. There are at least sixteen SOAP implementations that support Java. Almost all of these implementations are built on J2EE (servlets or JSP). There are only five UDDI API implementations available, and four of them support Java (IBM UDDI4J, Bowstreet jUDDI, The Mind Electric GLUE, and Idoox WASP). Third-party software vendors such as Tradia (www.tradia.com ), CapeClear (www.capeclear.com ) and The Mind Electric (www.themindelectric.com ) also offer tools for creating web services. 

The preview release of Microsoft.NET also enables organizations to build web services. The tools that ship with Microsoft.NET also offer rapid application development of web services, with automatic generation of web service wrappers to existing systems. You can perform operations using SOAP, UDDI, and SDL (the precursor to WSDL). Visual Studio.NET provides wizards that generate web services. 

Our conclusions from our web services comparison are as follows. 

With J2EE, you can develop and deploy web services today using JAXP. However, this is not the ideal way to build web services, since it requires much manual intervention. An alternative is for organizations to leverage 3rd party libraries to accelerate their development. In the future these libraries will be standardized through the JAX APIs. For now, if you develop web services rapidly, you'll need to bundle these libraries with your application. 

With .NET, you can develop web services today using the partial release of .NET. However, since this is only a beta implementation, it does not represent a realistic deployment platform. Another issue with .NET is that it does not support true web services because of a lack of support for ebXML. ebXML is a very important standard for eBusiness collaboration, and is experiencing broad adoption from around the world. Thousands of vendor and non-vendor companies, government institutions, academic and research institutions, trade groups, standards bodies, and other organizations have joined the ebXML community. This includes HL7 (Health Care), OTA (Open Travel Alliance), RosettaNet, OAG (Open Applications Group), GCI (Global Commerce Initiative), and DISA (Data Interchange Standards Association). Undoubtedly, ebXML is going to be an important force in web services, and we hope that Microsoft chooses to embrace it. Microsoft is still clinging to their BizTalk proprietary framework which has proprietary SOAP extensions. This evidence makes us question Microsoft's true commitment to open and interoperable web services. 


Tools 

The Sun J2EE Product Portfolio includes Forte, a modular and extensible Java-based IDE that pre-dates both Sun J2EE and .NET. Developers who prefer other IDEs for Java development are free to use WebGain’s Visual Café, IBM’s VisualAge for Java, Borland’s JBuilder, and more. Numerous 3rd party tools and open source-code products are available. 

Microsoft has always been a strong tools vendor, and that has not changed. As part of its launch of .NET, Microsoft released a beta version of the Visual Studio.NET integrated development environment. Visual Studio.NET supports all languages supported by earlier releases of Visual Studio - with the notable exception of Java. In its place, the IDE supports C#, Microsoft’s new object-oriented programming language, which bears a remarkable resemblance to Java. Visual Studio.NET has some interesting productivity features including Web Forms, a web-based version of Win Forms, .NET’s GUI component set. Visual Studio.NET enables developers to take advantage of .NET’s support for cross-language inheritance. 

Our conclusion is that Microsoft has the clear win when it comes to tools. While the functionality of the toolset provided by J2EE community as a whole supercedes the functionality of the tools provided by Microsoft, these tools are not 100% interoperable, because they do not originate from a single vendor. Much more low-level hacking is required to achieve business goals when working with a mixed toolkit, and no single tool is the clear choice, nor does any single tool compare with what Microsoft offers in Visual Studio.NET. Microsoft's single-vendor integration, the ease-of-use, and the super-cool wizards are awesome to have when building web services. 



Shared Context 

A key element of smart web services is shared context. To understand shared context, think about how many usernames, passwords, credit card information, and so-on that you need to remember and re-type in every time you visit a web site. The vision for shared context is that you type this information in once, and that information is then accessible to all web services that you choose to give access to that information. The information is under your control, rather than the control of the web services, and is protected using security rules that you define. 

The Sun J2EE vision for shared context is a decentralized, distributed suite of shared context services that live on the Internet. Each user might have a list of one or more of their preferred shared context services, with each repository storing select information about that user. You would point the web service to your preferred shared context service when you connect. 

Today, developers are empowered to create shared context services by writing a servlet that exposes itself as a web service using JAXP, and by using JDBC to access a relational storage. 

In the future, Sun J2EE will include standards to access shared context services. This will enable the context repositories to act as web services using a standard interface, empowering other web services to connect with and tap into the shared context service in standard ways. 

By way of comparison, Microsoft.NET achieves shared context via the Passport.NET service. Passport.NET is a repository hosted by Microsoft that contains user identity information. It is the cornerstone to Microsoft's Hailstorm services, which is their vision for creating user-centric web services experiences. 

In conclusion, we have found that both Sun J2EE and Microsoft.NET support shared context, and each have their own advantages and drawbacks. The noticeable difference is that the Sun J2EE approach of a shared context standard will spawn a marketplace of shared context repositories on the Internet, whereas the Microsoft.NET solution is a single shared context repository approach. 

The advantages of the Sun J2EE approach are: 

Each shared context repository can be specialized for different needs. For example, there could be medical repositories that store medical history information, or financial repositories that store credit card and banking information. It is unlikely that a single repository approach such as Passport.NET would be specialized enough to cover all the bases of shared context information that the industry demands when smart web services become widely used. 
There is no 'big brother' effect. Businesses and individuals do not need to trust their data to any individual firm. Local shared context repositories can be created within a trusted few partners in a business web, which means data can be contained. 
We believe the J2EE solution will will scale to handle the needs of the masses. The needs of the many better then Passport.NET. Shared context is a more important phenomenon than any one organization. 
There is no single point of failure. 
There is no control being enforced by a single organization. Can you envision a time when AOL agrees to use Passport? Or when VISA, MasterCard, or American Express agree to let Microsoft control their customers’ information? It is difficult to imagine just one vendor-controlled identity service succeeding for all. 
The advantages of the Microsoft.NET approach are: 

There is no question of what is the 'official' shared context repository. There is one place to find identity information. This is a very important point. J2EE runs the risk of a fragmented shared context repositories, eliminating the usefulness of such systems, unless care is used. 
Passport is an established and active system. 
Until Sun J2EE standardizes on a schema and API for accessing web services that are shared context services, we do not predict any real usage of J2EE-based shared context services. 
Given that almost no web services use shared context yet, it is too early to tell which approach is the best. Fortunately most organizations are barely getting up to speed with the basics of web services, and shared context is in the distance. For most organizations, this debate is likely to be important when choosing J2EE or .NET. 


System Cost 

A wide variety of implementations based on J2EE architecture are available for purchase, with price points varying dramatically, enabling a corporation to choose the platform that meets its budget and desired service level. Costs are typically in the single-digit thousands of dollars per processor, although there are higher-end implementations and lower-end ones. At the time of this writing, Microsoft had not released pricing information for the .NET platform. 

As far as hardware, J2EE supports UNIX and Mainframe systems, while both J2EE and .NET support the Win32 platform, which is generally the less expensive alternative. There is a level playing field for hardware costs, and the hardware cost debate becomes a moot point. 

The takeaway point is that you can get low-cost solutions with both Microsoft and J2EE architecture. Microsoft's solution has an aggressive price, whereas J2EE architecture allows you choose your service level. For example, with J2EE you can have a high-end, expensive solution (iPlanet running on Sun Solaris in an E-10000 server), or a low-end, inexpensive solution (jBoss running on Linux on a Cobalt RAQ server). There's also an assortment of free and/or open source tools and services that support Java and XML. It should be noted that you pay for what you get, and most organizations will not go for this low-end solution, but rather will embrace a midrange solution as a happy medium. 

If you are trying to make heads or tails out of the price wars, we recommend that you consider this: the price of the platform is always a drop in the bucket compared to the total cost of the project. This is defined as the price of the server platform, the cost to train developers, the cost to build and evolve a solution on that platform, the cost to maintain the solution, and any business opportunity costs from picking the 'wrong' platform. 

We hope that firms realize that the total cost of ownership of a project dwarfs any short-term cost differences between underlying platforms. We recommend you do not consider the price of the platform when selecting between J2EE, .NET, or any other platform, but rather consider the more important other factors.