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?"
Firewalls forcing HTTP (Score:1)
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.
Re:Bah, step back and stop playing Linux Zealot fo (Score:1)
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.
Re:here is more info (Score:2)
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.
Re:LDO vs XML-RPC vs SOAP (Score:1)
I see two major technical advantages to SOAP.
- It spec's a set of HTTP headers to make it more firewall friendly.
- 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).DB
http://www.develop.com/soap/soapfaq.xml [develop.com]
Re:...they cannot lose (Score:1)
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.
DB
Soap won't scale (Score:1)
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.
Another ORB vendor signs on for SOAP (Score:1)
Here's the link: http://www.iona-iportal.com/news/prsui te.htm [iona-iportal.com]
DB
Re:Soap won't scale (Score:1)
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.
Pay Forrester, see the proof... (Score:1)
Wanna see more, buy the report. Now where's your proof?
Deja vu (Score:1)
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
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.
Re:Firewalls forcing HTTP (Score:1)
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.
SOAP, as it's called, isn't needed... (Score:1)
MS just doesn't get it do they?
Re:Head in sand FUD (Score:1)
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.
Microsoft proposes the LEMON (Score:2)
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...
No they wouldn't (Score:2)
Reading thru all this... (Score:1)
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.
SOAP and K.I.S.S (Score:3)
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.
non-propietary my ass (Score:2)
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.
Re:Fight Club? (Score:1)
stupid (Score:1)
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...
Re:Soap won't scale (Score:1)
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.
csw
Re:The requested URL could not be retrieved (Score:2)
here is more info (Score:2)
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.
Bah, step back and stop playing Linux Zealot for (Score:4)
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".
Ha! (Score:4)
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.
Re:here is more info (Score:1)
Re:Reading thru all this... (Score:2)
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.
Re:Beware Astroturfing!! (Score:1)
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?
The Road to MSMQ... (Score:2)
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?
Re:XML to be used as standard. (Score:1)
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.
Re:Why don't they give up trying to kill unix (Score:2)
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.
Re:Firewalls forcing HTTP (Score:1)
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.
Re:non-propietary my ass (Score:2)
Re:Reading thru all this... (Score:1)
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.
XML isn't a "standard"... (Score:2)
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.
Re:Head in sand FUD (Score:1)
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).
I smell a rat... (Score:2)
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.
Re:Beware Astroturfing!! (Score:1)
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.
LDO vs XML-RPC vs SOAP (Score:2)
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.
Happy Halloween (Score:2)
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...
Re:The Road to MSMQ... (Score:1)
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.)
Re:XML isn't a "standard"... (Score:2)
Re:Bah, step back and stop playing Linux Zealot fo (Score:1)
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
Re:How "open" do you want it? (Score:2)
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.
hurray! (Score:1)
Re:Don't be confused (Score:1)
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".
Re:Head in sand FUD (Score:2)
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.
How can cnet get away with lying? (Score:1)
Re:Why don't they give up trying to kill unix (Score:1)
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. (???)
Re:No they wouldn't (Score:1)
Re:here is more info (Score:1)
Much of it is HTML, with XML embedded to describe word characteristics (paragraph styles etc).
It's not very hard to understand.
Re:How long would things remain open (Score:1)
Re:Java better (Score:1)
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).
Re:Head in sand FUD (Score:2)
You say this as if there were marketing departments that haven't...
SOAP just a standardization of a common practice (Score:1)
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.
Anyone for a submarine? (Score:2)
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.
--
Re:...they cannot lose (Score:1)
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.
Dave Whiner (Score:1)
Re:Bah, step back and stop playing Linux Zealot fo (Score:1)
Re:Ha! (Score:1)
>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
--Ben
Moderators, where are you? (Score:1)
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's history of SOAP and XML-RPC (Score:2)
http://www.xmlrpc.com/discuss/msgReader$555 [xmlrpc.com]
An eye-opener to say the least.
Microsoft are too late. I have it already (Score:1)
SOAP is one of those (Score:1)
* 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.
They're too late (Score:1)
And I think people are also aware that MSFT is trying to "embrace and extend" so that they control all the cash again.
Re:XML to be used as standard. (Score:1)
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.
Simon
Re:...they cannot lose (Score:2)
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.
Re:Dave Winer's history of SOAP and XML-RPC (Score:1)
Re:How "open" do you want it? (Score:2)
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).
Re:XMLEverything (Score:1)
Re:Ha! (Score:4)
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.
Re:here is more info (Score:1)
How long would things remain open (Score:2)
... 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
Re:Bah, step back and stop playing Linux Zealot fo (Score:3)
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''?
It's weak (Score:3)
- 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/
...they cannot lose (Score:1)
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.
Don't be confused (Score:2)
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...
Re:Bah, step back and stop playing Linux Zealot fo (Score:1)
Fight Club (Score:3)
XMLEverything (Score:3)
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."
Re:What's happened to Slashdot (Score:2)
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?
Check Out These Links (Score:1)
http://www.research.microsoft.com/~ymwang/paper
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/c
Those not in control will always want it open (Score:2)
Re:here is more info (Score:2)
Re:Bah, step back and stop playing Linux Zealot fo (Score:1)
S *Object* AP (Score:1)
Re:XML isn't a "standard"... (Yes it is!!!!) (Score:1)
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.
Re:XML isn't a "standard"... (Yes it is!!!!) (Score:2)
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).
Soft Soap (Score:1)
Also, CORBA always has been non-proprietary and OS independent.
MODERATE the above comment up! (Score:1)
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.
It seems... (Score:2)
Re:Why don't they give up trying to kill unix (Score:1)
How "open" do you want it? (Score:5)
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
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)
Re:Why don't they give up trying to kill unix (Score:1)
Microsoft would just fizzle. We make the sacrifice of having 5 years of Windows EVERYWHERE, and then just watch it die.
Re:Bah, step back and stop playing Linux Zealot fo (Score:1)
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.
Ack!!! (Score:4)
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?
Head in sand FUD (Score:2)
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.
--
Re:Fight Club (Score:2)
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.
Another expertly researched article (Score:2)
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
Shower Block... (Score:2)