a Web services framework? Here are the key considerations.
by Ong Boon Kiat
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 protocolshttp 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 .Netdoes
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."
layers of Web services
Like any network application, a Web services application
is put together like a club sandwich--stacked
in layers. There are five layers, each with one
or more dominant protocols.
The first is the discovery layer, provided by
UDDI (Universal Discovery, Description and Integration),
which is an XML-based registry of Web services.
This is followed by the service layer, which comprises
Web services and WDSL. Lower down is the information
or data layer, provided by XML. And following
that is the packaging layer, provided by SOAP.
Finally, all are underpinned by a Web protocol
layer, which comprises http/https, SMTP and ftp.
It is this foundational protocol layer that creates
the connections between devices and services in
a "request-response" manner.
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
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 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
"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 standardsUDDI, 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
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 independentinter-spaces,"
argued Edward Chew, .Net/Developer Evangelist, Microsoft
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.
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,"
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."