Slashdot Mirror
Microsoft Proposes "Open" Replacement for CORBA
Alex T-B writes "Looks like Microsoft is taking the threat from CORBA and Java seriously. They've
launched a network protocol suite [C-Net story] to embrace
and extend the distributed business software market. SOAP, as
it's called, is based on XML, and is supposed to move audiences
away from UNIX and towards adopting Win2k and fully MS-ized
software solutions. Interestingly, no MS software is needed to
use SOAP, and it levels the playing field as 'proprietary'
solutions can be replaced with a universal standard that
enabled apps written in different languages to communicate with
each other easily over the internet. Is MS actually doing the
market a favour by removing vendors' 'lock-in' strategies to
properietary solutions?"
I don't call what O2K saves as "XML". Show me the DTD and the style sheets so I can edit it elsewhere. Show me the specifications so other software can read it. Then I'll call it XML.
After Microsoft convinced everyone to wash their
hands with SOAP and to quietly eat their SOUP, now
it comes back with the LEMON protocol. Presently they refuse to disclose the meaning and details of their new Open Protocol. Meanwhile some anonymous sources claim to be "Lamers Entitled to Moron Over the Network". Anyway it seems this will be the last blow Microsoft plans to give their concurrents. First it was SOUP where they teached a lesson to all those dirty and nasty Linux boys. Later it was SOUP where they teached good manners to IBM and SUN.
"Finally we get the final standard..." says Mr. John Johnson of expert Gardners Group. With a clear and fresh yellow smile, he explained the great advantages of the new protocol. "You see, it might not taste well at first sight, but similarly to a real lemon, it can give you a lot health to your enterprise. It has a lot of vitamin C on it..."
It seems that Microsoft has already filed a proposal to international standards bodies to make it an new well accepted protocol. So, soon, every one of us will be happily eating lemons while roaming the net...
After reading the spec, I'm going to take up my position as liking SOAP. Why? :
1. Keep it simple & stupid. SOAP looks like a very dumb protocol. It's basically a near wire level protocal; sits o top of XML. The only thing it cares about is proper formatting of XML in passing information (looks like you can even pass structs). It's up to the applications to deal with whatever it needs to deal with (like sessions and whatnot). Example of KISS successes? HTML and TCP/IP. All I'm going to say about this is for the OSI model, I should get the shirt saying, "Milliones of dollars, an international consortium, and all I got was a picture with 7 layers." HTML and TCP/IP was so successful because they were simple to use and implement.
2. Security concerns. NONE. Why is that good? Well, what would happen if the protocol handled the security? I think we would get bogged down with the overhead of security negotiations... And what if there was a flaw, then we'd all be @#$%... Looks like the security is up to the user, and I'd rather trust the security in my web server (Apache) instead.
3. Cross platform... come on! It's only Text...
4. DCOM? COM was never ment to be cross machine, and DCOM was a hack (IMO) to solve these RPC issues. Even still, DCOM has a lot of overhead to keep the session and connection alive. A lot of overhead to get one call to and back. Not to mention all the crap you have to do to actually implement DCOM... IPointers... god awful!
5. CORBA? Repeat DCOM argument... Too much overhead and you need to learn this model. CORBA isn't implemented with all platforms. DCOM isn't implemented with all platforms... Neither is SOAP, but it looks like you can just write some quick perl script and shove it on the web server.
Uhm. I just woke up so my thoughts are lost... that's all i have.
From the SOAP specification:
When carrying out an invocation, a SOAP client must first try the invocation using the M-POST invocation style.
...snip...
a) If using the M-POST verb, a mandatory extension declaration must be present that refers to the namespace "http://www.microsoft.com/protocols/ext/SOAP". For the purposes of this section, suppose that said declaration chooses to map the namespace to the header-prefix "01". If the POST verb is used, the namespace header-prefix is not used. For example, a MethodName header would have an M-POST value of "01-MethodName" and a POST value of "MethodName".
I guess this is microsoft's way of making sure they stay in the distributed object game for a while.
correct link
I don't know much about this, but i have seen info when i was researching XML.
Here are some icky MS links:
Microsoft's XML page has some stuff about this soap thing, and they actually say that they want people to use XML as a standard format for data (not a Office2000 format of some sort instead??)
Their SOAP explanation is here.
Juln
a while will you all? YEESH
...need a name tho ;) SOAPY sounds cool.
SOAP like XMLRPC are both very interesting and promising efforts to standardise RPC. Microsoft no doubt would have developed SOAP anyway - DCOM is far more successful than CORBA is in the world - and Microsoft isn't threatended by either CORBA or Java RMI. I think Microsoft is just trying to give the "XML touch" to everything they do now in the same way they did with the internet.
That's microsoft's brilliantness, they can quickly adopt a technology or idea (usually they haven't developed it) and then start thinking of new interesting ways of using it - QUICKLY implementing these ideas.
Personally, I've read thru the somewhat brief SOAP spec, and it looks ok, but I like XMLRPC better, XMLRPC seems a bit simplistic at the moment tho. I think I'm going to write my own one for Java
Everyone here seems to treat Microsoft like it's one single entity. Well, you know, MS is run by many individuals, no one person usually makes a decision. And all this "when did microsoft suddenly go moral" etc etc is ridiculas. They can do what ever they want, and if you choose to hate EVERYTHING they do NO MATTER WHAT then what's the use of pointing it out ALL OF THE TIME unless you want to give some reasons beyond "blah blah Microsoft evil blah blah monopoly blah blah Linux will kill Microsoft".
It's silly to think that Microsoft would want you to be able to choose something besides NT to do your serving or something besides NT or 9x to do your desktop work. They haven't ever done this -- ever. How many MS SQL servers run on Solaris? How many Exchange servers run on Irix? How many BSD machines run IIS? Even things like Word and Excel tend to be ported to MacOS with as little effort as possible... and MacOS is the only other platform.
Microsoft has most of their business exactly because vendors are locked into a single, proprietary operating system. Compatable alternatives tend to not come along easily because their ``open'' APIs are incomplete or wrong -- just ask the WINE team -- or add ``features'' which break open protocols. People who get conned into using Exchange or IIS or MS SQL are forever tied into using Microsoft products.
-- Erich
Slashdot reader since 1997
This is standard; I-D (and RFC) authors have the option to allow or not allow derivative works. Not allowing derivative works is fairly common, especially if describing a proprietarily-developed yet openly used protocol, or to establish a standard that shouldn't be changed except in approved ways; after all, that's the point of a standard.
I'm a bit concerned about performance, and also I've had problems in the past with stream i/o over http, especially when a poxy proxy gets in the way.
Intelligent use of HTTP/1.1 will fix this; proxies are now just starting to support this more fully, including chunked encoding.
The purported reason for SOAP to be a "good thing" is that it's a way of layering a messaging model atop HTTP; of course, if this was truly their interest, honesty would require admission that it is possible to layer IIOP/GIOP atop HTTP, with ILU as the most obvious manifestation of an implementation of this.
The problem with SOAP is that it pushes you back towards defining messages, rather than protocol, as IDL provides.
My suspicion is that the real purpose is to get people to build messaging systems using XML. That is not, in and of itself, a bad thing; I'd much rather see people building asynchronous messaging systems where messages are represented in XML rather than in some less-well-known format. (And, plug, plug, use Isect as the transport mechanism...)
If you're wanting to build a reliable system using that "SOAPed" XML, Wouldn't it be better to transport that XML around using MSMQ with reliability guaranteed using a TP Monitor like MTS?
How much would you want to bet that reliability of the MSFT tools would be deliberately limited so as to encourage widespread use of MSMQ/MTS?
If you're not part of the solution, you're part of the precipitate.
You bring up a good point. It's silly to try to have a "one size fits all" OS. I have to believe if MS had tried to compete on technical merit and tried to make an OS that could "play nice" with other systems that they would be more succesfull in the long run (if that's possible). They are brilliant when it comes to marketing, but they have missed the boat when it comes to the psychology of true geeks. They have built so much angst and distrust with the geeks that there is little hope of winning them over now. The *anything but Microsoft* sentiment is very strong and won't be erased by a few "good moves" my the boys in Redmond.
It's sad actually, with the amazing resoureces that MS has they really could be doing some brilliant things for the technology industry, instead they choose to waste so much effort trying to kill/block the competition.
Now, look at what MS is doing:
That has about as much chance of being "open" as the Windows API does: Sure, you may be able to read & write data (more or less, given how much of the extended HTTP standard you get), and you may be able to parse some of the tags, but MS can simple define new tags that only they understand.
I'll beleive in the promise of XML when good, well defined standards exists for defining tags, and standard tags are defined for standard things.
I'll beleive in SOAP when entropy runs backwards.
www.eFax.com are spammers
Perhaps it's my own paranoia, but I don't trust MS on this one. They see themselves as having something to gain. My guess is that it's one of two things:
1) They'll finally have a real innovation to their credit (actually they won't, but this looks more like one than anything they've had so far, so more people will be fooled).
2) Like everything else, they already have plans to Embrace and Extend their own protocol. In a way I guess this would be like the Windows hidden API's.
My guess is, it's the second. I suppose I could be simply paranoid as well, but I doubt it; Microsoft has given us no reason to trust it over the years, and plenty of very good reasons not to. So forgive me, Billy, if I take your words with not a grain of salt, but a planeload.
I'm not entirely happy with SOAP either.. but for different reasons. It seems just a smidgen more complex then XML-RPC but I don't see any significant advantage over the latter. XML-RPC works just fine for me and it's just as cross-platform.
LDO, now, is probably as good as dead wrt to being any kind of standard. It is probably more efficient and/or "better" than XML-RPC/SOAP in many ways.. but it just doesn't have the momentum or backing to make it fly. I think it's telling that the lead author of LDO is one of the most active participants on the XML-RPC lists.
Wasn't it just a year ago that we were delighted to read this quote from an internal Microsoft document:
"Generally, Microsoft wins by attacking the core weaknesses of OSS projects.
De-commoditize protocols & applications
OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market."
Sounds like this SOAP thing is just another Microsoft Trick; not a Treat...
Right: CORBA is already open!!
MS doesn't like CORBA since it's got a head of steam up, and they'd rather control anything like that. (Remember when Sun was pushing RMI instead of CORBA? They got their noodle whacked, and now are back to their indifferent CORBA support, but using RMI tools on top of it.)
I know a lot about IIOP, having done the first implementation and worked with OMG. That nasty multi-canonical stuff would be worth removing (it was an attempted compromise with the DCE/DCOM folk that fizzled). But otherwise it's not so bad as binary protols go -- easy enough to implement, but of course it's the infrastructure which most matters. SOAP would have a couple years to go before it could have the amount of infrastructure as CORBA.
If you want to do Open XML messaging over HTTP, you don't need (or want) SOAP to do it !!
There's a lot of potential with XML messaging on the web. Don't blow it by going retro with Yet Another RPC System. Adopt the model of document exchange to drive workflow. Going to the RPC world is really not forward motion.
Unlike DCOM, Corba was developed using input from many companies. Therefore it is simply better. MS wants us to belief that NT in combination with COM/DCOM is the solution to all your problems. Their marketing department has managed to spread this belief for a few years and many companies were fooled enough to start using it. In some cases it worked, in some it didn't. A few months ago I read somewhere that despite what MS wants us to believe, NT is mainly used in small scale companies to do simple stuff like email and databases for small departments. Don't misunderstand me this is not a small market but it is nowhere near the great stuff MS wants people to belief NT is capable of.
Windows 2000 has the smell of failure all around it. Endless delays, features nobody is asking for, features that already exist in other products. Really if you need directory thingies, you're problably using netware already. If you really need RPC, CORBA has been around for years. Most companies that actually need these features have already found them in non MS products.
MS's marketing department has clearly lost its touch with reality. The much hyped MS DNA has died within months of its introduction. Nobody bought it. This new thing (SOAP they call it LOL, I mean are they serious or what???) will burst also. XML and Java are both past the hype stage now, so people will no longer blindly buy anything that be associated with either of these terms.
Untill a year ago or so MS was always one step ahead of their competition. They killed netscape by creating explorer, they killed os/2 with succesfull marketing and windows 95. They killed wordperfect wit office. But they failed to kill Java, they saw no other choice but to embrace XML and didn't even bother to provide a propietary alternative. Their proprietary HTML extensions are going nowhere because most people want their pages to be readable in non MS browsers as well. EJB and CORBA is eating their lunch in the ecommerce department. Linux is eating their lunch in the small department server market (so far their only market for NT). SUN is giving away star office for free, this has to hurt in ms office revenues.
So are they going to die?? Of course not! Their shareholders will eventually stop them and get them back to what they were once good at: reinventing and marketing the wheel. MS shouldn't bother inventing new stuff nobody asked for because they are pretty lousy at it.
MS DNA and MS SOAP bubble only show they are getting nervous. Both things will go away (pretty soon) and will be replaced with other stuff. Windows 2000 will be the turning point. Shareholders will be pretty pissed of when they find out companies refuse to convert to w2k. This combined with the unavoidable DOJ case output will cause some serious change within MS.
Their traditional markets (operating systems/office ware) are eroding because there are increasingly succesful, free alternatives. In the end there won't be enough profit margin in creating operating systems and word processors This is something they noticed (hence their activity in the ecommerce and internet market), so they are trying to find new markets.
Jilles
MS's marketing department has clearly lost its touch with reality.
You say this as if there were marketing departments that haven't...
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Considering what happened with style sheets:
Microsoft appears to hold a patent on them, and this was only found out after W3.org adopted them as a internet standard. (W3.org statement)
If you excuse the pun, I have a sinking feeling about the possibility of a submarine patent on any "open" standard Microsoft suggest.
--
Exigo spamos et dona ferentes
http://www.xmlrpc.com/discuss/msgReader$555
An eye-opener to say the least.
I don't know what Lee is talking about when he says "[SOAP] does have some proprietary software code". SOAP is just a simple protocol that uses HTTP to transmit XML in a traditional RPC-like request/response pattern.
Lee's statement about folks grudginly using CORBA because it's tricky - I've heard exactly the opposite from friends using it. I wish folks would stop adding fuel to the object war fires.
M-POST isn't just an MS thing. Check out the spec at the W3C. H. Frystyk Nielsen (W3C) is the lead author. Both he and Paul Leach (of MS) were on the HTTP 1.1 spec as well.
It might actually make sense to use SOAP as a new transport mechanism with CORBA. Coders would get to keep their language bindings and their existing code base, and CORBA would get a more or less standard way to travel over HTTP (which is the whole point of the SOAP excercise. HTTP means that every firewall will understand it)
Agreed. SOAP is intentionally simple and as nonobtrusive as possible. I'd like to be able to make SOAP calls to objects whose runtime is CORBA, Java, COM, Perl, etc., from any CORBA, Java, COM, Perl, etc. runtime. SOAP is so much simpler than DCOM, IIOP, JRMI, etc., and it really just codifies the existing practice of transmitting XML over HTTP, which lots of folks are already doing. If folks are going to ignore it just because some MS guys are on the spec, then I think that's rather sad.
As for M-POST, if you check out the spec I linked to above, you'll see that it provides a sane way for firewalls to filter based on HTTP headers. SOAP uses M-POST to be firewall friendly (it's easy to block all SOAP requests, or just certain ones depending on its endpoints or the logical type of the request; i.e., the interface or method name).
I don't know a lot about XML....
... but, if MS manages to use this to kill the other protocols (I know thats not their announced intention), how long would things remain open?
How long to MS build Lock in code into the SOAP spec?
Years and years of MS have just built up too much suspicion for me to be impressed by announcements like this.
See ya
Dan
Not that this is an unusual practice. Just that I find your claim that every project at MS is independant is a fallacy.
Here's an interesting thought (and perhaps not related to the post, just in general): Even if one corporation isn't managed by a single person making most of the decisions, is there a certain ``mentality'' that will steer everyone in a similar direction? Do general MS employees make decisions that would usually fit in with commands from higher-ups? Can we generalize this to other big companies? Is there an (Oracle|IBM|Sun|SGI) ``mindset''?
-- Erich
Slashdot reader since 1997
I'm not happy with SOAP.
- It's too much RPC and not enough distributed objects. They support the concept of session/transaction IDs, (although these seem nicely spoofable). But the persistence model is too weak and object refs are not explicit.
- They're INCORRECT when they say that no current distributed protocols can be deployed on the current web infrastructure. IIOP tunneling over HTTP is quite simple and exists now.
SOAP is weak, but it's kinda cute and easy to implement. But Casbah LDO is better. http://casbah.org/LDO/
by MS doublespeak. If they are truely interested in getting windows programs to integrate better in a diverse environment, they don't have to develop, from scratch, YET ANOTHER PROTOCOL!
They are admitting that DCOM is not the smashing success they anticipated. They also feel that CORBA is too complex. If MS were truely interested in better integration, they should just comp up with the MSORB, slap some visual tools with wizards on it and presto, folks that already use CORBA will not have to trash their existing infrastructure, and the world will not have to decide between an open standard which benefits from 10 years of development vs. some new drivel from MS which is close to, but not like whats out there. At least it has a catchy name.
In the end, they are not interested in helping the world with better tools, only in decomoditizing existing protocols. How much you wanna bet that while SOAP may be used on any platform, it only really works well on MS platforms...
Interestingly enough, a lot of the SOAP development happened outside of Microsoft. Don Box of Developmentor is listed as the lead author on the RFC. Dave Winer has been involved as well: XMLRPC is based on an early draft of the SOAP spec. The most comprehensive information currently available on SOAP can be found at http://www.develop.com/soap/. There's a Perl-based implementation that runs under both NT/IIS and Linux/Apache. This stuff is great -- check it out!
The difference between theory and practice is that, in theory, there is no difference between theory and practice.
The C|Net article nails it when they say that Microsoft has spent a lot of effort making component programming relatively painless. Until UNIX and most of the programming tools embrace component technology, the natural result of standardizing on any technology that Microsoft proposes or can utilize will be that Windows coders will make very wide use of it while only really large UNIX projects will make use of it.
Also, don't confuse this with an alternative to DCOM. DCOM is multi-protocol capable. Microsoft's own explanation of SOAP gets this mixed up, claiming DCOM is a protocol! Eventually, like the multi-protocol capability of Windows, that fact will become irrelevant as TCP/IP and XML become the only protocols actually used. Subsequently, the lines may begin to blur and COM (DCOM is just COM that actually uses RPC) may come to rely on XML, use LDAP instead of OXID resolver, etc. Then, in a next-gen component technology that further blurs the lines between components and native objects in a particular language, you get a Java-oid C++ derivative that is totally dependent on SOAP and its friends. Neat. (And I predict the next shoe to fall will be an open Internet-oriented virtual machine.)
Don't, also, mistake SOAP as a replacement for CORBA. Generally, all distributed component technologies are built on RPC technologies. SOAP is an RPC technology that uses XML.
The SOAP approach does have some interesting aspects: If all the distributed component/object technology implementations could agree on SOAP as an underlying protocol, the need for the clumsy COM-to-CORBA gateway approach to interoperation would go away. Java servlets could easily talk to Windows controls. Microsoft is clearly betting they have the weight to dominate without any mechanism to impose a single higher-level component technology.
What this points out is that, for all the flaws in Windows, component technology does matter, and Windows makes good use of it. Can Linux, or any UNIX, adapt to this challenge? Or is a different approach needed? If I were Steve Jobs I would either adopt SOAP, or find an alternative ASAP, otherwise OS X will not impress among the crowd for whom component technology matters. Adopting SOAP could make the Objective C distributed object technology a player. Furthermore, SOAP opens a new way for Apple's OS X to distinguish itself from other UNIXs.
This will get more and more interesting. If you ask any Microsoft product or program manager "What are you going to do about..." any topic whatever, the answer is likely to be "XML."
I wrote parts of this stuff
> Everytime Microsoft is mentioned i see "FUD" used to the point of being rediculous...
Yeah, won't it be nice when Micorsoft gives up the FUD campaign and we won't need to take the time to debunk it anymore? But 'til then, we have a responsibility to the world's consumers.
--
It's October 6th. Where's W2K? Over the horizon again, eh?
Sheesh, evil *and* a jerk. -- Jade
It's funny how quick MS is to want open standards when they are losing a battle. This reminds me of the whole instant message war. MS, like Sun, AOL, AT&T, and others, want to control the way things are done. From the language we code in (Sun's Java) to the environment we develop for (MS's Win32 API), to the way we communicate (Instant Messeges) to how are data is transfered (AT&T's Cable Lines). MS proved a long time ago how powerful and profitable this control can be and everyone knows it. This leads to the companies that do not have the control screaming for open standards while they quietly protect the proprietary monopolies that they do have.
-- soldack
Thanks for spanking the person who doesn't know sh*t about XML and probably does not even know what a DTD is.
You are very right that Microsoft does not control XML. But it is extremely irksome that XML (in its SGML incarnation) has been around and been used for over ten years now, and only when MS jumps on the bandwagon does the media and the world stand up and take notice (and that same media often proceeds to mis-attribute XML as MS's invention, AS IF!! poor Charles Goldfarb and the people who slaved over ISO 8879 and all the rest of us have the right to be pissed about this).
like a good idea. That is, if M$ can actually let it be an open protocol and not try to dominate it with anything proprietary. This does sort of remind me of when IE4 came out a while back. They tried to make all interfaces HTML (at least their own brand of HTML) which would have worked if it hand't needed a Pentium IV 1200mhz processor to run correctly. Correct me if I'm wrong but they want to make new components for programs out of XML so they basically make their OS and programs XML readers and interpreters that just talk to each other over HTTP? That to me sounds like a reworked idea of Active X controls, which had they been really open and used a public API might have been cool. I'll withhold judgement until I see an actual product that uses it.
I'm a loner Dottie, a Rebel.
First: the title of this /. item is misleading:
CORBA is already open.
I've written my own CORBA implementation in perl using only the freely available documentation from the OMG (see COPE).
Second: about XML and remote procedure/method calls.
From the MS SOAP specification it looks like the scope of SOAP is far more limited than that of CORBA. The same can be said of Dave Winer's XML RPC (I forgot the exact name).
The difference is that the XML-based specifications only tell you how to make a method call. What they don't tell you are things like
CORBA uses IDL to write the contracts. Or you can use an Interface Repository.
The embrace-and-extend angle.
I noticed that MS felt the need to implement a new HTTP method called M-POST. So even though from a distance everything looks standard (XML, HTTP), a closer look reveals thta for best results people should use web servers, client libraries, proxy-servers and firewalls that are all taught to properly handle M-POST.
Conclusion
It might actually make sense to use SOAP as a new transport mechanism with CORBA. Coders would get to keep their language bindings and their existing code base, and CORBA would get a more or less standard way to travel over HTTP (which is the whole point of the SOAP excercise. HTTP means that every firewall will understand it)
Yikes! Is it me? I read the bit about an addition to HTTP (thinking "hey hey HEY WHOA run that by me again please?"), and I was wondering exactly how incompatible this would be with existing Web software (does this relate to the client at all? All those old netscapes out there, made useless?) and then it hit me...
Isn't the gag that you're supposed to not drop the soap in the showers because of what would happen to you when you bend over to "pick up the SOAP"?
Is that an accident or are these guys really that cynical? Are they actually considering 'secondary' embrace and extend effects to existing stuff like HTTP to be primary, is the primary agenda here to, you know? "Wups! Looks like it might be a good idea for you to PICK UP THE SOAP!" *plook*
Certainly that's what they are trying to do to the government and DoJ funding, but are they really thinking like this at all levels, so much that it colors their product names and makes anal rape their personal metaphor for the embrace and extend planning? Why are they not being more careful about this potential public relations disaster?
DCOM is far more successful than CORBA is in the world
Stats I have seen (but have no pointers to) say CORBA is twice as popular as DCOM.
Microsoft isn't threatended by either CORBA or Java RMI
Regardless of what you profess to believe, M$ acts as if threatened by everything they don't own. That's all that counts. Your perceptions of what threatens them is insignificant.
--
Infuriate left and right
Here are my quips:
What is meant by "programming model"? Do you mean programming language? That would be feasible; CORBA already does this. But if you mean "programming model" in the more general sense, i.e. architecture, such as remote invocation, remote objects, publish and subscribe, etc. (in other words, the part that really matters), then this statement is pure fantasy.
This sentence contradicts itself. How are Microsoft plans to establish their own invention as a standard not an attempt to steer the software development business? That is exactly what they are doing.
First, using SOAP is choosing a model; the SOAP model. Second, SOAP itself might not be best suited to solving the problem at hand.
Gee I wonder why. Most companies have to survive in a market where multiple competing standards exist and must be interfaced with. No reasonable engineer wants to use multiple mechanisms that do the same thing. SOAP will just be added to the mix, not eliminate it.
This already exists; it's called CORBA.
This is the most misinformed statement of all. CORBA is a specification from a standards body. It specifies an architecture, not an implementation. CORBA specifies no communications protocol other than IOP (interoperability protocols such as GIOP, IIOP, etc.). CORBA runs over whatever protocols the ORB implementers choose, in fact most use RPC as a foundation. There is absolutely nothing proprietary about CORBA.
Straight from the mouth of marketing. XML is a grammar. How does is magically make all programming "models" compatible? It's like saying if we always communicate using English, systems will magically be interoperable. For example, you have a credit-card billing system and I am going to send you the account information for a purchase that I want you to charge. Ready? Here comes the data in our compatible English interface..."The quick brown fox jumps over the lazy sleeping dog". Got it? Now you can just charge that account, right?
Right, so Microsoft can be the sole definer of SOAP. Isn't this the definition of proprietary?
Wait a minute? I thought that XML magically made all business systems compatible?!?
Then you (Smith) must be deaf. How about visiting IBM's web site, or Sun's, or any of the other thousands. You just might find something called CORBA.
Arc
if this is the metaphoric dropping of the SOAP, who's the silly bastard that's gonna pick it up??