Java Development News:

Web Services: A Business Perspective on Platform Choice

By Ben van Eyle

01 Aug 2001 | TheServerSide.com

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

  1. "Web Services - The Web's next revolution", Doug Tidwell,
    http://ww6.software.ibm.com/developerworks/education/wsbasics/wsbasics-1-1.html

  2. "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/

  3. "XML Schema", W3C Recommendation, "http://www.w3.org/XML/Schema"

  4. http://www.uddi.org/

  5. "Web Services Description Language (WSDL) 1.1", W3C Note, http://www.w3.org/TR/wsdl

  6. "Simple Object Access Protocol (SOAP) 1.1, W3C Note", http://www.w3.org/TR/SOAP/

  7. "J2EE vs. Microsoft.NET", Chad Vawter & Ed Roman, June 2001, /resources.pdf/J2EE-vs-DotNET.pdf

  8. "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

Related Content

Related Resources