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?"
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.
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
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/
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
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?