V. Comparative Analysis
--------------------------------------------------------------------------------
Time-to-Market Features
When developing a commerce solution in today's marketplace, a few months of time is an eternity. Missing a small window of opportunity is the difference between a corporation that is first to market, and a corporation that must play catch-up for years.
One way to speed time to market is to choose a Web services platform that allows rapid application development. This enables developers to write and maintain code quickly, lowering development time.
Both Sun J2EE and Microsoft .NET provide runtime mechanisms that insulate software developers from particular dependencies. In addition to a web service-oriented XML layer of indirection between platforms, languages, and enterprise architectures, Sun J2EE and .NET offer language-level intermediation via the Java Runtime Environment (JRE) and the Common Language Runtime (CLR) respectively.
J2EE offers several features that accelerate time-to-market which are not found in .NET. For example, state management services enable developers to write less code and not worry about managing state, resulting in a higher degree of rapid application development. State management services enable you to build components that hold state. Persistence services (entity beans) enable developers to write applications without coding data access logic, resulting in leaner, database-independent applications that are easier to build and maintain. Programmatic transactions allow you to have greater transactional control. And custom tags are extremely powerful, and empower developers and web designers to easily collaborate.
In addition to these features that enable rapid application development, there are several features that specific vendors offer which aid time-to-market, such as business process management, E-Commerce components, XML-based legacy integration, and enhanced B2B collaboration. A warning: Customers who elect to leverage these features will sacrifice portability. This is a consequence of J2EE architecture not being all things to all people. However, it should be noted that even after taking advantage of such proprietary features, there would still be a great deal more portability in the end solution than the .NET alternative.
Microsoft.NET offers a variety of time-to-market features not found in J2EE as well. Most notably, ASP.NET is independent of client device, and allows for user interfaces to be rendered to alternative user interfaces without rewriting code. Microsoft also offers Queued Components which are superior to MessageDriven Beans. It should be noted here that Microsoft has tried to simplify server-side programming greatly by removing support for features found in traditional enterprise applications, such as stateful servers and simple transactions. If developers need to go outside this box, their code must be made to be non-managed and reside outside the .NET Framework rather than take advantage of it. Microsoft also provides business process management and E-Commerce capabilities, which are available in some J2EE implementations but not all.
In conclusion, we feel the ability to achieve rapid application development offered by both J2EE and .NET is definitely not equal. It is, however, comparable. The feature differences are minor and it is very difficult to make a compelling argument either way. We do not recommend organizations make their platform decision based upon them. There are larger business issues at hand that dictate the platform choice.
Single-Vendor Solution
When building web services, in general you should always prefer to have a single-vendor solution. A single vendor solution is usually more reliable, interoperable, and less error-prone than a two-vendor bridged solution.
One of J2EE's strengths is that it has spawned a wide variety of tools, products, and applications in the marketplace, which provide more functionality in total than any one vendor could ever provide. However, this strength is also a weakness. J2EE tools are often-times not interoperable, due to imperfections in portability. This limits your ability to mix and match tools without substantial low-level hacking. With lower-end J2EE implementations, you need to mix and match to get a complete solution, and this is the tradeoff when choosing a less complete package. Larger vendors, such as IBM, Oracle, BEA, and iPlanet, each offer a complete web services solution.
.NET provides a fairly complete solution from a single vendor--Microsoft. This solution may lack some of the higher end features that J2EE solutions offer, but in general, the complete web services vision that Microsoft will be providing is equal in scope to that of a larger J2EE vendor.
Another way to look at a single-vendor solution is from a legacy perspective. Many legacy systems are written by J2EE vendors, such as IBM or BEA. J2EE offers a single-vendor solution from the legacy integration perspective, since you can re-use existing relationships with those vendors. A J2EE solution would therefore be a single-vendor solution, since you can stay with that legacy system vendor rather than inject a new vendor such as Microsoft. For users with existing Microsoft-based systems, the reverse argument applies.
Support for Existing Systems
Most large corporations have existing code written in a variety of languages, and have a number of legacy systems, such as CICS/COBOL, C++, SAP R/3, and Siebel. It is vital that corporations be given an efficient, rapid path to preserve and reuse these investments. After all, it is likely that businesses will have neither the funds nor the time to reinvent all existing systems. This legacy integration often is one of the most challenging (if not the most challenging) tasks to overcome when building a web service.
There are several ways to achieve legacy integration using J2EE, including
The Java Message Service (JMS) to integrate with existing messaging systems
Web services to integrate with any system
CORBA for interfacing with code written in other languages that may exist on remote machines.
JNI for loading native libraries and calling them locally.
But by far, the most important part of the J2EE vision for integration is the J2EE Connector Architecture (JCA). The JCA is a specification for plugging in resource adapters that understand how to communicate with existing systems, such as SAP R/3, CICS/COBOL, Siebel, and so-on. If such adapters are not available, you can write your own adapter. These adapters are reusable in any container that supports the JCA. The major vendors of existing systems are bought into the JCA.
.NET also offers legacy integration through the Host Integration Server 2000. COM Transaction Integrator (COM TI) can be used for collaborating transactions across mainframe systems. Microsoft Message Queue (MSMQ) can integrate with legacy systems built using IBM MQSeries. Finally, BizTalk Server 2000 can be used to integrate with systems based on B2B protocols, such as Electronic Data Interchange (EDI) (the reader should note, however, that BizTalk does not serve as an access point to a proprietary network on which EDI takes place).
In conclusion, we believe that the legacy integration features offered by J2EE are superior to those offered by .NET. The JCA market is producing a marketplace of adapters that will greatly ease enterprise application integration. Integration with packaged applications and legacy systems will become much easier--imagine integrating with a system such as Siebel, Oracle, or SAP without ever leaving the Java programming environment. There is no analog to this in the Microsoft domain; rather, there is limited connectivity to select systems provided off-the-shelf through the Host Integration Server.
Market Perception
When comparing two platforms, your first instinct is probably to compare the technologies. The unfortunate reality is that good technology rarely succeeds in the marketplace because it's good technology. Usually it's the technology with the best marketing that wins.
J2EE is an extremely well-marketed platform because it is being marketed by an entire industry of 50+ assorted vendors. This network of interdependent businesses form a virtual marketing machine, and the result is a fantastic market perception for J2EE.
.NET's marketing strength stems from the fact that Microsoft knows how to market a platform. They have put their "A" team on marketing .NET, as is apparent in the industry hype surrounding the platform. This is a powerful force not to be reckoned with. Microsoft's advantage is also that it announced it's web services strategy before the J2EE players, which gave it market perception. So in the marketing front, we give the nod to Microsoft for doing the best job in hyping their platform--so far.
Maturity of Platform
Organizations that adopt a web services platform must consider the maturity of the underlying platform. A less mature, earlier-generation platform is more prone to errors and problems.
J2EE is a veneer atop existing J2EE solutions. J2EE deployments are alive and healthy, running a variety of mission-critical business problems today. However, when looking past the surface, it should be noted that there are some identifiable areas of risk where J2EE lacks maturity:
The automatic persistence provided EJB is still immature
The Java Connector Architecture (JCA) is new.
All web service support is new.
For Microsoft.NET, the story is a bit different. Some of .NET is based on Windows DNA, which also runs a variety of mission-critical web sites today and enjoys success. However:
With the new CLR, a good portion of the underlying .NET platform has been substantially rewritten. Indeed, the platform itself is currently only available in a beta version.
C# is new.
All web service support is new.
In conclusion, we must find that J2EE is the more mature platform. It is true that certain new features in J2EE are new and risky. However, the very underlying fabric of .NET, is an overhauled rewrite, and the entire C# language is brand new. This represents enormous risk compared to the new J2EE features. This best thing about .NET is that it removes the dependency on the COM Registry -- .NET will do away with DLL Hell. But the worst thing about .NET is that it tosses out the existing infrastructure. We recommend that the risk averse take a 'wait and see' approach with first-generation software such as this.
Language Support
J2EE promotes Java-centric computing, and as such all components deployed into a J2EE deployment (such as EJB components and servlets) must be written in the Java language. To use J2EE, you must commit to coding at least some of your eBusiness systems using the Java programming language. Other languages can be bridged into a J2EE solution through web services, CORBA, JNI, or the JCA, as previously mentioned. However, these languages cannot be intermixed with Java code. In theory, JVM bytecode is language-neutral, however in practice, this bytecode is only used with Java.
By way of comparison, .NET supports development in any language that Microsoft's tools support due to the new CLR. With the exception of Java, all major languages will be supported. Microsoft has also recently introduced its new C# language which is equivalent (with the exception of portability) to Java and is also available as a programming language within the Visual Studio.NET environment. All languages supported by the CLR are interoperable in that all such languages, once translated to IL, are now effectively a “common” language. A single .NET component can therefore be written in several languages.
The multiple language support that Microsoft has introduced with the CLR is an exciting innovation for businesses. It is clearly a feature advantage that .NET has over J2EE. But is the CLR a business advantage for you? This is a more interesting discussion. We are a bit concerned that the CLR may represent a poor design choice for you if more than one language is used. This is for the following reasons:
Risk. Many existing systems are internally convoluted. Disrupting such existing systems is a risky proposition, since knowledgeable engineers, original source code, and a general understanding of the existing system are often-times unavailable. The old adage, "if it ain't broke, don't fix it" applies here.
Maintainability. We speculate that a combination of languages running in the CLR may lead to a mess of combination spaghetti code that is very difficult to maintain. If you have an application written in multiple languages, then to fully develop, debug, maintain, and understand that application, you will need experts in different languages. The need to maintain code written in several languages equates to an increase in developer training expenditures which contributes further to an increased total cost of ownership.
Knowledge building. With combination language code, your developers are unable to share best practices. While individual productivity may increase, communication breaks down, and team productivity decreases.
Skills transfer. While developers using different languages may have very quickly coded a .NET system using VB.NET and C#, what happens if the new C# developers leave your organization? You have two choices. Train your VB.NET developers to understand and write code with C#, or hire other C# developers who know nothing about your code base. The resulting lack in productivity equates to a reduced time to market and a higher total cost of ownership.
In most cases, we feel that it's much better design to standardize on a single language, and to treat legacy systems as legacy systems and integrate with them by calling them through legacy APIs, which can be achieved using either J2EE or .NET.
We do feel the CLR still adds significant value. The value is that a new eBusiness application can be written in a single language of choice other than Java. This is useful for organizations that are not ready to embrace Java. However, again we must provide words of caution.
It will not be seamless to transition existing developers from their familiar language into productive .NET developers. Procedural languages such as COBOL and VB are being rewritten for .NET to be object-oriented. Teaching developers object-oriented programming is much more of a stepping stone than understanding syntactical rules.
Languages such as COBOL or VB were never intended to be object-oriented. Legacy code will not seamlessly transition into .NET. The resulting code is forever bound to .NET and can never be taken from its .NET home.
We question the general wisdom in reinvesting in outdated technologies, such as COBOL, with new eBusiness or web services initiatives.
In summary, there are pros and cons to both approaches to language support. Use the approach that best suits your business needs, but at least be aware of the consequences of your decision.
