Microsoft's Soap gets Sun in a lather

The probable adoption by the World Wide Web Consortium (W3C) of Microsoft's Simple Object Access Protocol (Soap) is likely to deepen the rift between the software giant and its old enemy, Sun Microsystems.

Microsoft and 10 other companies, including IBM, Hewlett Packard, Compaq and SAP, submitted the XML-based Soap protocol to the W3C in May with the aim of creating a universal bridge between Microsoft's COM+ component model, and the Object Management Group's (OMG's) Corba and Enterprise JavaBeans object frameworks.

Soap is designed to enable developers using one object model such as Com to access and use components based on another model, such as Corba, over the internet.

The submission represents a landmark for Microsoft, which has been trying to create bridges between its own Com-based software and non-Windows operating systems and development platforms for some years.

However, one notable absence from the companies endorsing Soap is Sun. The company's apparent reluctance to support the protocol has created confusion over its position on the technology.

It would seem logical for Sun to oppose the move because the vendor's Remote Method Invocation (RMI) protocol does the same thing as Soap, although only on a Java-to Java basis.

Quite the opposite, says Anne Thomas Manes, director of business strategy for Sun's software products and platforms division.

She claims that Sun has not taken a negative stance against Soap. "We believe that Soap 1.1 provides a reasonable starting point for an XML-based message protocol standard," she says. "If a standards body such as W3C starts a project to define a standard for an XML-based message protocol based on Soap, we will aggressively join that standardisation effort."

Manes says that one of the main differences between Soap and RMI is that the former enables objects to communicate with each other across different firewalls, while RMI can only be used behind the firewall.

This means that version 1.1 of Soap is more extensible, which is the main reason for Sun's cautiously positive response to the technology. It also has tools for supporting new transport protocols such as SMTP or FTP, which turns it into a more general-purpose XML messaging protocol. As a result, the protocol presents significant opportunities for accessing objects over the internet.

However, Manes is not convinced that Soap is ready to be used commercially yet. "The current Soap implementations are slow and inefficient transports. Soap, by default will be slower than any native transport," she says. "XML is a relatively bulky mechanism to encode data, so the message packets will be bigger, plus you need to convert all the data from the native format into XML, then back again."

As a result, she recommends using one of the existing alternative COM+-to-Java bridges as a means of communicating between the two frameworks at the present time.

Testing times
It would appear to be to Sun's advantage to extend an olive branch to the rest of the vendor community at this stage.

The company's relationship with its licensing partners has become increasingly volatile following its failure to relinquish ownership of its Java technology to the industry.

Sun originally negotiated with the International Standards Organisation (ISO) to make Java a de jure industry standard rather than merely a de facto one. But after negotiations fell through last July, it began talking to the European Computer Manufacturer's Association (ECMA), although these talks again fell through in December.

The ECMA incident led to the publication of an angry letter from Jan van den Beld, ECMA's secretary general, at the end of February. "[Sun's] action over the past two years has resulted in an enormous waste of experts' time and companies' money," he stormed. "Every element of sensitiveness and subtlety is missing by blaming ECMA and TC41 for having not been able to do and complete a successful standardisation project."

To its credit, Sun has attempted to revise the Java Community Process (JCP) - the consensual method by which future Java technologies are supposed to be developed. The second version of the JCP includes an executive committee that would extend control of the Java specifications outside of Sun. But problems still exist.

Java revolt
In the embedded market, for example, renegade vendors, unhappy with Sun's approach to Java, have formed the J Consortium - a group that has eschewed the JCP to develop its own technology because it does not feel the process is sufficiently open and vendor neutral.

John Montgomery, Microsoft's US product manager for Soap, claims: "The reason Sun is scared is that it's playing the game that Microsoft was accused of playing, which is that we were locking everyone into our own APIs [application program interfaces]."

He also discounts Sun protestations that it was not invited to participate in the Soap development process. "For the last two years we have been working on this and kept it quiet. Last September, we went public and anyone was invited to participate," he says.

Another company that has been displeased with Sun's actions in recent times is IBM, which is a core development partner in both the Java and Soap camps.

Scott Hedner, director of Big Blue's ebusiness marketing, remains critical of Sun's stance over Java. IBM has already refused to use the branding associated with the server-based Java 2 Enterprise Edition (J2EE) technology, on the grounds that Sun still owns it and it is therefore not an open standard.

"The brand is a peripheral issue. It's more about the business issues around control of the technology and the licensing rights," he says. "We think that there is a risk because it has become a control point for Sun."

Supporting role
So Sun's current lack of support for Soap threatens to leave it increasingly isolated in an industry that is becoming increasingly unhappy about its stance over Java - and this despite the fact that many vendors support both technologies.

Microsoft's ambivalence towards the vendor should also not be underestimated. The companies are still engaged in a lawsuit over breach of contract because Microsoft allegedly altered some core Java technology in its implementation, and Microsoft staff have gone on the record criticising Sun's ownership of Java.

Although there are several possible outcomes to the scenario, the most likely, given Sun's comments, is that the company will accept and work with Soap, however.

And ironically, support for the communications protocol could present it with an opportunity to reconcile itself to the industry. Because Soap renders the differences between component frameworks irrelevant, it offers the possibility of levelling the playing field, something that may lessen the industry's concern over its autocratic approach to Java.

However, something that is likely to concern Sun is that Soap could make developing applications in Microsoft's Com+ more attractive by negating the main current argument that it is a proprietary framework from which it is difficult to access other component models.

The whole brouhaha raises the interesting point, however, that when the underdog becomes powerful enough, it appears to take on the characteristics of the dominant force it originally sought to undermine.

Sun's original stance with Java was to promote openness, industry ownership and the devolution of authority in the face of autocracy, arrogance and aloofness. It is now being criticised for the very behaviour it originally challenged.