|
|
 |
Web Services - A Business Perspective on Platform Choice
By Ben van Eyle
August 2001
Introduction
This paper examines "Web Services", the latest offering in the internet
and information technology arena. It outlines what Web Services are,
investigates offerings that exist currently (or will do shortly),
outlines what this means for enterprises, and provides a strategic
recommendation for adoption and implementation. In particular, it
seeks to show the effective differences and potential benefits and
disadvantages between the Microsoft .NET architecture and the Java Platform.
The term 'Java Platform' is used to encompass the Java Runtime Environment
(JRE), the Java 2 Enterprise Environment (J2EE), and the host of APIs
available which provide a large range of functionality and connect
ability within these environments.
A number of papers by other analysts have already been written on this
emerging dichotomy between the .NET architecture and the J2EE extended
architecture for Web Services. However, all of the current reports fail
to clearly identify the business impact of the choice, as they only
consider what technology a business currently uses and fail to focus
on either a progressive implementation plan or the underlying
philosophies of the proponents.
Web Services
Definition
Web Services are a new breed of Web application. They are
self-contained, self-describing, modular applications that can be
published, located, and invoked across the Web. Web Services perform
the functions that can be anything from simple requests to complicated
business processes. Once a Web service is deployed, other applications
(and other Web Services) can discover and invoke the deployed service.1
History
The first company to publish the idea of such services was
Hewlett-Packard (HP). They developed the specification for e-speak,
proposing it was the next generation of internet information exchange.
Microsoft, realising the promising nature of this proposal, released
its .NET strategy and IBM soon followed with its Web Services Toolkit
(WSTK) and then the Web Services Development Environment (WSDE).
At the same time, Oracle announced and developed its Dynamic Services
which were integrated into Oracle 8i Release2. Oracle's initial
deployment of its framework didn't appear to be following the
standards approach (not that any standards were in existence
at that time); but now, they are committed to follow all
appropriate standards as they emerge. Sun has recently
announced its framework for Web Services. Sun is tying its
Web Services initiative into the J2EE environment and will be
ready in the first half of next year. Included in Sun's offering
is a set of Tools to aid rapid development of both client and
server side functions.
Structure
So what comprises a Web service? (There are a number of new acronyms to
learn and add to those one already has to juggle). In the diagram
below, it can be seen that a Web service is an application which
utilises a number of protocol stacks, specifically, the Wire Stack,
the Description Stack, and the Discovery Stack.
Fig 1: Overview of the Web Services Architecture Stack2
This diagram was taken from the discussion of the W3C Web Services
Workshop (April 2001), which has very strong representation from IBM
and Microsoft. As can be seen from this diagram, the Wire Stack is the
least defined of the three protocols. Also, at the time of writing
(June 2001), only one of the underlying "standards" used in
Web Services have actually made it to W3C recommendation, that
being XML Schema (which defines the content, structure and semantics
of XML documents3)). This at least is useful as XML is a great
technology for moving structured data across the web.1
The important emerging standards are UDDI (Universal Discovery
Description Integration)4, WSDL (Web Services Description
Language)5
and SOAP (Simple Object Access Protocol).6 UDDI defines the method for discovering
a Web service and WSDL describes the service to be discovered and how to access the
service once it has been discovered. SOAP and XML are the underlying methods used
to access the UDDI registry and communicate with the Web Services. There was some
doubt about whether SOAP would ever make it to recommendation in the future as ebXML
(a business to business XML protocol) was well advanced and had requirements which
where not catered for by SOAP. However, the recent SOAP with attachments
specification (submitted by HP) satisfies the requirements of ebXML and
suitably builds on the existing work already carried out on SOAP. Still, the
W3C are working on XMLP which is using SOAP as its starting point; hence it
is likely that SOAP will not become the standard for XML messaging and RPC in the future.
Still, since these standards are far from complete, don't expect to see the solidarity in the
Web Services offerings for at least the next year, eventhough both IBM and Microsoft have each
launched their UDDI registries late last month. IBM is leading the race at present, having the
WSTK and WSDE available to enable a simpler method of creating and integrating Web Services.
According to IBM, their WebShpere Application Server will be incorporating these functions
within the next month. Microsoft has launched the beta versions of their toolset but is not
expecting their completion until later this year.
By this time, one can expect to see near equivalent offerings from Oracle, HP, Sun and BEA.
Offerings
What are the similarities of offerings?
The best part of this new regime is that communication is going to be built on standards, and
those which play the most important role are UDDI, WSDL, SOAP, and XML Schema. Specific XML
files define all the definitions and configuration for each of the protocols. Hence, a sound
knowledge of XML is required. Nonetheless, due to each of the companies being willing to
follow and implement standards as they emerge, it will be possible for all the various
flavours on offer to communicate with each other.
What are the differences?
The differences lie in the underlying "machinery" for performing the application logic and
data manipulation.
All except for Microsoft use the Java product suite as well as their own custom developed
extensions (something for which Java was specifically designed - that is a solid framework
which may be suitably extended to meet application requirements without altering the structure
or reliability of the framework). The Java product suite, having grown over the past five years,
is now very large and incorporates environments from small devices (including smart cards and
mobile phones), desktop computers, servers, and enterprise level environments in many areas of
business including telecommunications and multimedia. Though the Java specifications are
managed by Sun, the actual input and changes are carried out via the Java Community Process
(JCP), which adds the value of open source development in a much more structured and managed
process (incidentally the source code of the JDK and J2EE are available for anyone to download).
The JCP has just been extended and modified to allow even more participation than before and
is now hosted at http://www.jcp.org/.
.NET, of course, is solely a Microsoft architecture. While it is not impossible for other
companies to implement the .NET architecture or at least parts of it, all of the other big
players are already committed to Java. Probably one of the main reasons for this is that
previously, the Microsoft component architecture was highly integrated with the Windows
operating system. Although the .NET framework specification, and more specifically the
CLR (Common Language Runtime), improves the possibility of running on other operating
systems, there is still far too strong a binding with the Windows architecture to allow
easy porting. Microsoft has no form of community process or open source initiative.
They have recently announced access to source code for their larger beta test companies,
but have also clearly damned open source as being a noose around the neck of innovation.
From my perspective, open source does not hinder innovation, but it places a different
slant on profitability. IBM now supports Linux along with Java on all of its platforms,
and the Apache Web Server as part of WebSphere. This has actually improved IBM's
software business and aided in the more rapid development of innovative products.
What does this mean for Business in the future?
Clearly, a system of available, dynamically searchable services, which provide all manner of
information and interaction from a variety of connectable devices, will change the face of
business, communication, and the work and lifestyle of a large proportion of the
information world. At least this is what the larger internet and telecom companies
are hoping, as sales of this type of infrastructure and services will certainly help
to move the companies out of the current economic downturn. However, while there
can be advantages to this form of communication, it is clear that the service
companies stand to gain, although I consider that the telecommunications
providers will likely gain the most.
So what does business stand to gain? Well, those businesses which partake of this framework will
have greater and more instant access to customers, consumers, and vendors, which literally span the
entire globe. That is, of course, only for those businesses which have suitable products to take
advantage of this type of medium. Booking agencies for travel, dining, theatres, cabs, etc.
immediately benefit, as do those which have already managed success in the current internet
market space.
The ability to centralise information in a globally accessible manner is definitely a plus for
the company intranet. This has been one of the major problems in organizations, which have
several divisions and even more applications. For example, the contact details of a customer
or even an employee have traditionally been bound to one application and then either copied to
another application via cut and paste, or via sophisticated integration programs, or completely
re-entered altogether. The Web Services approach allows this information to be
stored and universally retrieved by any application which requires the information, in a
common and defined manner, independent of platform and programming environment.
This characteristic, more than any other, is what makes Web Services the hallmark of
the next generation of the information age.
What does it mean for Business now?
First, there is no need to rush (as all the offerings, even when they arrive, will still be based
on uncompleted standards), but there is a need to plan now, in order to be well positioned to make
effective use of the technology when it arrives and also to improve the quality of current
software development. It also brings business to one of the most difficult decisions it will
have to make in the next several years, and that is, which technology or platform it will use.
This diversion of middleware technologies and architectures (.NET or Java Platform) is causing an
even larger polarisation of the information technology arena than the original OS wars between
Windows and UNIX. Both architectures are theoretically sound but, are you prepared to bet your
business on one or the other.
Choices
The choice of platform for the future must be based on sound business reasoning, and not personal
preference or even technical excellence. Many articles written on the subject are biased and
worse than this, many readers only see what they want to see, having made up their minds
irrespective of what information is presented. Still, the Web Services approach is a good
move for enterprise and customer alike and, like it not, it will involve significant change
on the part of application developers, providers and IT organizations.
The rest of this paper highlights some of the differences and similarities of the two
architectures and specifically focuses on the business decisions, which must be realised.
Language
.NET touts language independence, which is indeed a remarkable feature. However, it is well
known that by far the largest expense in any IT project lifecycle is the ongoing maintenance
(up to 80%) which occurs through ever-changing (and hopefully improving) business practices.
Hence, common sense dictates that a single language should be used in any business or enterprise
in order to ensure maintainability. The likely choice then would be VB.NET for most
organizations currently using the Microsoft platform, as there are by far more VB
programmers available than C++ programmers. However, VB.NET is a quantum leap from VB6.
VB.NET is fully object-oriented, allowing all the features of the CLR to be achieved.
Roger Sessions also concludes, backing his argument with Gartner studies, that
retraining programmers to Object Oriented technology is expensive and VB6 to VB.NET
involves that very same retraining.8
So business must forgo a cost to retrain programmers to either VB.NET (or C#) or Java. In the USA
78% of universities teach Java and 50% of universities require Java. Most Australian universities
teach Java and the University of Canberra has many years of expertise in Java. Hence, since
retraining must be performed regardless, it is a fact that recognised professional facilities
already exist for programmers to learn Java. Since the facilities already exist outside the
business organization, in educational institutions, the cost of retraining to Java will be
considerably lower than any other alternative object-oriented language. It will likely take
years for VB.NET or C# to achieve a similar status in universities, if it ever happens at all.
Equally, it is a very small step for a Java programmer to utilise C# or VB.NET should such a
migration ever be required.
Web Services involve the use of enterprise level backend architectures. For a business or
enterprise to build and maintain such architectures requires skilled middleware developers and
system architects. Such skill is rarely found in VB programmers who traditionally have not
had to deal with the complexities of concurrent programming and fault tolerant architectures.
These skills are usually only found in a few experienced C++ and Java experts who by nature
are already middleware developers. It would be unwise to believe that traditional VB programmers
are up to the task of architecting and developing robust, scalable Web Services simply by adopting
an improved programming language and platform.
Migration to a new Platform
Organizations which currently operate on a Microsoft platform will be forced to change existing
applications. .NET brings with it the Common Type System in which existing data types used by VB
have been dismissed and currently there is no migration tool.7 Existing VB applications must
therefore be rewritten. Even COM+ objects must be rewritten to take advantage of the managed
code environment or other special action must be taken to interface with these unmanaged code
components within the .NET platform.
Those already using the Java Platform will have no difficulty migrating to Web Services. Existing
applications will continue to operate untouched. The addition of some new APIs (for managing XML,
SOAP and ebXML) and strategically placed components will turn even existing applications into Web
Services.
Migrating from one platform to the other is, needless to say, the largest exercise. Bearing in
mind, however, what has already been said about language retraining, it will most likely be
easier to migrate from Microsoft to the Java Platform due to the availability of professional
Java training.
Maturity of Platform
Both platforms are quite mature and are already running large-scale enterprise applications.
Web Services are new to both platforms. This however is where the similarities end.
.NET is an entirely new underlying code base involving a new Object framework and runtime
environment (CLR). The Java Platform does not actually require any change to incorporate
Web Services now. However, changes are being made to improve the functionality and time
to deployment of Web service functionality. Included in the upcoming changes is the new
J2EE 2.0 specification which has enhanced the container managed persistence of Objects
(one of the arguments used against J2EE due to perceived caching anomalies between the
container and the database). Roger Sessions incorrectly states that .NET has a 3 year
head start over the Java Platform as .NET is not built on the existing Microsoft platform
but is in fact a complete rewrite utilising the CLR. Even ADO.NET is different from the
current OLEDB approach.
Device independence is one of the favourable features of the .NET approach, which uses
server-based controls to dynamically create code for the specific device. The Java platform
already has APIs, which are used by industry for Smart Cards, Phones, PDAs, TV, and a host of
Telecommunications products. Nokia recently announced it will be incorporating Java into
its phone technology to support the mobile internet functionality. Java has been available
on Palm handheld devices since 1999.
Past experience has shown that being totally reliant on the Microsoft approach can be very
costly. Large developments in VB have been fraught with problems, both due to the architecture
of the language and the underlying implementation produced by Microsoft, which have had
significant memory problems. Microsoft Data Access Components (MDAC) has also been a
troublesome technology, which apart from also having memory problems, denied backward
compatibility with existing systems. Since this technology was so tied to the operating
system, it was not possible to utilise version-based installations. With Java however, it
is possible to run multiple versions of the JRE on the same machine, allowing progressive
migration from existing applications to more recent developments. Apart from this, the
Java Platform has maintained a consistent approach to enabling backward compatibility.
The Java class hierarchy has been very stable and most of the classes available in
Version 1.0 are still available. Where there have been changes, these classes or
methods have been marked as deprecated, but still available, allowing time for
applications to be progressively migrated to the improved approaches.
Portability
This has been described as a problem for those in the J2EE camp. However, while different
vendors have varying implementations of propriety extensions, should a business decide to move
from one vendor implementation to another, it is unlikely to involve more that 20% of the code
base. Adoption of the Microsoft .NET technology allows absolutely no room to move. Hence, a
business is less likely to be locked into a single vendor by adopting the Java Platform.
Disconnected Applications
For the next several years, due to the limitations of the worldwide communications infrastructure
and cost, it is unreasonable to think that Web Services will be the panacea of application
development. Mobile computing is certainly on the increase, but applications must be able
to be operated as stand-alones, and synchronise information as required, when a connection is
made. .NET provides WinForms and MobileForms (a new technology) for this purpose, but is
once again limited to the Windows platform. The Java Platform has a range of application
capabilities, which span from Smart Cards and hand-held devices and phones to desktops,
already in operation. Recently, Sun has released Java Web-Start, a toolkit which enables
applications to perform automatic update and installation when connections are made,
greatly simplifying the job of version maintenance and upgrade faced by many organizations.
Business delimiters
It has been said in the past that "no one ever got fired for recommending Microsoft."
However, this may well be the time to re-evaluate that sentiment. The economy is tight
, particularly in the IT arena. Hence, it is important that the standard business
approaches be applied to making the forthcoming decisions, those being overall cost
(lifecycle cost), risk management (reduction of risk), and return on investment
(the bottom line). The cost of operating systems and hardware is outside the scope of
this paper. Windows is traditionally a low cost operating system, but Linux offers
equivalent performance for even lower cost with many major hardware vendors (including
IBM, Compaq, HP and SGI) offering Linux as a supported operating system on their hardware.
Cost
This is invariably the most important factor to any organization. It is easy for an organization
to say that since we already have X technology we will stick with that as it is likely to be the
lowest cost and easiest to manage. As was mentioned above, if an organization is not currently
using the Java Platform, then retraining and recoding is already an issue. It will likely be a
lower cost option (due to university support) to retrain programmers to the Java Platform than
to the .NET Platform (which has no formal support). .NET will be available to all current
Microsoft Select customers and MSDN Universal licensees (which is already a significant cost)
but nonetheless each developer seat must still be paid for. Microsoft has not yet released the
licensing costs involved with .NET. Equally, a development environment such as Borland's
Jbuilder, WebGain's Visual Cafe, IBMs Visual Age or Sun's Forte for Java will need to be
purchased for timely Java enterprise development.
The Java Runtime Environment is free on all operating systems. The Tomcat servlet/Java Server
Pages (JSP) engine is also free on all platforms. So enabling an environment to take part in
the Java platform is not a problem. Purchasing a J2EE container is a different problem which
comes with a significant cost unless the organization utilises JBoss (a free J2EE container
which has recently been used by production sites replacing BEA WebLogic server).
Still, the lifecycle cost of applications far outweighs the initial purchase price of the software
environments (if it didn't why would anyone purchase Vignette?). Unless organizations mandate a
single Language, lifecycle costs will undoubtedly be far higher than any other platform costs.
With the Java Platform, language is not a choice. With the .NET Platform it would probably be
a better choice to adopt C#, as this is the only language which has access to all the power of
the environment and connect ability features to interact with legacy systems.
Risk
Risk minimisation is imperative in establishing or maintaining a strong business and client or
customer satisfaction. The Java Platform is not just Sun but is an industry standard, supported
by the all the largest software vendors (with the exception of Microsoft and even they still
support their own Java Virtual Machine (JVM) and Development Tool (VJ++); though probably not
for much longer). .NET is not a standard but purely a proprietary framework. Whilst Microsoft
is large enough to be here for the long run its expertise has really been in the operating
system and desktop office applications environment. While it has operating installations of
Commerce Server, IIS and BizTalk the percentage market share pales in comparison to it's
installed based of Server and Desktop Operating Systems.
Microsoft architecture is good. Microsoft implementation is where the problem lies. They are
quick to market the new technologies but stability does not enter the offering until
the fourth or fifth release of the product. It is just as likely to happen this time with .NET.
As I have already said, it is a small investment to move from the current Java Platform to one
which supports Web Services, hence the existing stability virtually guarantees lower risk.
Last year I questioned Microsoft presenters at a seminar on Enterprise Java Beans
(EJB) vs. COM+. I asked why the very large majority of Fortune 500 companies chose the
Java Platform and Oracle database over the Microsoft offerings. The presenters were unable
to answer the question. Also, Microsoft released its MFC (Microsoft Foundation Classes) for
C++ five times. Each MFC was so significantly different from the previous one that applications
had to be continually rewritten just to work. Microsoft Transaction Server was potentially a
quantum leap in technology when it was announced, but it has taken until the most recent
editions of COM+ for it to work, and now they are abandoning the architecture for a new one.
In a complex venture such as .NET, it would be foolish to assume that any organization could
build a stable platform without at least several iterations. In such a case, are
businesses willing once again to wait for Microsoft to get it right?
Return on Investment (ROI)
Far too often, organizations have adopted a product offering simply because it is backed by a
large company or it is the latest and greatest, or it has an apparently large market share.
With continuing difficult economic times (especially in the IT industry), there needs to be a
much greater focus on ROI than in the past. There is no value to choosing the Rolls Royce or
BMW when a Ford will do the job just as reliably.
Both the previous points of lifecycle cost and risk greatly impact the ROI. Microsoft is
traditionally touted as being the lower cost option when it comes to enterprise offerings,
but this is no longer the case when far more organizations choose databases like Oracle to
safeguard their data, and the amount of hardware required to run Windows operating systems
ends up costing more than some Mainframes.
Any development performed now on the current Windows platform must be seen to become a legacy
system when .NET becomes available, and will either require specialist interfacing or complete
rewriting in the future. This is definitely a poor ROI unless the organization can be sure
that the application's useful life will be exceeded shortly after the move to Web service
technology.
Investment in current Java technology will lay a sound foundation for the future Web service
offerings. Applications written using the Java Platform do not need to be rewritten, but simply
require the addition of extension APIs when they become available (some are already available,
but since the standards are not yet mature, only experimental or preparatory work should use
these APIs), to implement both current and future applications into the Web Services arena.
Clearly the Java Platform offers a better ROI. As training can be performed immediately by
recognised institutions, applications can be developed and utilised immediately and all the
skill and knowledge gained will continue to be utilised even beyond the transition to Web
Services. Java already has offerings on a multitude of devices and can perform in either
a connected of disconnected manner.
Organizations which have Oracle Enterprise already installed must seriously question whether
they should not make full use of the investment they already have. Oracle Enterprise already
contains a full EJB container and XML services. Oracle's container may not currently be voted
as one of the best but Oracle is moving to improve this situation. Nonetheless, since the
investment already exists, shouldn't an organization take full advantage of the situation?
Oracle has its own "Dynamic Services" initiative, which is destined to comply with all the
standards along with all the Web Services offerings from other organizations.
Conclusion
This new Frontier is an exciting time in the information technology industry. Business must
make sound decisions based on Cost, Risk, and Return on Investment. The adoption of a preferred
platform should not be influenced by what an organization currently has or what the
preferred desktop environment is.
For those organizations currently on a Windows platform, retraining is inevitable and must be
planned and budgeted for now. The lowest overall cost and risk will likely be achieved by
adopting the Java Platform for Business and Enterprise applications, which may or may not
include Web Services. This will undoubtedly be a difficult and even brave move for the
management of some organizations, but nonetheless should not be passed by without clearly
understanding the impact of any decision made.
 
...Software to graft into your
business
and make it grow...
Scion Systems is a small development company dedicated to
the production of enterprise scalable, industrial strength and commercial quality
software applications and components.
We offer the following products and services:
- Enterprise Architectural consulting
- Strategic Business Technology consulting
- Software development consulting
- SSIM Route (customized connector to integrate systems -
currently supports integration with SAP R/3)
- SSIM Mail (SMTP/POP3 Mail Engine)
- SSIM Form (Business Form environment)
For further information about our products and services please visit our web site at
http://www.scionsys.com
|
References
- "Web Services - The Web's next revolution", Doug Tidwell,
http://ww6.software.ibm.com/developerworks/education/wsbasics/wsbasics-1-1.html
- "The Web services insider Part 2: A Summary of the W3C Web Services Workshop", James Snell,
http://www-106.ibm.com/developerworks/webservices/library/ws-ref2/
- "XML Schema", W3C Recommendation, "http://www.w3.org/XML/Schema"
- http://www.uddi.org/
- "Web Services Description Language (WSDL) 1.1", W3C Note,
http://www.w3.org/TR/wsdl
- "Simple Object Access Protocol (SOAP) 1.1, W3C Note",
http://www.w3.org/TR/SOAP/
- "J2EE vs. Microsoft.NET", Chad Vawter & Ed Roman, June 2001,
/resources.pdf/J2EE-vs-DotNET.pdf
- "The Java 2 Enterprise Edition (J2EE) versus The .NET Platform, Two Visions for eBusiness",
Roger Sessions, March 28, 2001,
http://www.objectwatch.com/FinalJ2EeandDotNet.doc
PRINTER FRIENDLY VERSION
|
