by Ganesh Prasad -- October 28, 2001
Synopsis: This article is a sequel to an earlier one that laid out a strategy for taking on the Microsoft .NET challenge. It contains responses to issues raised after the earlier article.
My article of August 2001, "Will Open Source Lose the Battle for the Web?", struck a chord, to put it mildly. Tremendous discussion has taken place in the talkback forums, and I have received the odd e-mail as well, so it was only appropriate for me to digest these and respond.
Before going on to discuss the issues raised in the talkbacks, let me very briefly repeat the gist of the article.
I used the dramatic shift in webserver marketshare (5% in favour of Microsoft IIS at the expense of Apache) in July 2001 to suggest that Apache as a plain webserver was perhaps losing its appeal to users. In the time that Apache was making minor tweaks to its features, Microsoft has been repositioning its products as a platform to enable "web services", under the umbrella name ".NET". This is perhaps making the Microsoft products more attractive to users looking for e-commerce capability in the future.
I added that web services are a way for applications to advertise their own capabilities over the web, find other such applications, and call each other to perform transactions without prior or ongoing human intervention. There are Internet standards for these, such as WSDL (Web Services Description Language), UDDI (Universal Description, Discovery and Integration), SOAP (Simple Object Access Protocol) and the newer ebXML (e-Business XML) suite. All of these are XML-derived languages, and can be communicated over the ubiquitous HTTP protocol.
I noted that the Java 2 Enterprise Edition (J2EE) already had a mature infrastructure in place for scalable distributed computing. I suggested that rather than copy the Microsoft architecture for web services, we should use pre-existing Open Source implementations of J2EE components and add implementations of the Internet standards for web services. With a friendly interface topping it off, Open Source would have a convincing alternative to Microsoft's technology.
Though I had anticipated some resistance to the idea, I was astonished at the scale and breadth of the opposition I encountered. The points that were raised vary in seriousness and degree of validity, but they all nevertheless need to be addressed. Accordingly, I went through the talkbacks in detail and classified the responses under different heads. It's a fascinating mirror that I can now hold up to the community.
(Note: In spite of the humour in the characterisations below, I promise to respond to each argument seriously enough)
No trouble ("We're with you, pal"):
Some diversity, huh?
I will respond to all the above groups except the last (whose existence is perhaps solely to remind us that it takes all kinds).
First of all, my appreciative thanks to those who encouraged and supported me through their e-mails and postings.
While there are 20 groups by the above classification that didn't agree with my arguments, I find myself sympathising and even identifying with some of them, -- the freedom-fighters, the parallel processors and the diversity democrats. I'm also usually found in the company of corporation cynics, but embarrassingly for me, not this time.
The constructive critics would be happy to know that I am aware of and use Apache Tomcat on a daily basis, and have used the Apache SOAP servlet on Tomcat as well (My complaints regarding the latter implementation could form another article!). However, Tomcat is technically only a JSP/servlet engine, not a full-blown application server like JBoss. It plays in a much lower-end space than a true web services platform would, so that's a crossbow I'm not eager to fire at the .NET tank. I'm also not aware of any Apache modules for SOAP, WSDL or UDDI. Without a corresponding framework for back-end application integration, they would be of limited value anyway.
Like the freedom-fighters, I too want a free Java, and by "free", I mean four things:
Unlike the freedom-fighters, however, I am willing to work with a non-free Java in the interim to fight what I think is a greater immediate threat -- the impending proprietarisation of the web. Let a thousand commercial applications bloom, but the plumbing of the web must always remain open and free (in the sense of freedom). .NET threatens the freedom of the web's very plumbing, which is why I believe we have no time to lose, and must hurl every weapon we have at this monster. J2EE, in my opinion, is the most powerful such weapon.
I've also no real bone to pick with the parallel processors. The community is certainly large enough to support multiple initiatives. It's more important to me that the community not neglect what I think is the technology with the greatest chance of success -- J2EE.
The diversity democrats are right, too. What's so special about Java, anyway? Why can't developers choose the language they're most comfortable with? I don't really have an answer except that language diversity is not an urgent requirement in today's context, and we can work at getting there after we've won back our freedom. In any case, the argument for other languages isn't a strong enough one against Java.
Before I delve into addressing all the other arguments, I think it would be worthwhile taking a detour through the concepts behind web services, the J2EE platform and the .NET architecture, so that we're all on the same page. Many of the arguments I heard reminded me of the six blind men and the elephant, because the respondents in question only seemed to understand some of the relevant concepts.
The concept of web services first crystallised with XML-RPC (XML Remote Procedure Call), which represented the realisation that XML was capable of carrying information corresponding to both a procedure request and a response. That quickly evolved into SOAP (Simple Object Access Protocol), a standard first proposed by Microsoft, then later adopted and improved by IBM. When you want an application to be invoked over the web, you first need to document the way in which it must be called. SOAP specifies how a system may call another using an XML message sent over HTTP, and receive a response in a similar format. All of this is independent of the language in which the procedure is written, the operating system it runs on and even its underlying object system (COM or Java).
Another XML format, WSDL (which is not the callsign of a radio station but an acronym for Web Services Description Language) is used to document what a service does and how to call it. Among other things, WSDL defines the name of a service, its component procedures or functions, their parameters, their returned values and all relevant data types.
Finally, the WSDL description of the service may be published on the web in a way that can be searched by external applications. UDDI (Universal Description, Discovery and Integration) is a protocol that allows you to point to your hosted WSDL file from a web-based directory service and allows clients to search that directory service. UDDI is explicitly oriented towards searching and lookup.
(Any doubt that these represent advances over traditional computing should be dispelled by the observation that they are not traditional three-letter acronyms but four-letter ones!)
The following table illustrates these concepts.
| Web services format/protocol | Description |
|---|---|
|
UDDI (Universal Description, Discovery and Integration) |
A standard for publishing information about web services in a global registry. A UDDI entry also contains the URLs where WSDL files for web services may be found. |
|
WSDL (Web Services Description Language) |
Describes the structure of the XML messages that go to and from a web service. |
|
SOAP (Simple Object Access Protocol) |
A standard for applications to exchange XML-formatted messages over HTTP. |
The sequence of operations is straightforward. Another application looking for services of the kind your application provides searches a UDDI registry for those types of services. It finds an entry corresponding to your service. The application goes to the appropriate URL and reads the WSDL file that describes your service. Now the application knows how to format the SOAP procedure call and also the format in which the response is going to be in. It uses this knowledge to invoke your service over the web and obtain a response.
Within an organisation, or between existing business partners, the discovery phase represented by UDDI may not even be required, although it can provide location transparency for physical servers. A WSDL file is all that needs to be shared between caller and callee.
ebXML (an even more advanced, five-letter acronym standing for "eBusiness XML") is a fresh attempt to do all of the above. While SOAP, WSDL and UDDI are the creation of vendors (Microsoft, IBM and Ariba), ebXML is the product of a user group under the banner of UN/CEFACT and Oasis. It's not an entirely independent set of technologies, because it does try and reuse some of the specifications from the other standards. For example, ebXML uses SOAP as its protocol for calling web services. It also tries to address more complex issues such as authentication, security, transactional calls, etc., which are currently not supported by SOAP. However, the ebXML specification is quite a way away from a final version, so we shouldn't hold our breath. For all practical purposes, web services in the near future will continue to mean just UDDI, WSDL and SOAP.
Java, as is often said, is both a language and a platform. This means that you can write programs in the Java language, but when you compile them, they are not converted to regular processor-specific machine code. They are converted to the pseudo-object code ("bytecode") of an imaginary processor called the Java Virtual Machine. The Java Virtual Machine is a machine-emulating application that is written for different operating systems and runs on top of them, providing the same kind of interface to Java programs that run on it. It can be thought of as an "OS wrapper", because it hides the differences between the underlying operating systems. That's why one of the promises of Java is "write once, run anywhere". It's also why Microsoft hates it. A world full of applications that are written in Java and that run on the Java platform do not require Windows underneath. You could equally run Linux or MacOS, and that would make no difference at all to your application.
The Java language, to be truly useful, requires a large number of libraries that applications can call to perform common functions like networking, file I/O, graphics, etc.
The diagram below illustrates these concepts.
|
|
|
|
|
|
|
|
|
So Java is more than just another language like C or C++. It actually consists of three parts, -- a language and its associated compiler, a set of libraries, and a virtual machine to run programs on. By contrast, C or C++ has only two of these three things, -- a language/compiler, and a set of libraries. A C/C++ executable runs on the physical machine, and is generally faster because no run-time translation is required, but it is obviously less portable across CPU architectures and operating systems. What you get when you download the Java Development Kit (JDK) for Linux or Windows is the compiler, libraries and the virtual machine for that operating system. This basic set is an implementation of the base Java specification called the Java 2 Standard Edition, or J2SE.
The Java 2 Enterprise Edition (J2EE) is another set of specifications. J2EE is not a piece of software, though Sun does provide a reference implementation for it. It specifies how Java programs will run in an Enterprise context (with the attendant requirements of performance, robustness, scalability and location-transparency), and the interfaces between Java programs and other Enterprise components. With a consistent syntax and style, J2EE lets programmers talk to many systems in one language -- Java.
J2EE is the Tolkienesque ring that binds them all, -- web servers, mail servers, databases, message queues, directory servers, etc. To systems integrators and enterprise application developers, it promises the holy grail of seamless connectivity and interoperability.
The J2EE specifications are tight, and there is a strict series of tests that third-party implementors need to pass before they are certified to be J2EE-compliant (perhaps too strict from an affordability viewpoint!). The advantage of having strict specifications and compliance tests is that users can switch vendors without breaking their applications, because all vendors support exactly the same interface. In earlier versions, there were still minor differences between implementations that led to annoying errors when applications were ported, but these incidents are becoming fewer and farther between as the specifications get tighter and the implementations get better. It may not be overoptimistic to say that the promise of "write once, run anywhere" is being realised today.
The most important part of J2EE is perhaps the EJB (Enterprise JavaBeans) specification. This describes how business logic must be coded and run on a server (called an "EJB container"). Persistent objects like bank accounts and products in inventory are modelled as "Entity Beans". Business processes such as the transfer of funds between bank accounts are modelled as "Session beans". If a transaction needs to maintain state across a session, such as a shopping cart, it is modelled as a "Stateful session bean", otherwise it's a "Stateless session bean". The programmer of a bean only needs to worry about the business logic of the application. The EJB container is responsible for performance, threading, clustering, failover of running transactions, security, etc. The EJB container is the equivalent of COM+ in the Microsoft world. The basic idea is the same, i.e., that the system should take care of the plumbing issues, leaving the programmer free to concentrate on application logic alone.
The following table lists some of the component interfaces of J2EE, and examples of implementations of each. It's interesting to see how we can put together a completely J2EE-compliant system using just Microsoft components, because there happen to be J2EE interfaces for them. In most cases, this is because the Microsoft product happens to support an Internet standard (e.g. JavaMail support in Exchange exists thanks to SMTP and POP compliance), and that's all that's required. In other cases, a special driver is required, and this is available from a third party, sometimes free (e.g. a JDBC-ODBC driver for SQLServer).
| Enterprise component | J2EE Interface | Open Source Implementation | Microsoft Implementation | Other Commercial Implementation |
|---|---|---|---|---|
| Container for back-end business objects | Enterprise JavaBeans (EJB) | JBoss | None, though all third party EJB containers run on Windows as well. | Weblogic, WebSphere, iPlanet |
| Web server | Java Servlets, Java Server Pages (JSP) | Apache Tomcat | None, though third party plug-ins for IIS are available, such as ServletExec and JRun | Resin, JRun (standalone) |
| SQL Database | JDBC (commonly thought of as Java Database Connectivity) | PostgreSQL | SQLServer | Oracle, DB2 |
| Directory Server | Java Naming and Directory Interface (JNDI) | OpenLDAP | Active Directory | Novell NDS |
| Message Queue, Publish/Subscribe system | Java Message Service (JMS) | JBossMQ, SwiftMQ | MSMQ | IBM MQSeries, Tuxedo /Q |
| Mail Server | JavaMail | SendMail, PostFix | MS-Exchange | Any SMTP and POP compliant servers |
The table also reveals another interesting insight. It is possible to build a completely J2EE-compliant system without using a single commercial implementation. This means that the Enterprise-class features of J2EE are not reserved only for large organisations with deep pockets. They are available to everyone, from the proverbial two guys in a garage, through cash-strapped non-profit organisations, universities and research labs to government departments and the Fortune 500. Of course, there are commercial implementations, too. J2EE therefore provides access to a complete range of Enterprise products, and customers can pick and choose the implementations they want, at a price that suits their budget. What's more, they can switch implementations and vendors without fear of breaking their applications.
Effectively, J2EE is an agent of commoditisation, just like Open Source. Like Open Source, it transfers power from vendors to users and creates a buyers' market. In practical terms, what this means is that users can either follow an inexpensive prototype strategy (by using Open Source implementations in development, and then switching to commercial equivalents in production), or they can follow a mix-and-match strategy (by using the cheapest components that are good enough). There is considerable flexibility here. Critics of Java would do well to remember that this is no imaginary benefit, as thousands of users are discovering to their delight. Nor is it vapourware, because the products exist today, and thousands of J2EE-based applications have been built and are in production.
The biggest complaint against the Virtual Machine architecture is speed. This argument can be made against the .NET architecture as well (see next section). Sometimes, this speed handicap is more imaginary than real. Java supports multithreading, which can yield significant performance benefits compared to traditional process-forked Unix applications, especially on multi-CPU machines. The 1.3 version of the JDK includes the HotSpot virtual machine, which is much more optimised than earlier JVMs. In any case, performance is relative, and needs to be measured in real-world terms. A 30% speed advantage of a C application may be meaningless if response times are of the order of milliseconds. On servers with sufficient RAM, Java-based applications actually perform quite well. As Java performance continues to improve into the future, speed will be less and less of an issue, especially when weighed against the very real benefits of the platform. After all, hand-coded assembly language programs may still be faster than any high-level language, but there are very real reasons why assembly-language coding has fallen out of favour for most applications development. History, and the inexorable progress in hardware and networking speeds, are on the side of Java.
The second major lightning rod in J2EE is the EJB architecture, which has attracted a disproportionate amount of flak. To be fair, the EJB specification is the least mature of all the J2EE interfaces, and its complexity makes it difficult to get right the first time. The areas where EJB is weakest are in persistence and object-relational mapping. However, we need to put this in context. EJB may have bitten off more than it can chew when specifying a transparent ("container-managed") persistence model for objects, regardless of complexity, but it doesn't leave developers without other options. What were developers doing before EJB? They can still do the same things. If they don't like container-managed persistence, they can use bean-managed persistence and roll their own persistence mechanisms. To get even more basic, they can do things the Microsoft COM way, and use stateless session beans to interact directly with the database on every transaction. It must be remembered that EJBs only attempt to provide another way. They do not preclude doing things "the old way", if that is what developers need to do.
|
WinForms | ||
|
|
|||
|
|
|||
A quick .NET terminology demystifier:
.NET: Essentially, .NET is an umbrella term for a set of different components. Its architecture can be visualised in three layers (see diagram). The bottom layer is called the Common Language Runtime (CLR). This runs programs in Microsoft's Intermediate Language (IL) format, similar to the way that a Java Virtual Machine runs Java programs that have been compiled into architecture-neutral "bytecode". So those familiar with Java can think of the CLR as a JVM equivalent, and the IL as bytecode. The CLR provides a common abstraction to access the services of the underlying OS, and can be viewed as an "OS wrapper". In theory, therefore, we can have CLR implementations for Linux as well as Windows, and applications can run unchanged on both of them, since they will not interact directly with the OS. There will, however, be a way for applications to call Windows services directly, gaining some performance benefits at the cost of breaking cross-platform capability. This is similar to the Java Native Interface (JNI) that lets Java applications call native OS code.
So far, the analogy with Java is straightforward. However, .NET explicitly allows for multiple languages to be compiled into the same Intermediate Language and run on the CLR with similar performance. Source programs in different languages can even be freely mixed, thanks to a "Common Type System". In contrast, even though there was some talk of compiling Ada and Python programs to Java bytecode, the concept has not proved popular in practice (To Jython fans: Yes, I know about Jython, but it's a drop in the Java ocean). .NET also takes the language-independence idea further by allowing classes in one language to inherit from parent classes written in another.
Just above the CLR are a set of Framework Classes that roughly correspond to the Java libraries. This is a kind of supporting infrastructure that makes the bare-bones CLR actually usable by applications.
Above this is what roughly corresponds to an application or user-interface layer. One component at this level is ASP.NET, which includes WebForms and Web Services. Another component is the next avatar of traditional Win32 applications, called WinForms.
The WebForms subsystem of ASP.NET translates to traditional HTML forms and Javascript, with the added sweetener that WebForms can sniff out the type of client and send across the appropriate markup. Web Services are web-invocable APIs that have an XML-derived language definition. The interesting thing about these calls is that they need not occur just between browser and webserver like regular HTTP traffic, but can also occur between webservers, a form of peer-to-peer communication. So a user request can be satisfied by a server that transparently makes calls to other servers and puts those results together to provide a composite service. Unsurprisingly, these services are described using WSDL and called through SOAP.
All applications are compiled to IL and run on the CLR.
Passport: Perhaps the most critical web service is what is called the "identity service", or authentication service. For many e-commerce transactions, the identity of the party engaging in the transaction needs to be verified ("Transfer a million dollars into account number XYZ" is an instruction that obviously cannot be carried out without some background checks). Therefore, the identity service is a kind of "super-service" that every other service relies upon. Microsoft realises this, and has made its own identity service (called "Passport") the one that will be accessed by default by Windows XP users. In theory, there could be any number of independent identity services in the world, and they could be looked up using a UDDI interface. However, early reports of Windows XP and MSN Explorer (the .NET avatar of Internet Explorer) indicate that the user will be unable to sidestep Passport when accessing web services from a PC running Windows XP. With over 90% of desktop users locked into Windows, and with Passport holding the personal details (including credit card details) of potentially every web user in the world in one centralised database under Microsoft's ownership, the move to .NET raises enormous issues of privacy, security and control.
Hailstorm: This is the first set of web services and underlying infrastructure (CLR, language compilers) that Microsoft has released to testers and business partners. It can be considered a prototype for the complete .NET implementation, which will proceed over the next couple of years.
The major feature of .NET is its ability to allow developers to use any language of their choice, with the guarantee that they can access all the modern features of the .NET platform, and enjoy roughly similar performance. One of the languages introduced with .NET is C#, which is a slight improvement over Java in many respects. Other than these, .NET does not bring anything to the table that Java and J2EE don't already have.
Currently (and some cynics would say, expectedly), the Microsoft, Apache and IBM implementations of SOAP and WSDL differ slightly, enough to create integration problems. Only part of the reason is dear Microsoft's known habit of breaking standards. More importantly, the Apache implementation of SOAP is actually incomplete, and lags those of Microsoft and IBM at the time of writing. The 1.1 version of the SOAP standard is also partly to blame for its ambiguities that allow two "correct" implementations to be incompatible. Nevertheless, these problems are gradually disappearing with advancing versions of the standards, and improving implementations.
Technically, there is little left to nitpick about in .NET, except perhaps that SOAP is an inadequate protocol to address more complex issues such as security and transactional semantics. SOAP's bigger cousin, ebXML, is designed precisely to overcome its limitations, and so any modern web services architecture must aim to implement ebXML at some stage.
One vaunted feature of .NET, its language independence, is actually a double-edged sword. A developer's paradise can be a project manager's nightmare. Standing in a project manager's shoes, I would be more comfortable managing a homogeneous team of 10 Java programmers than a motley team of 5 Visual Basic programmers, 3 C# programmers and 2 C++ programmers. .NET's ability to let classes in one language inherit from classes in another has the potential to create mayhem of another sort, -- inheritance as a means of language translation! ("I was asked to modify the behaviour of a C# class, but I only know VB. So I inherited from it and overrode that behaviour in my VB subclass.") Can one see the project manager and future maintenance programmers tearing their hair out?
In contrast, the single-language philosophy of J2EE is a blessing. The requirement to know Java is a barrier, no doubt, but barriers are no longer barriers once you've crossed them. Once you learn Java, this "disadvantage" of J2EE simply melts away.
Early indications are that C# is a slightly better language than Java, from a purely technical point of view. So, as a technical person, shouldn't I be eagerly switching to C#? Well, we must remember that Field Marshal Erwin Rommel was reportedly a very decent guy, but the master he served was the real problem. If C#'s victories are going to translate into Microsoft's victories, I choose to be technically retrograde.
Technically, .NET appears to be a sound architecture that can deliver the goods. But that's like saying Mussolini made the trains run on time. Great job, but let's check out the dungeons.
The loophole that lets applications drill down to access native Windows services "for performance" will completely destroy the nominal cross-platform capability of the .NET architecture, and it's difficult to visualise Microsoft wringing its hands over this. If anything, they will encourage building Windows hooks into .NET applications to effectively reduce them to Windows applications. Microsoft is not in the cross-platform business. Microsoft is in the proprietary platform business. Those hoping for .NET to provide a level playing field between Windows and Linux will be sadly disappointed. The friendly fire of performance purists in the .NET camp will end that idealistic crusade.
Second, anyone with the faintest instinct for self-preservation will recognise Passport as the biggest threat to citizens' rights since apathy. The fact that Passport already has over a hundred million subscribers tells us that Goethe was a hopeless optimist ("He only deserves freedom and life who daily conquers them anew"). Given Microsoft's machinations, it doesn't seem possible to divorce Passport from .NET, so there doesn't seem to be any alternative to throwing this baby out with its bathwater.
Even those convinced of Microsoft's good intentions (in this day and age!) must remember that Microsoft's servers have been hacked into and Windows source code has quite possibly been stolen. If they cannot safeguard their own crown jewels, what is the guarantee they can safeguard a database containing your personal details? A centralised repository like that will be extremely attractive to criminals, and Microsoft's security track record does not inspire much confidence in its ability to keep it safe.
Third, there has been a good deal of FUD from Microsoft on the legality of Open Source efforts to clone .NET. At the same time, they eagerly use these initiatives as proof of .NET's widespread acceptance. Indeed, it seems likely that the more successful these ventures are, the greater will be Microsoft's incentive to derail them. Sun was able to obtain the help of the courts to stop Microsoft from polluting Java, but can Open Source legally prevent Microsoft from making proprietary extensions to .NET in future? It's their own technology! They can do anything they like with it. So swimming with the Microsoft shark is definitely a dangerous pastime that is better avoided. .NET is a proprietary technology, regardless of appearances. In the web era of open standards, that should be sufficient reason to damn it.
Fourth, in the absence of strong competing implementations that implement web services correctly, what we will probably have in the near future are MS-SOAP, MS-WSDL and MS-UDDI, -- embraced and extended Open Standards that lock out everyone else, along with some oh-so-convenient Microsoft-only protocols that won't work on other platforms. If you think Microsoft won't try that, there's a nice bridge over at Sydney harbour that I'd like to interest you in. To prevent the unthinkable and keep the crooks honest, we need to flood the market with inexpensive, easy-to-use and correct implementations of web services.
And that brings us, finally, to the arguments of various sections of the Open Source community.
To those I characterised as having starting trouble, I need to say this:
The statistical significance of Apache's drop in market share is not the point. The point is that it's a good opportunity to critically evaluate our competitive position. A smart competitor does not disparage the competition or encourage complacency. After all, what would the other side do in a similar situation? Whenever Microsoft sees something remotely resembling a threat, they jump on it with both feet and ask questions later. Perhaps we're afraid of looking silly if we rush off and implement web services because of a temporary fluctuation in market share, and Apache bounces back to 60% the very next month. Well, better silly than sorry. Would you prefer to wait six months to confirm that there is a trend before taking some action?
Again, there is no room for complacency regarding Microsoft's security weaknesses. There have always been security and virus problems with Microsoft software, and it has never forced users to switch. Don't count on it happening now. Hoping the other side will drop the ball is a bad strategy going into any game.
And for the information of the skeptics, web services are real and not a solution in search of a problem. In corporate and banking circles (where I work), there is tremendous excitement about it. OFX (Open Financial Exchange) generated a lot of interest when it first appeared, with some corporations even now writing OFX implementations. SOAP, WSDL, ebXML, etc. are generating even greater interest now, and with good reason. OFX was SGML-based, while the newer standards are based on the simpler and more modern XML. A system through which organisations can exchange day-to-day business information and conduct transactions with their business partners using a standard, inexpensive and easily accessible medium is extremely attractive. It will cut costs in the first instance and enable far greater flexibility and choice in future. Concerns about security are no longer a show-stopper, because there is greater optimism today that security issues will be sorted out than in the early days of the web. Banks are getting pretty un-stodgy these days...
It is entirely likely that web services will first start to be used by corporates and then by individual customers. In other words, the B2C (business-to-consumer) market for web services may lag the B2B (business-to-business) market by a couple of years. If implemented in a standard and cost-effective way, it will enable small businesses to participate in the electronic marketplace by bringing about "EDI for the masses". Smaller organisations no longer have to implement multiple EDI systems to comply with the requirements of their larger business partners. Web services promise a common vocabulary for all.
Let no one doubt that XML has now won the mindshare war. Every technology vendor, including Microsoft, is flogging XML, and regardless of what the skeptics say, sheer industry momentum will get it to work. Even if I were to believe that XML is overhyped, I would respect the momentum of near-unanimous opinion. XML will be the de facto way of doing things in the future simply because it's a self-fulfilling prophecy.
And therefore, I have no reason to doubt that in the very near future, there will be tremendous development activity focused on getting applications to interoperate using XML-derived transactional languages over the vanilla HTTP-based web.
The view of web services that I take is as a means of Enterprise Application Integration (EAI) internally and as the next-generation EDI in relationships with business partners and across geographies. However, many people have a much narrower concept of web services. For that, we probably have Microsoft to thank. Through their actions, they have focused attention on just three aspects:
This has led many to attack the entire web services concept on these grounds:
I absolutely agree on these points, and I oppose Microsoft's initiatives in these areas as strongly as the next person. Yet, web services are about much more than this, as we have seen. They are the next logical stage of the web's evolution.
Everything that we need to implement web services may or may not already exist in Open Source, but to be attractive to users, it needs to be available in one easy-to-use package, not in the form of individual software packages that the user has to separately install and integrate. Until such an integrated package is available, Microsoft's alternative will always appear more attractive.
Open Source may have a fabulous alternative to .NET under its sleeve, but until it makes an appearance, we can't comment on it. It's certainly exciting to visualise Open Source riding up in the nick of time, Gandalf-like, at the head of an army of Elves, to beat the Orcs. But we don't live in Tolkien's fantasy world and need to make real-world plans.
That's why I believe we cannot be complacent. We need an Open Source web services platform. But which one?
Let me now address those who I consider to have "direction trouble".
Some Open Source developers like the architecture of .NET, but do not want its implementation to be available only from Microsoft. The specifications of the CLR and the Intermediate Language are publicly available, and Microsoft has promised to publish the XML formats of its web services. So these developers believe they can create an Open Source version of .NET. The Mono initiative of Ximian, Inc., is the best-known project. Ximian can certainly implement large parts of .NET, including most web services, but the implementation of the identity service raises many interesting questions. It is not clear at the present time how compatible Mono will be to .NET without a seamless Passport interface. It's instructive to note that the specification of the Passport service is not open. Hiding crucial APIs, of course, is textbook Microsoft. Users of Mono will probably not be able to use Microsoft-oriented web services in the absence of Passport access. Since Passport is one of the most controversial pieces of the .NET architecture, Mono will either be an unwilling assistant to its acceptance, or it will simply not work. It is unlikely that Microsoft will let a crucial part of its planned web domination be diluted through the existence of rival identity services. Besides, even if Passport is reverse-engineered and cloned, there is a certain "winner-takes-all" attribute of a centralised identity service. The more subscribers Passport has, the more it will attract. Having multiple centralised identity services is a contradiction in terms. That's why Mono is a bad idea that is better abandoned. Ximian will either be dead or undead, in that they may have to push the evil Passport scheme in order to survive. Either way, Mono will be of no use to Open Source.
The other Open Source initiative, "dotGNU", is a different kettle of fish. DotGNU is explicitly designed to overcome the potential privacy violations in .NET. It allows for services to run locally on a user's PC as well as remotely, so as to let users keep their personal data confidential. It is also in the process of designing a distributed identity service called "Virtual Identities" (in contrast to the centralised Passport) which is explicitly oriented towards protecting users' personal data. DotGNU even supports multiple IL formats, not just the one specified by Microsoft. Certainly, dotGNU is a commendable effort, both technically and from the viewpoint of freedom. However, it suffers from a perception problem. It appears to legitimise .NET, even though its stated purpose is to fight it. The casual observer is easily misled into thinking that .NET is receiving support from Open Source.
More importantly, dotGNU has an unintended side-effect. It weakens the appeal of J2EE, the primary opponent to .NET. By weakening J2EE, dotGNU is strengthening the very enemy it seeks to destroy. Often, in elections, minority groups resort to "tactical voting" to secure their interests. Rather than vote for the candidate they like, they vote for the candidate who is most likely to defeat the one they don't like.
Even though I have high personal regard for the people involved in dotGNU, and appreciate the ethical underpinnings of this initiative, I still consider any cloning of .NET a waste of time that will end up doing more harm than good. The only feature that .NET offers that is not in J2EE is language-independence, and I have my own views on the usefulness or otherwise of that feature!
Many have talked about Zope, Jabber, Cocoon and other Open Source products that supposedly do many of the things that web services are supposed to do. Rather than descend into a slanging match on the relative features of these products and J2EE, I will accept for the sake of argument that any of these servers can do everything that a J2EE implementation can. Having accepted that, does anyone believe it possible for any of these servers to gain traction against .NET in the next couple of years? Do they have the corporate credibility to swing decision-makers away from .NET? As I said, I believe B2B will take off first, and so the corporate decision maker is a vital link in the chain. I frankly do not believe that this can be done. In time, it may well be possible to build awareness around these products. But right now, we need an alternative that is equally high up on the corporate credibility index. Nothing fits the bill better than J2EE.
And to those with "mule trouble" who stubbornly refuse to go the Java route, here's my piece:
Don't trust Sun? You don't have to. Just take a realistic look at the way the Java Community Process has been evolving. Look at the number of participants who have contributed to the various Java specifications. Even if you doubt Sun's bona fides, do you think the other industry participants (who include heavyweights like IBM and Oracle) will stand by while Sun grabs their intellectual property contributions and turns them into an exclusively Sun technology? I don't believe it is practically possible for Sun to unilaterally move Java in a proprietary direction.
There is also the small matter of precedent. At least so far, Sun has not tried to corrupt or hijack an Internet standard. Microsoft has done nothing but. So while I agree with the corporation cynics that both are greedy corporates (translation: they're both answerable to their shareholders), I would trust Microsoft a lot less than Sun. J2EE and .NET are not ethically equivalent in my eyes.
Lest anyone go away with the impression that I am a Sun apologist, I strongly resent their shortsighted refusal to provide affordable J2EE certification assistance to JBoss, the only J2EE server capable of fighting .NET at the high-volume, low end of the market. So, while all corporations may be greedy, they are not all equal. Microsoft is greedy and smart. Sun is merely greedy.
Let me repeat: While I would dearly love to see a Free Java, the situation today does not give us the luxury of tossing aside the biggest weapon we have against a hostile takeover of the Internet. What would you rather have, a Free Java or a Free Internet? There will be a battle to free Java one day, I promise you that, but let's not fight on too many fronts at once.
I'm also not convinced that J2EE's single-language orientation is such a damning limitation. We can work in parallel on compilers to convert other languages to Java bytecode, but that's really all that we should be doing on that score. Cross-language inheritance? Horrors!
If you really miss the programming freedom that C/C++ gave you that Java doesn't, I am sorry, but I cannot empathise. I was a C/Unix programmer for over 8 years, but Java has made me promise myself not to write anything more in C. I am not a masochist, and I don't enjoy tracking down obscure pointer bugs or memory leaks. Java lets me concentrate on my main job and makes software development fun. I don't complain about the noise when opportunity knocks.
Java is improving with every release, and the coming 1.4 version continues this trend. If you had problems with Java before, maybe it's time to try it again. Many of those issues probably don't exist anymore.
Will Java ever be as fast as C/C++? Probably not. Will it matter? Probably not. In my own experience, the slowest parts of Java are applets and Swing. Both of these are client-side Java technologies. Most web applications today use lightweight Java Server Pages (JSP) rather than applets. It's a move back to the server. You may find that server-side Java is a great deal faster than anything on the client side. It's also quite comparable in performance with other server-side technologies. Besides, performance is something you look at in relation to real-world requirements as well as the other benefits the technology yields. Java performance is hardly a factor on which to base a decision anymore. Given enough memory (and memory is cheap!), Java programs perform extremely well.
Yes, Microsoft will not ship a JVM with Windows XP. What does that mean? It means that Internet Explorer (or MSN Explorer) will lack a JVM and hence be unable to run Java applets. But who runs Java applets anyway? For every web application that uses Java applets, there are at least a dozen that use Java servlets and Java Server Pages. What the browser sees in these cases is standard HTML. Who really thinks Windows XP's lack of built-in support for Java applets will affect server-side Java?
The weakest part of J2EE is the EJB specification, and even that appears to be pulling its act together with the 2.0 version. Any weaknesses are ephemeral and are not sufficient reason to dismiss the technology. RMI is not the preferred implementation for web services anyway, it's XML over HTTP. That will ensure that a Java-based web services platform can interact with another platform built using a different technology.
So is this just an Anything But Microsoft issue? Hardly, because the web is about freedom and about keeping the user, not vendors, in control. Web services should advance the web without restricting this freedom. If we implement Internet standards for web services on top of open source versions of an enterprise platform like J2EE, we will achieve precisely that. If we stand by and let the Microsoft version of web services capture the world, then we lose the essential freedom and user control that we had wrested from proprietary interests not so long ago.
Of course, I can also see that I underestimated the extent of dislike and loathing that many in Open Source seem to feel for Java. It saddens me that so many intelligent people can fail to think strategically. You don't have to like Java. You just have to realise that Java has the best chance of stopping Microsoft's recent resurgence. Like I said, this is a form of tactical voting, where you vote not for the guy you like, but for the guy with the best chance of beating the creep you absolutely don't want.
So take a deep breath, and hiss through clenched teeth, "All right, I'll work with this %$&*(&*^ Java for now, but after we beat Microsoft..."
That's good enough for me.
Ganesh Prasad is a Sun Certified Java Programmer, a web architect by profession and a Linux user by choice. Though not a betting man, he is willing to wager his freedom that Java-Linux is the way to go, because the alternative involves no freedom anyway.
Copyright © 2001 Ganesh Prasad. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. A copy of the license is available at http://www.gnu.org/copyleft/fdl.html.