Chapter 3: Microsoft s Web Services

A battle is only great or small according to its results.

”Mark Twain

Overview

Microsoft s Web services initiative, as embodied within its .NET program, is incisive, pervasive, and aggressive . This is to be expected. It is also remarkably realistic and pragmatic, which may come as a surprise to some, but let s face it ”Microsoft, as the idiom goes, put skin in the game. Actually, Microsoft, the world s most successful software company has a lot of skin in this game. Microsoft, one of the founding fathers of Web services, along with IBM, knows exactly what is at stake here. Ironically, this very alliance with IBM accentuates to Microsoft s senior management on a daily basis the dangers of what can happen if you do not pay adequate attention to a potentially important software technology.

Twenty years ago, IBM and Microsoft also collaborated, not as the peers that they are today but very much on a David and Goliath basis, on desktop software for the then-nascent PCs, in particular the OS/2 operating system. IBM, sated by continuing success in the mainframe and mid-range sectors, was somewhat lackadaisical in rallying its considerable resources to decisively exploit this emerging market in a timely manner. IBM took its eyes off the ball. Microsoft stalked it like a hawk. The rest is history.

IBM is still paying the price for this miscalculation and hoping that the new Web services “oriented software model, coupled with the growing acceptance of Linux, might give it a chance to redress the balance when it comes to PC software. Microsoft, innately more street-smart than most, and certainly more so than IBM, knows that. It does not intend to slip up and give IBM, or anybody else for that matter, an unexpected opening. Rather than let Web services weaken its desktop franchise in any way, Microsoft is committed to making sure that Web services fall within its franchise.

Microsoft coauthored the SOAP, WSDL, and UDDI specifications in 2000 (as shown in Table 1.1). By April 2001 it had one of the first widely used implementations of SOAP ”namely, the Microsoft SOAP Toolkit 2.0. It is now one of the four companies responsible for maintaining the global UDDI Business Registry, as discussed in Section 1.1.2; the other three companies are IBM, NTT Communication Corporation, and SAP. It is still extremely active, one could even say proactive, in the Web services standards front (as shown in Table 1.1), and has had a hand in creating many of the key auxiliary standards, including business process representation (BPEL4WS), Web services discovery (i.e., WS-Inspection), messaging, XML key management (XKMS), security (e.g., WS-Security, WS-Trust, and so forth), and transaction processing (WS-Coordination). The bottom line here is that it is fair and safe to say that Microsoft really does know what Web services are all about and furthermore is making sure that rather than just having a finger on the pulse, it has a stethoscope on the heart.

Given this level of familiarity and involvement from day one, it is not surprising that Microsoft s characterization of Web services is perspicacious and snappy (Figure 3.1). Two of the high-level definitions favored by Microsoft are as follows :

• Web services protocols enable computers to work together by exchanging messages. Web services are based on the standard protocols of XML, SOAP, and WSDL, which allow them to interoperate across platforms and programming languages.

• Web services are small, reusable applications written in XML, a universal language for data exchange. They allow data to be communicated across the Internet (or internal intranet) between otherwise unconnected sources that are enabled to host or act on them.

Figure 3.1: One of Microsoft s perspicacious depictions of Web services (see Web services model introduced in Figure 1.2).

Despite what its many distracters may ardently hope, there is no question that Microsoft is destined, even preordained, to play a pivotal role when it comes to Web services. This is a given. To look at this in another way, one can even say, without any fear of contradiction, that Web services cannot really take off without the help of Microsoft offerings, whether it be Windows, Microsoft s ubiquitous Internet Information Services (IIS) Web server, Microsoft BizTalk Server 2000, or any of Microsoft s Visual application development suites (e.g., Visual BASIC, Visual C++, or Visual Studio).

The reality here is that given Microsoft s current control of basic corporate IT infrastructure, especially at the desktop and the Web interface, it is inconceivable to see how Web services can truly flourish without in some way impinging upon Microsoft technology. Furthermore, Microsoft s development tools are widely used and highly popular within the application development community. Consequently, many Web services will be developed using Microsoft tools and deployed on Windows NT, Windows 2000, or Windows 2003. That is ineluctable.

Web services, particularly in the case of Microsoft and IBM (and to a smaller degree in the case of IBM and BEA), have added a whole new twist to the co-opetition (i.e., cooperating with your competition) concept favored by Novell s founder, Ray Noorda. When it comes to Web services “ related standards and the task of maintaining the global UDDI Business Registry, Microsoft and IBM appear to work hand in glove and advocate the same values. There has been more productive collaboration between these two companies on the Web services front than between any other two companies. Together they account for at least 60% of the standards- related work done to facilitate Web services.

However, the cooperation and chumminess end abruptly when it comes to marketing Web services “related solutions. IBM is all Java and Microsoft is all decaf. The gulf could not be any wider or more fundamental. Rather than getting better over time, this dispute continues to escalate and get more acrimonious. Microsoft s decision not to include an industry standard “compliant Java Virtual Machine (JVM) that was acceptable to Java s creator Sun Microsystems within the Windows XP operating system precipitated the latest showdown ”which yet again included lawsuits and injunctions .

A JVM is also not installed as part of a typical Internet Explorer 6.0 (or greater) installation, though one is automatically downloaded and installed on the fly when a user encounters a Web page that relies on Java Applets. The upshot of all of this is that Microsoft, as of February 2003, is claiming that it will not include any sort of JVM in any Microsoft products as of January 2004 ”and moreover will stop distributing its Java-oriented Visual J++ product as well. Those who want a JVM with Microsoft products, including the newer Windows platforms, will have to get JVM from a third party. In reality this is not a big deal, since free and highly automated downloads for all major releases of Windows are available from the http://www.java.com Web site.

At this juncture, to avoid any future confusion or misunderstandings, it is important to point out that Microsoft does have a relatively widely used Java-based software development suite known as Visual J++ (Figures 3.2 and 3.3) and that the latest version of this software development package, known as Visual J#, is integrated into Microsoft s Visual Studio .NET. The pivotal issue here, however, is that Microsoft s Java is not platform independent!

Figure 3.2: The product packaging of Microsoft s Visual J++ Release 6.0 offering.

Figure 3.3: An example from Microsoft of the highly visual, integrated development environment available with the Java-based Visual J++ software development tool.

Software developed using Microsoft s Visual J++ or J#, as is also the case with most other Microsoft software development tools, will only run on the Windows platform. That is the rub. This issue is so germane to the discussion here that it is worth repeating what Microsoft has to say about this: Visual J# .NET 2003 is not a tool for developing applications intended to run on a Java virtual machine. Applications and services built with Visual J# .NET 2003 will run only in the .NET Framework; they will not run on any Java virtual machine. Visual J# .NET 2003 has been developed independently by Microsoft. It is neither endorsed nor approved by Sun Microsystems, Inc. This terse set of statements tells it all and confirms that there is indeed a basic difference of opinion and sentiment between Microsoft and the Java camp. As of 2004, this split could reach the point of being irreconcilable.

IBM likes to claim that its WebSphere family is the best route by far for implementing Web services “related solutions. Microsoft disagrees vehemently. As far as Microsoft is concerned , its .NET initiative is a much more practical and cost-effective approach than anything IBM can offer. Both camps have ardent, dyed-in-the-wool supporters, in roughly equal quantities . Many of these are active, knowledgeable practitioners who make a good living developing software. They can cogently argue as to why they opted to use one scheme rather than the other. They cite practice as opposed to theory.

Both sides, given their ample war chests, also have mercenaries in the form of consultants and analysts. These, though typically more articulate and prolific with the written word than the software practitioners, tend to disseminate what is essentially party propaganda. Media journalists for their part, though hoping to elucidate, tend to vacillate between the camps depending on who they last spoke to at length. Acrimony, on the whole, is such that both camps even go to the trouble of writing white papers or commissioning others to write white papers that are no more than just rebuttals of each other s methodologies vis--vis Web service development and deployment. In these documents, each side agrees, albeit grudgingly, that the other s technology works. What they bicker about incessantly is what approach is easier to use, the significance of platform independence, and the overall cost of one approach over the other.

In reality, much of this my approach is faster than yours or my approach will save you money carping is not that useful in relation to the big picture, even when these claims are categorized by empirical data such as 12 steps rather than 9 or an average programmer can complete the task 3 hours quicker, thus saving $360 in development costs. Preference when it comes to programming methodology, as anybody who has programmed for a living will know, is a very subjective personal thing akin to whether one prefers briefs or boxers. Experience and familiarity with one approach will invariably outweigh the apparent superiority of alternate schemes ”hence, the futility of these claims and counterclaims.

A programmer or a team of programmers, who have spent the last 5 years (or more) working with Microsoft Visual InterDev tools, are unlikely to want to, or need to, switch to using a totally Java-based approach, because the Microsoft scheme involved a few more steps when it came to developing Web services. The learning curve will invariably be too steep, and the retraining costs too high. On top of this there is all the very real but hard to quantify lost opportunity costs, such as higher programming error rates, longer debugging cycles, and a propensity for more testing. Obviously, the converse case ”that is, seasoned Java programmers with no prior exposure to Microsoft development methodology being expected to decamp ”is equally unrealistic . Retraining programmers is a slow and costly undertaking ”particularly so if they were perfectly content with the methods they were using before. Major switchovers invariably only happen over a protracted period of time, because of major changes in overall corporate IT policy, such as those brought about by a merger or acquisition, change in company mission, or the hiring of a new CTO. Section 3.1 highlights the real issues in methodology and points out those factors that are but mere noise.

The bottom line here is that both camps have their pros and cons, and both sides have important roles to play within the emerging Web services market relative to their constituent bases. The die is already cast. Microsoft and IBM, whether they like it or not, have no choice whatsoever other than to share the stage. That is not going to change. Nonetheless, it is safe to assume that, at least for the foreseeable future, IBM will continue to be petulant that Microsoft has the audacity to want to play an active role in the Web services market.

It seems hard for IBM to reconcile that Microsoft really is a bona fide, credible, and influential player when it comes to enterprise-class, server-side application software. However, the reality is that Microsoft now has a huge and ardent following in the programming community, with many casual and part-time practioners only being conversant with Microsoft tools. At this juncture it is also obligatory to point out that this is not just a two-horse race between Microsoft and IBM, or even Microsoft and Java. There are also the very viable and compelling software development options provided by the open source software initiatives, such as Perl and PHP from the Apache Software Foundation (http://www.apache.org) or the increasingly popular Python (http://www.python.org), which appears to be the new no-charge BASIC for the masses. There will be more on this in subsequent chapters.