Wednesday, April 20, 2005
Why J2EE Firms Are Considering Microsoft .NET
When you meet with customers who cite portability or the vendor neutrality aspect of Java as an advantage over the Microsoft platform, you can demonstrate that this simply isn’t true in practice.
April 11, 2005
With the impending release of the 2.0 version of the Microsoft .NET Framework , I’ve started receiving some unusual requests from die-hard J2EE companies for briefings on Microsoft’s vision for .NET 2.0, Visual Studio 2005 , and beyond. What makes them unusual is that previously these companies wouldn’t even accept an invitation to lunch to discuss Microsoft development technologies.
Based on my conversations with people from J2EE companies, I conclude that these requests are emerging because many companies have started to discern that Sun’s hopes of establishing "one Java" are not being realized. Originally, Sun promoted the concept that Java would provide the ability to "Write Once Run Anywhere." Then the portability of the J2EE enterprise application platform became the watchword. In an August 2001 article in SD Times, Judith Lilienfeld, a Sun senior product manager at the time, said that "Portability is the cornerstone of J2EE."
The idea was simple and compelling to corporations. Through the Java Community Process (JCP), Sun would specify Java application programming interfaces (APIs). This would allow vendors to build independent but interoperable implementations of those APIs. Vendors could compete on the merits of their implementations. Ostensibly, this would provide vendor independence for users of the technology. For example, you could write an application on Vendor X’s platform, and then, if you wanted to, move your application to Vendor Y’s platform. But the reality is much more complicated. In fact, except for very simple demonstration applications, that kind of portability has never really been achieved.
It’s a little too simple to dismiss the recognition of the failure of the JCP to deliver “one Java” as "Java bashing" by Microsoft.
This Is Not Java Bashing
It’s a little too simple to dismiss the recognition of the failure of the JCP to deliver “one Java” as "Java bashing" by Microsoft. Actually, most of the dissatisfaction with the standardization efforts is coming from the same experts who first promoted J2EE as the future of enterprise development. For example, in an October 2004 analysis and report entitled "J2EE: a Standard in Jeopardy," the Burton Group cited the complexity of implementing J2EE and the length and complexity of the JCP process as key challenges to the continued success of J2EE. And in a December 2004 column in SD Times, Allen Holub, a Java expert and one of its staunchest defenders, questioned the relevance of the JCP, saying, "Just look at created-by-committee junk like EJB (Enterprise JavaBeans Technology) and JSF (JavaServer Faces). I personally believe that EJB has been responsible for the failure of more companies than almost any other single technology. EJB is too expensive at every level."
Vendors Are Taking Matters into Their Own Hands
As customers demand quicker solutions than the JCP can provide, vendors are responding with J2EE implementations with extensions specific to their platform. These implementations help customers in the near term by providing support for deficiencies in the J2EE standard, but ultimately they undermine the portability premise of J2EE. Using a vendor’s extensions creates the vendor lock-in that the JCP was supposed to eliminate. Every major vendor has announced and implemented plans for their own extensions.
IBM’s WebSphere: In the recently released version 6 of the WebSphere Application Server, IBM added several "IBM-only" interfaces, including WorkAreas, Asynchronous Beans, Last Participant transaction optimization, and many others. In Gartner’s October 2004 review of the new version of WebSphere, the title says it all: "IBM WebSphere 6.0 Adds J2EE 1.4, but Users Risk 'Lock-In.'"
BEA: It promotes the WebLogic Workshop Framework, which became Beehive. Although BEA donated their Beehive framework to Apache, it remains to be seen whether users will use Beehive instead of their vendor-specific framework. And BEA still has other “BEA-only” frameworks covering such things as security providers, integration, and portals.
Oracle’s App Dev Framework (ADF): Oracle defines an uber-J2EE implementation. The company takes a different approach, however, by licensing its API layer for use on other application servers. But this is simply a different way to make customers dependent on Oracle. For example, a customer still has to build solutions by using either Oracle + Vendor X or Oracle + Vendor Y.
JBoss: JBoss defines several JBoss-only frameworks and interfaces. These include both an Aspect-Oriented framework and the new JBoss Remoting framework, introduced last month. In recognition of the growing dominance of .NET, Marc Fleury, the CEO of JBoss, LLC, acknowledged in a June 2003 InternetNews article that “We are closer to .NET in philosophy than to the J2EE spec with JBoss 4.0."
Sun Microsystems: Sun admits that J2EE is little more than a specification and will require some level of vendor implementation. More specifically, Sun defends the need for an additional layer in its documentation: "Although J2EE is a solid foundation for an application framework, it is not one itself. The J2EE specification avoids recommendations in the application development space. J2EE leaves architects and developers the significant task of designing (or adopting) an application infrastructure that suits their application development needs. J2EE alone cannot suffice." Of course, Sun’s implementation of this application framework is available only on Sun’s own application server.
The dissatisfaction with the JCP standardization process isn’t just causing vendors to implement vendor-specific implementations of J2EE application servers. It’s causing portability chaos with Web services implementations, management and administration interfaces, and any other area where vendors are being forced to create interim functionality for standards that aren’t completed or for areas that weren’t anticipated. In fact, about the only thing most of the vendors have agreed upon (except Sun) is that Eclipse should be the de facto programming environment. But Eclipse is an incomplete development environment that makes it necessary for enterprises to adopt third-party plug-ins to design Web applications, smart client applications, schema, EJBs, portals, or database logic.
An Enterprise Opportunity
Here’s the bottom line: When you meet with customers who cite portability or the vendor neutrality aspect of Java as an advantage over the Microsoft platform, you can demonstrate that this simply isn’t true in practice. While the JCP continues to bicker over standards, innovation is continuing at the vendor level. As a result, customers will commit to a vendor-specific set of platform technologies or they will pay a huge cost in lost productivity. Once the vendor lock-in issue is addressed, you have an open door to discuss how the Microsoft platform can meet their business needs better than a Java-based platform. The productivity enhancements in Visual Studio 2005 and the Web services standards work in Visual Studio 2005 and Indigo create a compelling argument for a switch to .NET now.
April 11, 2005
With the impending release of the 2.0 version of the Microsoft .NET Framework , I’ve started receiving some unusual requests from die-hard J2EE companies for briefings on Microsoft’s vision for .NET 2.0, Visual Studio 2005 , and beyond. What makes them unusual is that previously these companies wouldn’t even accept an invitation to lunch to discuss Microsoft development technologies.
Based on my conversations with people from J2EE companies, I conclude that these requests are emerging because many companies have started to discern that Sun’s hopes of establishing "one Java" are not being realized. Originally, Sun promoted the concept that Java would provide the ability to "Write Once Run Anywhere." Then the portability of the J2EE enterprise application platform became the watchword. In an August 2001 article in SD Times, Judith Lilienfeld, a Sun senior product manager at the time, said that "Portability is the cornerstone of J2EE."
The idea was simple and compelling to corporations. Through the Java Community Process (JCP), Sun would specify Java application programming interfaces (APIs). This would allow vendors to build independent but interoperable implementations of those APIs. Vendors could compete on the merits of their implementations. Ostensibly, this would provide vendor independence for users of the technology. For example, you could write an application on Vendor X’s platform, and then, if you wanted to, move your application to Vendor Y’s platform. But the reality is much more complicated. In fact, except for very simple demonstration applications, that kind of portability has never really been achieved.
It’s a little too simple to dismiss the recognition of the failure of the JCP to deliver “one Java” as "Java bashing" by Microsoft.
This Is Not Java Bashing
It’s a little too simple to dismiss the recognition of the failure of the JCP to deliver “one Java” as "Java bashing" by Microsoft. Actually, most of the dissatisfaction with the standardization efforts is coming from the same experts who first promoted J2EE as the future of enterprise development. For example, in an October 2004 analysis and report entitled "J2EE: a Standard in Jeopardy," the Burton Group cited the complexity of implementing J2EE and the length and complexity of the JCP process as key challenges to the continued success of J2EE. And in a December 2004 column in SD Times, Allen Holub, a Java expert and one of its staunchest defenders, questioned the relevance of the JCP, saying, "Just look at created-by-committee junk like EJB (Enterprise JavaBeans Technology) and JSF (JavaServer Faces). I personally believe that EJB has been responsible for the failure of more companies than almost any other single technology. EJB is too expensive at every level."
Vendors Are Taking Matters into Their Own Hands
As customers demand quicker solutions than the JCP can provide, vendors are responding with J2EE implementations with extensions specific to their platform. These implementations help customers in the near term by providing support for deficiencies in the J2EE standard, but ultimately they undermine the portability premise of J2EE. Using a vendor’s extensions creates the vendor lock-in that the JCP was supposed to eliminate. Every major vendor has announced and implemented plans for their own extensions.
IBM’s WebSphere: In the recently released version 6 of the WebSphere Application Server, IBM added several "IBM-only" interfaces, including WorkAreas, Asynchronous Beans, Last Participant transaction optimization, and many others. In Gartner’s October 2004 review of the new version of WebSphere, the title says it all: "IBM WebSphere 6.0 Adds J2EE 1.4, but Users Risk 'Lock-In.'"
BEA: It promotes the WebLogic Workshop Framework, which became Beehive. Although BEA donated their Beehive framework to Apache, it remains to be seen whether users will use Beehive instead of their vendor-specific framework. And BEA still has other “BEA-only” frameworks covering such things as security providers, integration, and portals.
Oracle’s App Dev Framework (ADF): Oracle defines an uber-J2EE implementation. The company takes a different approach, however, by licensing its API layer for use on other application servers. But this is simply a different way to make customers dependent on Oracle. For example, a customer still has to build solutions by using either Oracle + Vendor X or Oracle + Vendor Y.
JBoss: JBoss defines several JBoss-only frameworks and interfaces. These include both an Aspect-Oriented framework and the new JBoss Remoting framework, introduced last month. In recognition of the growing dominance of .NET, Marc Fleury, the CEO of JBoss, LLC, acknowledged in a June 2003 InternetNews article that “We are closer to .NET in philosophy than to the J2EE spec with JBoss 4.0."
Sun Microsystems: Sun admits that J2EE is little more than a specification and will require some level of vendor implementation. More specifically, Sun defends the need for an additional layer in its documentation: "Although J2EE is a solid foundation for an application framework, it is not one itself. The J2EE specification avoids recommendations in the application development space. J2EE leaves architects and developers the significant task of designing (or adopting) an application infrastructure that suits their application development needs. J2EE alone cannot suffice." Of course, Sun’s implementation of this application framework is available only on Sun’s own application server.
The dissatisfaction with the JCP standardization process isn’t just causing vendors to implement vendor-specific implementations of J2EE application servers. It’s causing portability chaos with Web services implementations, management and administration interfaces, and any other area where vendors are being forced to create interim functionality for standards that aren’t completed or for areas that weren’t anticipated. In fact, about the only thing most of the vendors have agreed upon (except Sun) is that Eclipse should be the de facto programming environment. But Eclipse is an incomplete development environment that makes it necessary for enterprises to adopt third-party plug-ins to design Web applications, smart client applications, schema, EJBs, portals, or database logic.
An Enterprise Opportunity
Here’s the bottom line: When you meet with customers who cite portability or the vendor neutrality aspect of Java as an advantage over the Microsoft platform, you can demonstrate that this simply isn’t true in practice. While the JCP continues to bicker over standards, innovation is continuing at the vendor level. As a result, customers will commit to a vendor-specific set of platform technologies or they will pay a huge cost in lost productivity. Once the vendor lock-in issue is addressed, you have an open door to discuss how the Microsoft platform can meet their business needs better than a Java-based platform. The productivity enhancements in Visual Studio 2005 and the Web services standards work in Visual Studio 2005 and Indigo create a compelling argument for a switch to .NET now.
Comments:
Post a Comment
