Lucas Gonze, formerly of WorldOS, sends in these meanderings on XMLP and SOAP. Lucas wonders why it shouldn’t be built on SOAP, and why Microsoft supports SOAP, while Sun is against it.
A question I have been thinking about is why should the XML protocol (XMLP), ne XP, exist? Why should this be a new thing entirely, instead of something built on top of SOAP? Why is Sun against SOAP? Why is Microsoft promoting SOAP, which would seem to be good citizenship on a level that would normally cause an allergic reaction?
- As we saw in the Halloween documents, until recently MS considered commodity protocols a threat.
- Sun generally sees commodity protocols as being in their interest, since network-oriented products need big iron on the back end.
- MS owns the client.
- MS has saturated the client-side market, so in order to grow needs to move into the server market.
- MS has been unable to break the Unix cabal’s hold on the server market.
- Sun holds the lion’s share of the Unix market.
- SOAP is a commodity protocol for remote services.
- XMLP is a commodity protocol for remote services.
- EbXML is a commodity protocol for remote services.
- XML-RPC is a commodity protocol for remote services.
- Multiple standards are no standard at all.
Corollary of 1 and 2 should be that Sun is pro-SOAP and MS is anti-SOAP. Why are their roles reversed?
Corollary of 4 and 6 is that MS growth into the server market has to be at Sun’s expense.
Corollary of 7, 8 and 9 is that XMLP threatens SOAP. Even if XMLP is not a serious threat, because it is too far away from shipping for uptake to be a good bet, it muddies the competitive waters. In short XMLP is fear, uncertainty and doubt. 
Putting it together: MS is giving ground on 1 (commodity protocols) in order to gain ground on 4 (server market share). Sun is spreading FUD to block SOAP adoption, hence to keep MS fenced in in the portion of the market they already own - the relatively small number of projects using MS operating systems on their servers.
Why is MS betting on a new standard, rather than embracing an existing one like EbXML? EbXML is architected for server to server transactions, and gives no room for MS to leverage their client-side dominance. My best guess on XML-RPC, which is probably not right, is that MS could easily have chosen it over SOAP, but preferred SOAP for technical reasons .
In short, this is a replay of the COM/CORBA story, but written in XML, and with Microsoft giving ground to an open standard in order to see if it makes a difference.
1: No slam intended on the XMLP WG, whose work quality I much admire.
2: XML-RPC is beautifully lightweight; however it is too closely tied to HTTP to be used for the kind of high-throughput, low-latency transactions that COM and CORBA excel in.