Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Microsoft Proposes "Open" Replacement for CORBA 148

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?"
This discussion has been archived. No new comments can be posted.

Microsoft Proposes "Open" Replacement for CORBA

Comments Filter:

  • With regard to the last sentence... I think you are saying that every firewall lets HTTP through. But that means firewalls add no value to these sorts of things.

    It's a shame that everything in the world is getting tunneled through HTTP for this reason.
  • I was just recently at Internet World 1999 and my impression is that Microsoft is indeed threatened by Java/Corba. Most successful e-business/e-commerce solutions run on *nix using Java servlets, Corba and XML. Any vendor that is out to make money for himself (and most are) choose non-MS solutions. They are more reliable, extendible, and don't lock you into waiting for MS to provide you "additional" features or standards.

    The interesting thing about MS is that they adopt standards or features quickly in order to capture market share, not to provide the developer with the best tools quickly. They want to get their solution to you before you have a chance to realize their are better ones out there. How is that brilliant? It's just business.

    And MS is about to take a pounding. They're missing the next wave just like they missed the entire concept of the Internet.

    Anyone can choose to not use Microsoft for any reason they see fit. Not using "Microsoft logic" to base IT decisions is NOT a criteria for being a Linux zealot. It's just business.

    On a side note, it was really cool to see how popular Linux and other *nix solutions are remaining.

    I'm here to tell you guys, *nix isn't dead and won't be for a long time. And a lot of *nix will still run the Internet for a long time.

    From talking to many vendors, it obvious that any large scale web sites such as Excite have moved away from NT boxes to Unix (Solaris in this case for ChiliASP). The NT solution are just not as scalable as *nix solutions at the same cost.

    How's this for a business justification: Excite moved from 100+ NT boxes to 4 4-CPU Solaris boxes running ChiliASP. No more reboots, no more lock ups.

  • 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.

  • 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.

    I see two major technical advantages to SOAP.

    1. It spec's a set of HTTP headers to make it more firewall friendly.
    2. It easily supports multi-reference data/cyclic data.
    The latter is important for supporting serialized Java object graphs (I leverage the hell out of it right now).

    http://www.develop.com/soap/soapfaq.xml [develop.com]

  • And just what is the nature of the M$ code?
    Sun's Lee said while SOAP supports XML and HTTP, the protocol, as it stands, does have some proprietary software code because it was developed mostly by Microsoft.

    SOAP doesn't rely on any proprietary technology. The SOAP/Perl bits run on Linux/Apache with no black magic from M$. The Java bits also don't require any M$ software. Sun's Lee is obviously misinformed.


  • SOAP (nor XML-RPC) will not scale as well as
    IIOP used by Corba, simply because it's human
    readable. It consumes more bandwidth and is
    much more difficult to parse. I agree that It's nice for toy appliacations.

    The argument that port 80 is already open on most firewalls, is really silly. If everybody does some
    kind of RPC over it, soon there will be closed to not allow arbitrary calls.
  • Iona joins RW/Neuveau and is supporting SOAP.
    Here's the link: http://www.iona-iportal.com/news/prsui te.htm [iona-iportal.com]
  • SOAP (nor XML-RPC) will not scale as well as IIOP used by Corba, simply because it's human readable. It consumes more bandwidth and is much more difficult to parse. I agree that It's nice for toy appliacations.

    It may be true that human readable protocols and data formats are less efficient, but this has not been a problem in the past. The major advantage of HTML (and XML) over document formats with control characters or other binary stuff is that it is human readable, or, more importantly, editable with simple easily available tools. The human readable internet protocols - SMTP, FTP, HTTP - have been a success, I am not sure I could name a protocol with binary control information that has spread in the same way.

    The trouble with SOAP is that, despite its name, it is not an Object access protocol. One of the 'non-goals' is 'Objects-by-reference'; this means you cannot pass the ability to interact with a specific object instance (except perhaps by some application invented add-on). This was the feature that made CORBA so much more than just another RPC. It is also the feature that is responsible for most of the problems with firewalls.

    The argument that port 80 is already open on most firewalls, is really silly. If everybody does some kind of RPC over it, soon there will be closed to not allow arbitrary calls.

    I just dont believe that port 80 is open on most firewalls. In low risk environments it may be permitted to make direct outgoing connections (I used to work for a company that had its packet filters set up like that - it is probably too dangerous now). Anyone who allows direct outgoing connections it probably allowing more than just port 80. It is much more usual to have to go via a SOCKS proxy or an application level web proxy - these are not at all like having port 80 open.

    Every firewall configuration I have seen is much more restrictive in incoming connections. The textbook examples allow incoming connections only to specific bastion hosts, and these are often on a perimiter net separate from the main internal network. Having port 80 open to the host that runs the external web server is usually all you get. Anyone doing something dynamic involving live data that is on the internal network has some kind of proxy on the bastion host, perhaps integrated with the web server. If you can put the proxy in place, you are the one who can open up some other port if there is any benefit in doing so; using port 80 in this context is just irrelevant.

    I fear that SOAP will succeed by being buzzword compliant. I fear because it is as short-sighted as adopting an OS that has 8.3 filenames, with directories as an afterthought so you have to use '\' because you have already used '/' for something else. It may be adequate for now, but we will regret it when we move on to the harder problems.

    The saddest thing is that several of the the ORB vendors deserve this problem. Their customers told them to get out of the immature proprietary phase but they chose not to.

  • "The Fortune 1,000 prefers CORBA 2-to-1 over COM"-- Forrester Research, July 1999, "Internet Middleware", by Eric G. Brown (ebrown@forrester.com), Ted Schadler, Amanda J. Ciardelli, Ben Worthen, Stephanie Smith

    Wanna see more, buy the report. Now where's your proof?
  • I scratched my head when I read this and wondered what all the fuss was about. Its seems to be just another bunch of silliness written by people that don't really understand the underlying technology.

    1. Why is it a threat to Java - or any other programming language for that matter ? This is a protocol for passing objects by value (come on CORBA3 - hello RMI :-) and implementing method calling protocols.

    2. Using XML in this way is hardly novel. There must be 101 projects out there that are doing exactly the same thing. It would be nice if there was a single mechanism though.

    3. "Firewalls don't allow arbitrary ports to be open for the average distributed object protocol" (paraphrased from the MS SOAP site). Well there's a damn good reason for that. It makes your server terribly insecure. Allowing arbitrary method calls to be made over HTTP just expands the problem enormously. This is the distributed object equivalent of MACRO languages. Before widespread use of MACROS we only really had to worry about binary viruses and worms - which were tricky to write but sort of detectable. With the advent of MACROs everywhere the virus problem is ten times worse than it was before - and allowing arbitrary method calls over HTTP is just doing the same thing.

    4. Why are CORBA and DCOM complicated ? Well at their core they're pretty simple. They define an interface definition language which is a subset of most common procedural declaration syntaxes. This allows the definition of complex object interactions to be defined without reference to a particular language. However the complexity of CORBA and DCOM comes in the peripheral definitions it was realised had to be made in order to make them useful. i.e. they define a suite of services - Object resolution, Events, Transactions, Security etc, etc, which are non-trivial pieces of software. This is exacerbated by the fact that the OMG hasn't provided reference implementations and that CORBA was interpretable 100 different ways. Object interaction - methinks not.

    Anyway I guess the final point is CORBA (and probably DCOM - but its such a hybrid bastard that its hard to tell) started out life as really simple ideas. Probably even simpler than SOAP or any similar projects. The problem is, their actual problem domain is huge, encompassing most of the computing industry and its exactly this sort of half-baked "Oh look we solved all the world's ills" thinking that led to 'products' like COM and the huge shambling mess that is CORBA (read DCOM here too).

    The rather strange thing is, by getting something like SOAP ratified as an Open Standard MS probably has the greatest chance of this thing stalling and never seeing the light of day. By the time 20 or 30 companies start squabbling over minor details this will all disappear in a puff of smoke.
  • > It's a shame that everything in the world is getting tunneled through HTTP

    A very large Amen! to that.

    I love SOAP, and the whole XML-RPC concept. I've been using it for a month, and it's giving a lightweight protocol for shoving simple well-structured data around an Extranet. Yes, I've done DCOM, I even know a little about CORBA. Neither of these would have given me the ease of setup (especially at the client's site, and behind the client's firewall) that I get with XML-RPC (my strict SOAP compliance is ragged).

    If I was doing SOAP right now, I'd be doing pure http and using URLs that put BroadVision [peterme.com] to shame.

    Yes, tunnelling everything through http to get past the firewall is bad juju. When we start seeing commonplace SOAPservers that are worth subverting, then it really will be time to worry about it. Anyone for challenge-response firewall tunnels opened on the basis of certificates in the SOAP header elements ? I currently have an open SOAPserver that would attempt to ship you a bucketful of valuable product, in response to a trivially formatted SOAP request (Don't try it - there's also a human reading the orders). To regain the security benefit of reliable firewalls (reliably culling the nasties below the application level), then we'll start needing techniques like this as standard. After all, no-one needs (sic) a firewall today, as all our machines are secured anyway...

    OTOH - No way would I be pushing DCOM around a big LAN, let alone across the 'Net at large. No F'ing way, not after the continual shafting from Teardrop/NewTear that my ports took back in the Service Pack 3 days.

  • With industrial strenghth ORBs like ACE and MICO out that run and well at that under NT- do we need another "standard" that MS propagates? Will they keep it open or as they extend it to their own ends, will they pervert it so that you really have to use MS tools to do SOAP development right?

    MS just doesn't get it do they?
  • Unlike DCOM, Corba was developed using input from many companies. Therefore it is simply better

    I differ. CORBA was developed by a ton of companies who each wanted their "very important features" to be in there. It is therefore an unnecessarily bulky and complicated standard. DCOM has the advantage of being developed by one company and didn't have that problem. Of course, CORBA has the advantage of working with multiple vendors, but it is certainly not better because it was developed by many companies.

  • 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 years of watching them move in on:
    • travel booking
    • journalism
    • banking
    • e-business
    • entertainment
    • the fscking _navy_...
    ...what gives you the idea that, given uncontested control of computer desktops, they'd stop there?
  • It seems like it may be a reasonable protocol, we should judge it on its merits.
    This worries me: "This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted." Whats the point of a RFC without this? I dont suppose theres much chance of getting em to change their minds :/
    It being completely based on http-post, and an xml dataformat is, well, odd. It kinda seems innovative, but we could do all this stuff anyway. Being based on http is very good on the implementation process, firewalls already understand it etc.
    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.
    So far its hardly a replacement for corba though, imo.
  • by StupidEngineer ( 102134 ) on Saturday October 16, 1999 @05:43AM (#1609394)
    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.


    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.

  • I don't understand your title, but I agree that this SOAP stuff is first rate work.
    In the new movie "Fight Club", the Brad Pitt character's family got its wealth from selling a high-priced brand of soap. (The soap is made using a "special process" that turns out to be pretty gross.) The movie's logo is the words "Fight Club" embossed on a bar of soap.
  • At first I almost thought this was a joke because of the stupid acronym...

    CORBA is already open and very flexible and proven. The latest version of the spec integrates with Enterprise Java Beans. What more could anyone want? Add RMI and Java into the scene and a proprietary distributed architecture from Microsoft is totally unnecessary.

    let's hope SOAP goes the way of COOL...
  • You are right. SOAP is only based on the least scalable protocol there is--the text based, and verbose HTTP/HTML. It will never fly.

    There is a much more efficient protocol (from the early 1980's) which is binary--video text. The French us it on there MINITEL system. The protocol really great for MINITEL as it is limited to 1200 baud!!

    Long live binary protocols and bit counting. Gee guys, I though we stopped programming in assembly code a few years ago.

  • correct link [cnet.com]
  • 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 [microsoft.com] 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 [microsoft.com] is here.
  • by Anonymous Coward on Saturday October 16, 1999 @03:49AM (#1609408)
    a while will you all? YEESH

    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 ...need a name tho ;) SOAPY sounds cool.

    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".
  • by Erich ( 151 ) on Saturday October 16, 1999 @03:53AM (#1609409) Homepage Journal
    Since when has Microsoft been interested in locking vendors into a single platform? Since when have Nuns been Catholic?

    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.

  • Office 2000 already saves as XML (except ACCESS)
  • This worries me: "This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted." Whats the point of a RFC without this? I dont suppose theres much chance of getting em to change their minds

    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.

  • A lot of the comments on this page are MS stooges astroturfing!!!

    Notice how as an aside to a valid argument, they'll introducing FUD and/or straight Crapola - such as DCOM is more popular than CORBA

    I haven't seen anybody post here that DCOM is more popular than CORBA. Certainly, idiots at Microsoft make ridiculuous statements all the time, but some of us don't think that every technology coming from Redmond is crap by default. In fact, I *gasp* even *like* some of their products.

    Statements about COM vs CORBA seem particularly prone to mindless boosterism. Both of these attempt to solve the problem of component design in different ways; both are successful; neither enjoys any particular advantage over the other, other than the cross-platform-ness of CORBA and the tight system integration of COM on Windows. Anybody who tells you otherwise is either technically ignorant, has an axe to grind, or both.

    If the design of COM is so bad (as I've seen claimed here many times), then why did Mozilla/Netscape base XPCOM on the exact same model?

  • It's entertaining enough to see that they're promoting Yet Another Protocol that will, of course, mandate, on top of this, Yet Another API.

    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 [xerox.com] 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. [hex.net] 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 [netcom.com] 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 [hex.net] 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?

  • >>1> Office 2000 saves html documents(save as web page or some such option) in a broken XML format, support for which is available only in IE 5.

    Basically yes.

    >>2> The page cannot be displayed at all w/ netscape.

    Basically no. The files open just fine in Netscape. You can read all the content. You don't get all the fancy stuff though.
  • 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.
  • M-POST is not a *new* method; it's proposed in the HTT P Extension Framework [w3.org], which is only an I-D now, not a standard (so it shouldn't technically be referred to here, but this is the real world). This draft is about to be reviewed by the IESG AFAIK, and is written by Frystyk Nielsen, so it's a pretty fair guess that it'll be a standard soon enough.

    I agree that it's a shame that HTTP is used in this way, but it speaks more about the fallacies and shortcomings of people's current security models than it does about anything else. This is actually pretty tame.

  • This is completely normal - read http://www.w3.org/Protocols/HTTP/ietf-http-ext/dra ft-frystyk-http-extensions-03
  • While there are plenty of legitimate reasons to not allow derivative works, this can only make me wonder if Microsoft is attempting to insulate themselves from the type of thing that they do on an almost daily basis. In the past they've added either "special extensions" or created a proprietary standard out of a commonly used format out of HTML and XML.
    My first thought when I heard they had introduced a standard was that this would be a prime time to do the same back to them, but they've apparently thought of that.
  • in the way FTP, HTTP, or HTML are. Allow me an analogy: C++ defines a language, but by the time you define a few macros, some overloaded operators, and a few new libraries, you can generate a language that is completely different from stock C++. In the same way, all XML does is give you a framework to define your tags in. If I define a tag &lt Unit Price &gt, and you define the same meaning as &lt Price per unit &gt, then we have an incompatability.

    Now, look at what MS is doing:

    1. "Extend" the HTTP standard
    2. Use XML, so they can define their own tags willy-nilly.

    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.

  • > Stats I have seen (but have no pointers to) say CORBA is twice as popular as DCOM.

    Surely, all telco companies use CORBA-based distributed systems. AFAIK, the rare times a DCOM interface is offered in these circumnstaces is just a 'plus'.

    And then, there is already a standard protocol (IOOP) and a standard encapsulation in http (IOOP on HTTP).
  • 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.
  • you haven't looked very hard then. The comment was rebutted very quickly, but it is here

    One post hardly equals "a lot of the comments" that were claimed by the original AC (who may or may not be you).

    It's fairly standard Astroturfing.

    The author of the referenced comment may not have his facts correct. This does not immediately qualify him as an undercover Microsoft employee. Dismissing someone's opinion by claiming that it was paid for by a third party is insulting and offensive, unless you have the kind of evidence that seems to exist in the Gartner Group example. It certainly adds nothing to the dialog. *Not*, mind you, that I expect anything better from an anonymous coward.

    The design of Netscape is also commonly regarded as bad. Mozilla isn't much better - check out www.mnemonic.org for a well thought-out browser design.

    Be that as it may, if there was ever a software company motivated to *not* use MS technology out of strictly ideological reasons, it was Netscape. Presumably, the XPCOM design was chosen because it made at least *some* technical sense. Your comment says nothing to refute my claim that in terms of technological superiority, COM vs CORBA is basically a wash.

  • 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 [opensource.org] quote from an internal Microsoft [microsoft.com] 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 [microsoft.com] thing is just another Microsoft Trick; not a Treat...

  • 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?

    If you're wanting to build a reliable system using that "SOAPed" XML, wouldn't it be better to transport that XML around using MQSeries with reliability guaranteed using a TP Monitor like Tuxedo?

    If you're wanting to build a reliable system using that "SOAPed" XML, wouldn't it be better to transport that XML around using Java Message Queue with reliability guaranteed using Enterprise Java Beans?

    If SOAP makes sense (which I feel it does), then it will have broad vendor and developer support. If SOAP does not make sense, then only MS will implement support for it and you'd have to be an idiot not to expect to be locked into MS tools. (Nobody buys into VB development thinking they may someday be able to buy tools from Sun.)

  • by Anonymous Coward
    Listen, I hate Microsoft as much as the next guy, but the attittude on Slashdot borders on the ridiculous. If anything has a hint of MS in it, you guys assume it's bad. As someone who has previously implemented XML-RPC and used it to connect computers together, I can say after looking extensively at SOAP that it's a _good_ thing; it's better thought out than XML-RPC, but still pretty easy to implement. There's nothing proprietary about it. It's been submitted as an internet draft, and is completely open. The M-POST stuff is there for firewalls, so that firewalls can have better control of content that goes through them (e.g. a firewall administrator may want to allow normal POSTs, but not M-POSTs, which would only be used for RPC. Anyways, it's not strictly needed, if it's not there, the protocol will still work. Nobody is defining XML tags 'willy-nilly' here. There is a standard DTD which defines a set of tags to implement an RPC style protocol which is serialized as XML. What's the problem with that?
  • The real question is, does MS really need another distributed object specification? Chances are, the microsoft implementation model will be built on top of COM/COM+.
    I was employed for 2 months over my summer researching MS's COM so I could teach the company programmers what it was all about. Along the way, I attended a couple of talks by Inside COM+'s author (Mr Platt). From what I've seen, COM+ is a great specification - if 1) it wasn't changed every 2 months, and 2) if what is promised can be delivered.
    Now, I'm not blind to the fact that the proposed SOAP is an Open standard, but, the point is that MS is going to be the first people to implement it. Because of this, I don't see many Open Source zealots rushing to implement it as well, seeing MS's track record on so-called Open standards. I'm always reminded of a quote from Inside COM - "At Microsoft, we feel we can always improve upon a standard" (this refers to the IDL, by the way).
    Ah well. Enough of my miserable drivel. Now to actually go and look at the SOAP spec ...
  • 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.

  • by pohl ( 872 )
    This is one of the things I love about slashdot. Here you have already come up with the perfect guerrilla anti-marketing soundbite: anybody who advocates this technology is 'bending over to pick up the SOAP.' *snicker*
  • 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

    I agree. If M$ was really interested in opening up the playing field, they wouldn't have to invent SOAP; they would collaborate with other players and develop a technology with features common to all. Apparently, sharing/cooperation seems to be a problem.. unless they're sharing something with you that will give them control/the edge/more $.

    How much you wanna bet that while SOAP may be used on any platform, it only really works well on MS platforms...

    I'd be willing to bet you're right on this one. Either that, and you're stuck with a POC, or.. they'll charge you some nice $ for a "service pack".
  • 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.
  • Now I'm really pissed! How can a news organization get away with misleading the un-technical world this way? Quote of two adjacent paragraphs in artical: "The benefit to Microsoft? The company is hoping that greater compatibility between Windows-based software and Java and Unix-based systems could lead to greater adoption of Windows 2000, the company's forthcoming operating system. SOAP, in effect, could be bad news for Sun, IBM, Oracle, and other Java backers since it could nullify the effectiveness of proprietary "lock-in" marketing strategies."
  • Yes. And on average we are not taught to seek and understand the points of view of others. The automatic tendency is to defend the point of view that one has come to have already.

    And due to the inability of computers to interact in anything but strictly defined ways, the computing world has become an Either/Or battle. But I think we are at a turning point, and that in the future any systems that cannot inter-operate into a greater whole will be annexed off the main evolutionary path.

    MS has defeated much competition, but this was competition on a particular level. The next level is about integrating, so only those systems that can "increase their depth" to reach the next level will survive, and dominate. (???)
  • Yes, I agree with you there. I too found myself saying "What the f***" when I heard that the Navy was using NT, and I'm not even an American. What I'm alluding to is a historical Chinese idea, regarding how do deal with invaders. It goes like this: Put up no resistance, allow them to come in, and settle. The invading army then take up residence, marry locals, join local families, and have children. And after a generation or two, the "invaders" have been "assimilated". End of story. Mind you China is very big, so assimilation may work better there. The sheer mass of the people. I don't mean the oppressive Government system, as they seem to use "education" as their weapon.
  • Um, have you ever read one?
    Much of it is HTML, with XML embedded to describe word characteristics (paragraph styles etc).

    It's not very hard to understand.
  • It's kind of VERY hard to lock up SOAP since XML is human readable, it wouldn't take much of a chimp to be able to figure out what tag does what.
  • Cause not everyone in the world uses Java.
    And Java solutions like RMI only work with Java objects - and the point of SOAP and XMLRPC is that it can work with everything. (DCOM _could_ work with everything - but it's harder to understand).
  • MS's marketing department has clearly lost its touch with reality.

    You say this as if there were marketing departments that haven't...
  • It is common for implementors of internet enabled apps to need to pass messages back and forth. Since the only way past the corporate fireway is via the proxy, these apps have no choice but to overload http. Applix Anyware, among many, does this. SOAP is a standardization of this practice.

    CORBA is too heavyweight for these applications. Worse, a corba-over-http bridge must be used to get out via the proxy.

    Without SOAP implementors will keep writing custom implementations over and over again. Thus SOAP is a Good Thing because it lets us code this once and for all and move on.

  • Considering what happened with style sheets:
    Microsoft appears to hold a patent [ibm.com] on them, and this was only found out after W3.org adopted them as a internet standard. (W3.org statement [w3.org])

    If you excuse the pun, I have a sinking feeling about the possibility of a submarine patent on any "open" standard Microsoft suggest.

  • COM is fairly easy to use, DCOM is a POS.

    I used DCOM for some client/server projects and it was a disaster. I learned more about registry editing than I ever wanted to know. The projects were rewritten to use vanilla TCP sockets and all of the problems vanished.

  • of course!
  • Its a simple concept called "ride with the outlaws, die with the outlaws". I dont care if they are "moral" individuals or not. They have chosen to support the evil empire's trashing of all things not their own. They can hang right along side their boss for all I care. I won't be sending flowers.
  • >Since when has Microsoft been interested in
    >locking vendors into a single platform? Since
    >when have Nuns been Catholic?

    I actually know at least one Episcopalian nun.
    (A agree, though, most nuns are Catholic :-)

  • ...DCOM is far more successful than CORBA is in the world...

    What is this obvious FUD piece doing marked up to 4? Sure, Slashdot shouldn't be one-sided, and even pieces like this deserve to be heard one in a while, just to see the interesting rebuttals, but 4?? Go figure.
  • Dave Winer wrote his personal history of SOAP, and the beginnings of XML-RPC:

    http://www.xmlrpc.com/discuss/msgReader$555 [xmlrpc.com]

    An eye-opener to say the least.

  • Microsoft have made a major gaffe. at least here in Australia. I have already got the copyright for SOAP! http://linux.org.au/projects/SOAP/ It is pretty ugly at the moment as i havent had time to do anything past initial concept. the page went up about 3 months ago, which should be in the logs somewhere, so i beat microsoft to the name. now if enough people can get on developing this, it would be a race against MS. "harnessing colective IQ". the address to subscribe to is majordomo@lists.linux.org.au with subscribe soap in the body. We must beat Microsoft. send food code and lawyers!
  • Here are two items summarized from the strategy section of Microsoft's Halloween Memo, "released" almost exactly 1 year ago:

    * Linux can win as long as services / protocols are commodities.

    * 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.

    Microsoft's SOAPBOX... err sorry, SOUP, oops, noo I mean SOAP is exactly one of these. Are we surprised? Our response should be to ignore it, to lampoon it, to copy it in our own, truly open protocols, whatever, but not to adopt it.
  • Seriously, a lot of firms have clued in and already established CORBA as the standard. We're using it where I work, buying nice tools from IBM and Borland that all use CORBA.

    And I think people are also aware that MSFT is trying to "embrace and extend" so that they control all the cash again.

  • This remind me of a review of Ofice 2000 in PC World (India). The review made the following relevant points:
    1> Office 2000 saves html documents(save as web page or some such option) in a broken XML format, support for which is available only in IE 5.
    2> The page cannot be displayed at all w/ netscape.

    If M$ plans to use the same format for SOAP...

    Funny... the pages display perfectly fine in Opera. It's Netscape's crappy CSS/XML/XSL/DHTML implementation.

  • I was one of the first implementors of SOAP. My implementation is pure Perl and runs on Linux/Apache as well as any other platform that supports Perl - see http://www.develop.com/soap.

    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.

  • If what Dave Winer writes is true then SOAP sounds like one of the engineering-driven projects at MS as opposed to a marketing-driven project. After reading this I became fairly positive about the whole thing and I think the experimentation with XML protocols will be good overall.
  • I noticed that MS felt the need to implement a new HTTP method called M-POST

    M-POST isn't just an MS thing. Check out the spec at the W3C [w3.org]. 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 see how SOAP has anything to do with component technology. It's just a simpler RPC wire protocol than the fiercely competing alternatives (IIOP, DCOM, RMI, etc.)
  • by TummyX ( 84871 ) on Saturday October 16, 1999 @03:57AM (#1609469)

    People who get conned into using Exchange or IIS or MS SQL are forever tied into using Microsoft products.

    Not really, there are numorous tools that help you migrate both two and from microsoft solutions.
    Halcyon Software who advertise on slashdot have a pretty COOL asp solution for almost all non NT servers.
  • ah yes, I recall hearing that. Well, good for them to use an open file format - as long as they dont 'embrace and extend'.

  • 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
  • I disagree. Many projects at MS are carefully crafted to destroy the competition, and to lock the competition into using other MS products.

    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''?

  • by Squirtle ( 73289 ) on Saturday October 16, 1999 @04:08AM (#1609473) Homepage
    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/
  • Is this not very sly of M$?
    Adopting the most popular (XML) and turning it on their chosen target (CORBA)?

    So it is that good warriors take their stand on ground where they cannot lose, and do not overlook conditions that make an opponent prone to defeat. - Sun Tzu, "The Art of War"

    Can anyone confirm/deny the validity of this claim/FUD:
    But most companies use CORBA-based technologies grudgingly: the technology is difficult to master and tricky to implement.

    And just what is the nature of the M$ code?
    Sun's Lee said while SOAP supports XML and HTTP, the protocol, as it stands, does have some proprietary software code because it was developed mostly by Microsoft.

  • 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...
  • True enough. Microsoft, as a corporation, is not to be trusted at all. If it weren't for Linux and the threat it represents, we'd see Windows2000 out for release *right now* and MS would continue its practice of letting its customers debug its code for them. Would *you* run mission-critical applications on a platform that generates at least one bad security hole a month? Gates and Ballmer expect you to. Would you drive a car that stopped for no apparent reason in the middle of the highway? Would you drive one that slowed down to the point where you had to turn it off and start it again to get performance from it?
  • by Slothrup ( 73029 ) <curt AT hagenlocher DOT org> on Saturday October 16, 1999 @04:37AM (#1609478)
    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!
  • by Zigurd ( 3528 ) on Saturday October 16, 1999 @11:07AM (#1609479) Homepage
    The Forrester results regarding the use of CORBA in corporate IT projects is misleading. Almost all Windows coding involves COM, whether the coder knows it or not. I'd bet most /.ers have never needed to touch CORBA.

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

  • > 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?
  • A Technical Comparison of CORBA vs DCOM:

    http://www.research.microsoft.com/~ymwang/papers /HTML/DCOMnCORBA/S.html

    The paper concludes that they are roughly equivalent, but the diagrams indicate to me that the design of CORBA is much cleaner.

    A survey of CORBA usage vs DCOM, etc. (from 1998):

    http://www.cutter.com/consortium/architecture/co rbacom.html
  • 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.
  • The whole idea of XML is to embrace and extend. XML stands for extensible markup language. I'm glad to see that MS is embracing this.
  • WRT to who will be first to implement SOAP, I think that it was actually Keith Brown at DevelopMentor who produced a Perl implementation that runs on NT ( IIS/Apache ) and Linux ( Apache ). You can download the bits at http://www.develop.com/soap DevelopMentor also plan to provide COM and Java versions fairly shortly ( don't press me for a tighter time frame, I don't have one ). Regards Martin Gudgin DevelopMentor
  • And where is the part where objects come in?
  • That is what DTDs are for.

    I think you had better read a little about XML before you start making comments like that.

    The whole idea of XML is that it is a self describing file format. Sure, you might make mistakes like creating a new DTD before you check for an existing one, but that is your fault for begin an idiot, not the format.

    This is exactly the same as the Glade [slashdot.org] guys defineing their own DTD for a GTK user interface.

    If you really think that MS controls XML, i would advise you to get out a bit. Sure, Linux is behind the times a bit in XML support, but companies like IBM and Oracle are doing significant work in XML, now.

    Didn't you read that interview with Tim O'Riely earlier this week?

    You might want to go and have a look at IBM's XML workshop [ibm.com]

    As for M-POST, it is a good thing. It allows increased HTTP capabilties through firewalls.

    In this case, Microsoft has done a good job. You can be anti-MS all you want, but don't try posting FUD - make sure your facts are straight.

  • 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).
  • What is the big deal? SOAP is a simple and fairly intuitive way to do object messaging and data exchange across the WEB. It is perfectly useable with Java, CORBA, Python, COM or whatever else ultimately handles execution of the appropriate method on the specified object. It will not replace any of these. It is only a communication protocol. It says nothing about the many services necessary to have a true distributed object environment. Now that the proposal is out there is no way for MS to control who makes use of the basic idea.

    Also, CORBA always has been non-proprietary and OS independent.
  • As much as I hate to say it: Exactly

    But SGML was always too complex to take off in common acceptance, and the push XML needed was (I believe) more people running into the annoying limitations of HTML, and thinking wouldn't it bw nice....

    The point is XML is a good thing, and yes, it is a bit of a bandwagon, but it is a good bandwagon to be on.

    I'm not advocating that (as I have seen previously) Linux should get rid of the .rc files and go to a XML based configuration format, but I would like to see more tools on Unix that allow easy production of useful data in XML formats.

    Until then, and we blame the media for thinking XML is a Microsoft show? I can't. MS has done an excellent job of getting at least some XML support into their major app. (IE5 & "Data Island" or whatever they are called - need I say more?)

    Stuff like this should be a wake up call to the OSS community, not to moan, but to Show me the code.

  • 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.
  • The way to get rid of Microsoft is to roll over and play dead. Ever wonder what the Borg were actually going to DO once they took over the universe? I mean, they would have attained perfection, but perfection is unnatainable, so they themselves must be the imperfect...
  • by Arrowhead ( 7765 ) on Saturday October 16, 1999 @04:39AM (#1609500)

    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 [lunatech.com]).

    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

    • How to address objects (how do you find them, how does the server keep them apart, do they all have to live in a web server?)
    • How to write contracts that ensure that client and server speak on the same terms. XML is very flexible, it's easy to add a new field to your structure. But if you write your high performance server in C++ then it will need a recompile with some added code to make sense of that added field.
      CORBA uses IDL to write the contracts. Or you can use an Interface Repository.
    • How to write clients and servers portably. Does everyone take their favourite XML library and start hacking, or will there be a standard way to map the SOAP datatypes to native datatypes for all the programming languages people might use?

    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.

    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)

  • What I mean is, without anything to kill, all their force would just dissipate.

    Microsoft would just fizzle. We make the sacrifice of having 5 years of Windows EVERYWHERE, and then just watch it die.
  • Bill Gates book, or at least one of the latest ones, has a whole section of analogies comparing computers to cars. Clearly he hasn't considered what kind of Fatal Exception a fatal exception on the freeway would be! I dont think I would want a car that has to be restarted suddenly all the time (hmm..maybe he was thinking of my old Crown Vic when he said that...it was sort of like Windows)

    Thats right, the same book, I think, where he said 'The most obvious mathematical breakthrough would be the development of away to factor large prime numbers'. Factor...prime numbers. But thats off topic.
  • by Chris Johnson ( 580 ) on Saturday October 16, 1999 @04:53AM (#1609507) Homepage Journal
    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.

  • 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.

    Isn't Box the guy making money from the Microsoft gravy train every time another one of his COM books sells? Doesn't the history of XMLRPC show that they both worked closely with Microsoft engineers at Microsoft during the early development of what would be soap? To invoke these names as proof that the development happened outside Microsoft is misleading.
    The article itself is quite humorous--SOAP being a shot across the bow of Java and CORBA? Give me a break.

    First Rule of Fight Club: No one trusts Microsoft.
    Second Rule of Fight Club: No one trusts Microsoft.
  • Here is a suggestion for all technology journalists: understand--or at least research--a topic before you spin it.

    Here are my quips:

    "(SOAP)...will let business software programs communicate over the Internet, regardless of the programming model on which they're based."

    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.

    "In many ways, SOAP, and Microsoft's plans to establish it as a standard, represent a reversal of Microsoft's past attempts to steer the software development business."

    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.

    "Instead of being forced to chose one model, companies will be free to select whichever is best suited to solving the problem at hand, Microsoft reasons."

    First, using SOAP is choosing a model; the SOAP model. Second, SOAP itself might not be best suited to solving the problem at hand.

    "In practice, most companies build and run a mix of applications built using COM, Windows, CORBA, Java, and other technologies."

    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.

    "A protocol that gives companies greater freedom to link systems both internally and across the Net with other companies is expected to be welcomed warmly, said analysts."

    This already exists; it's called CORBA.

    "Currently, each programming model had its own proprietary communications protocol, so it's difficult for businesses that use EJBs and CORBA to exchange information and communicate with businesses that use COM."

    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.

    "Because SOAP is based on XML, it's compatible with all programming models and allows businesses to easily exchange data with each other over the Internet, said analyst Mike Gilpin, of Giga Information Group."

    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?

    "But Microsoft executives said they wanted to develop the basics of the technology before submitting the proposal to a standards body, where SOAP can be tweaked by other companies."

    Right, so Microsoft can be the sole definer of SOAP. Isn't this the definition of proprietary?

    "A protocol provides the guidelines to exchange information over XML. Otherwise, each business would have to discuss how to format their XML and handle interactions, he said."

    Wait a minute? I thought that XML magically made all business systems compatible?!?

    "SOAP is not the only answer, but it's the right approach. The world wants more interoperability," Smith said. "We've never solved it. And we haven't heard from any other vendors what the alternative is."

    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.


  • if this is the metaphoric dropping of the SOAP, who's the silly bastard that's gonna pick it up??

Due to lack of disk space, this fortune database has been discontinued.