TRENDS

August 20, 2001

There's little argument that XML Web services are the future of computing, which explains why Microsoft is promoting .Net — its XML Web services platform — as heavily as it is.

Related Articles

»A Glimpse of Microsoft's .NET Vision »Is Microsoft Attacking Sun or Protecting Consumers? »Sun Comes Out Slinging With Web Services Strategy

However, .Net is not the only player to offer a platform for Web services. Sun Microsystems will give Microsoft a battle in the Net-native application arena. Support for Web services is a key component of the next version of the Java 2 Platform Enterprise Edition (J2EE), a set of standards for developing enterprise applications using Sun's Java.

J2EE is backed by many heavyweight application server vendors, including IBM, BEA, Hewlett-Packard and Oracle. Sun's Web Services Pack, which contains key technologies to simplify building Web services using the current version of the J2EE platform and XML, will be available for developers soon.

The Wonder of Web Services
Web services enable different applications to communicate with each other, share data and — perhaps, most interestingly — invoke each other using the Internet. The principal way that these disparate applications are intended to communicate is by XML messaging over standard Web protocols including HTTP; almost any platform and language combination can do this.

In theory, standard specifications for Web services building blocks such as XML, SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery, and Integration) provide a common denominator that .Net and J2EE technologies can use to communicate with each other.

A significant difference between Microsoft's .Net platform and the J2EE specification is that J2EE involves many different companies. J2EE is not a product in itself, but is more a set of standards that developers need to adhere to.

The truth is that neither Microsoft's .Net product line nor the J2EE specifications are close to complete yet, although the picture for both platforms is slowly becoming more clear. So with two alternative platforms on which to build Web services, ASPs and software developers are faced with a choice: J2EE or .Net?

A Question of Platform vs. Language Dependence
Perhaps the most important difference between J2EE and .Net is encapsulated by the concept of independence and interoperability of platform versus language. A .Net component can be written in a combination of languages, including the .Net versions of Visual Basic and C, and C#. (Pronounced C sharp, C# is a new object-oriented language, which is a close derivative of C and C++). These developer tools fall under Microsoft's Visual Studio.Net brand.

Source code written in these languages (and, in theory, other languages once suitable compilers are written) is compiled into Microsoft Intermediate Language (known as MSIL or IL). This MSIL code is then just-in-time compiled at run time by the Common Language Runtime (CLR) or is compiled directly into native code. The only target platform now, and for the foreseeable future, is Windows. Code written in other languages can use a shared set of components after being compiled into MSIL (assuming again that such compilers are developed).

J2EE, in contrast, is based on Java and Java only. Java source code is compiled to produce object code, known as bytecode (which is analogous to Microsoft IL code). When the code is ready to run, the Java Virtual Machine interprets this bytecode and executes it at run-time. Or the code can be just-in-time compiled or entirely compiled into native code. In theory, at least, any platform with a Java Virtual Machine (including mainframes, Unix systems and Windows) will be able to run the bytecode.

If platform independence is key, then this makes the choice simple, according to Jay Williams, senior vice president and chief technology officer of Texas-based consultants Concours Group. "If as an ASP you were looking at Microsoft Office subscriptions then clearly looking at .Net will make a lot of sense. If you are looking at doing HR apps or Oracle-based apps then you'd want to be looking at a much more portable platform [like J2EE]," he said.

Development Tools of the Trade
Development tools are a vital part of any platform if it is to be adopted by code warriors, and a large part of Microsoft's Windows platform's success is attributable to the availability of widely adopted development environments such as Visual Studio. It's likely that Microsoft's Visual Studio.Net will make the development of Web services on .Net relatively speedy and painless for developers.

The tools available for J2EE are supplied by a variety of tool vendors including Sun, BEA, IBM, and to some extent they are interoperable. These tools should not be underestimated, but the pool of Visual Studio developers is likely to be far greater than the pool of developers with skills in any of the individual J2EE development toolsets. This is an important factor in .Net's favor, Williams said. "Visual Studio is hugely popular, and Visual Studio.Net will make .Net a significant development platform."

"There's probably general agreement among developers that the Java community has been playing catch-up. The conventional wisdom is it is a little behind .Net, but not as much as Microsoft would want you to think," Summit Strategies analyst Dwight Davis told ASPnews.

Many developers and customers seek a single-vendor solution whenever practical to avoid buck passing. While Microsoft provides a complete single-vendor Web services platform for existing Microsoft shops, anyone with legacy systems from J2EE vendors can create a single-vendor solution by integrating their legacy systems with a Web services platform from that same vendor.

For many developers, one feature will be enough to tip the balance in favor of one of the two platforms. Ian McBeath, CEO of London-based e-business software developer RemoteApps, is committed to the Java platform for reasons of platform independence. "J2EE allows us to use almost any technologies and application servers, so when we go to a client it is easy to sell a Java-based product.

Picking a Winner
A natural fear is that by choosing .Net or J2EE too early you risk "backing the wrong horse" or developing to a standard that is not dominant and is incompatible with the portion of the world using the other standard. But, in reality, it may never come to that, as there is plenty of room for both platforms to co-exist, McBeath said. ".Net has got the power of Microsoft behind it and J2EE has the power of a whole lot of technology providers behind it," he said. "I think it's healthy that there is competition between the two standards, as both will be looking to improve their weaknesses, which must be good for the industry."

Concours Group's Williams said he agrees that the fear of backing the loser is overemphasised. "The key here is Microsoft's support for standards," he told ASPnews. "If it does stick to the standards, then it doesn't matter what the services are delivered in. But if Microsoft makes proprietary extensions (to enable .Net to work with Microsoft Office apps in a particular way, for example) then it could make choices more tricky. In reality, however, you always have to implement nonstandard things to make a specification work, and Microsoft has done this in the past and it has turned out to be a positive rather than a negative thing."

Summit Strategies' Davis points out that same thing is largely true for J2EE, "Developers will develop code for more than one platform, not just J2EE. As developers fine tune their app, it becomes less portable. ISVs will differentiate themselves to complete with other vendors. They'll want to add value; then things can get fragmented."

Ironically, developers may select a Web services platform for far more pragmatic reasons than their relative merits. For example, the skills sets of existing and potential staff are vital, said Eamus Halpin, CEO of U.K.-based ASP and systems integrator iRevolution (formerly iFuel). "Our development effort is based around Visual Basic and C — this is client driven — and we have the skill sets for that. If you have existing Microsoft code and tools, then migrating to .Net is obvious," he told ASPnews. "If we didn't have Microsoft skill sets, it would be reasonable for us to choose [either] J2EE or .Net," he said.

Common Ground in XML
While ISVs and ASPs will likely lean towards either the .Net or J2EE camp, XML is the unifying factor that component architecture isn't. "The two sides have actually grown closer," Davis said. "When the focus was on objects, you had ActiveX and OLE competing with Java Beans. Now developer tools may be different, but they will converge in a way in XML."

Ultimately, it's in everybody's best interest to ensure that Web services work regardless of the platform they were built on, and for them to succeed in the way that many are predicting this will be essential. Fairly or unfairly, many suspect that if anyone decides to ignore Web services standards, it will be Microsoft. But Web services may prove to be too important to be ignored. Concludes Williams: "I think that Microsoft has recognized that with Web services, it can't lock out the rest of the world."

Tools:

Add aspnews.com to your favorites Add aspnews.com to your browser search box IE 7 | Firefox 2.0 | Firefox 1.5.x

Back to Trends