Focus: Web Services
Web Services: Which platform?

Choosing a Web services framework? Here are the key considerations. by Ong Boon Kiat

In the past few months, the IT industry has been collectively licking its chops over IT's next magic bullet, Web services. It heralds true ubiquity in applications that run over the commonest of Web protocols—http and TCP/IP.

But how ubiquitous? Since there are two main variants of Web services "frameworks"—Sun Microsystems' J2EE (Java2 Enterprise Edition) and Microsoft's .Net—does this mean that the Web services camp will eventually be cleaved into two irreconcilable cliques?

"The design point of the basic Web services technologies is to facilitate interoperability, and there is a Web services interoperability organization which is working to assure this," said Justin Martin, Sales Leader, WebSphere Foundation & Tools, IBM Asia-Pacific.

However, as he assessed the looming interoperability issues, Martin concluded that "while it might seem from a development point of view that [choosing between both frameworks] doesn't matter, in fact, it does."

Framing the question
The choice of frameworks matters because program codes can only be shared within a framework, so depending on application complexities, there are likely to be important benefits in standardizing on just one platform. Both J2EE and .Net however, can speak to each other if Web services spawned from both frameworks are packaged in SOAP (Simple Object Access Protocol), although this compatibility is not full.

One important issue to consider when choosing frameworks is the distribution of compilers and runtimes for different operating platforms and terminals.

J2EE runtimes currently exist for multiple OSes but has only one compiler, which is provided for Java. Conversely, .Net compilers are available for multiple languages, like C#, C++ and others, but .Net runtimes only exist on Windows. There are third-party compilers available for each platform, which allow developers to use other languages to write Web services, but the runtime issue still remains.

Given the difference in OS and terminal hardware affinities of both frameworks, device availability and backward compatibility become important considerations. For instance, if you want to use mobile devices, Java runtimes can be readily found in mobile phones and PDAs, but not .Net (although Microsoft is now working on a .Net framework for Windows CE 4.0).

It is this reason that Martin supports J2EE. "If you build Web services using J2EE, you gain a measure of portability between middleware vendors, but with .Net there is only one. Furthermore, there are the administration aspects to consider. With more than one platform to support, the total cost of ownership increases," he said.

He added that since the .Net infrastructure only runs on Windows, companies that need to integrate Unix, Linux, or other applications may have to introduce additional hardware platforms into the solution. "This is likely to be more expensive, particularly when you have to account for systems administration," he said.

Apps matter too
Besides end-point hardware, enterprises building Web services will also have to consider end-point applications. And the types of applications that exist will most likely determine the flavor of Web services that can be applied there.

"It needs to be clearly understood that Web Services are an integration architecture between two end-points, and that each end-point needs to be a Web service," said Martin. "Service-enabling the end-point is probably best done by the vendor of the middleware that the application was originally built upon." For example, a CICS application will probably be best enabled as a Web service using WebSphere (IBM's WebSphere has a J2EE application server which supports the principle Web services standards—UDDI, WSDL, and SOAP).

But that does not imply .Net loses out because Java is more ubiquitous. In fact, some Windows-partisan enterprises will find the benefits in developing on .Net so compelling, they won't care about J2EE. "If you have a predominantly Windows-based IT infrastructure, it makes sense to choose .Net," said Dion Wiggins, research director, Gartner Inc. "From an IT perspective, you don't have to retrain people, and with .Net, there exists better tools that let developers deploy Web services faster."

He also advises enterprises to look first at their internal IT and middleware infrastructure, since Web services are likely to be deployed in intranets first due to security and integration issues, before they are moved further down the supply chain into extranets.

Open or closed?
The choice between .Net and J2EE is also a choice between open and closed computing paradigms, said Stans Kleijnen, VP, Market Development Engineering, Sun Microsystems. "A lot of people don't realize that if they go with .Net, they are locked in [to the Windows platform]. On the other hand, if they go with J2EE, there are multiple players like IBM, Sun, BEA, Oracle and others that they can work with," she said.

But while it is easy to conclude that .Net is proprietary and Java is open, that would be too simplistic. Depending on an enterprise's IT makeup, staying open is less of an issue with some compared to others. Furthermore, even if the Web services applications developed from both frameworks are not identical, they are still likely to co-operate with each other at a high level in the long run.

As for Microsoft being closed, one could also easily argue that there is a sufficiently large and vibrant third-party developer community interested in the Microsoft platform to create applications and runtimes for .Net to eventually broaden its scope considerably.

"Do users of the applications have to be in the same technology and language? If so, then "open" is true only in the technology-specific space, or intra-space. Greater openness is thus exhibited by XML Web services, which is language and platform independent—inter-spaces," argued Edward Chew, .Net/Developer Evangelist, Microsoft Asia.

He said that Microsoft has submitted the underlying specifications of .Net to ECMA, and these have been used by third-parties to build the .Net Common Language Runtime and C# compilers for non-Windows platforms. "In addition, XML Web services are inherently platform and language-agnostic," he said.

Gartner's Wiggins said that .Net is more proprietary (compared to J2EE), but it will change over time because third parties will make it more cross-platform. "These days, Microsoft seems to be working a lot better with standards. Although they still tend to provide standard extensions which can be proprietary, I don't see it as a major issue," he said.

Making choices
Most developers are probably not so much interested in the benefits of each framework, as they are interested in the viability of their finished applications in the context of application deployment and widespread acceptance. The vibrancy and relevancy of third party tools, products and support also matters. So do the level of the programming talent pool available in the market.

In other words, expect both platforms to find support in their respective stronghold markets. "Web services based on .Net and J2EE will command the same market share by 2005, and many companies, especially smaller ones, will not be able to support both platforms," said Wiggins.

As for Web services, more work will be done to make it more secure. Wiggins reckoned that sophisticated Web services security models will show up over the next couple of years. "Today, we have certificates, SSL, encryption and a secure transport, but that's not enough. Web services will demand more granularity in security models, such as anti-data tampering capabilities, which will be needed for banking and finance."