Slashdot Mirror
Dave Winer On Microsoft, SOAP, XML-RPC In NYT
daveuserland writes: "Lots of activity in XML-over-HTTP. An article in today's NY Times about Microsoft, SOAP, UserLand and me. My comments. In the meantime XML-RPC keeps growing with solid interop. 29 implementations in the new XML-RPC directory. The politics are intense but everything's going well." It sounds like Dave understands this .Net thing; even after hearing about it for a few years, I've yet to hear a really lucid explanation of why I should want my apps and personal data floating in an amorphous cloud, but maybe that's just me.
what can i do with xml-rpc or soap? why is it so much better than just plain-old http post? just because it has the correct buzzword juju for today?
Actually, XML-RPC and SOAP both fall under the rubric of web services. Web services allow a program to make a remote procedure call to another machine using some wire protocol (ie XML-RPC or SOAP). The neat part about web services is that they are language neutral. That is, a Perl script on Linux can make remote procedure calls to an NT server running an ASP server. When the Perl script gets the data from the RPC call, the data will be available as a standard Perl datatype. If one were to simply use web pages to do this, every script would have to parse HTML just for that particular call. With web services, the programmer never needs to deal with XML at all.
Check out XML-RPC.com or IBM's developerWorks for more information on web services.
People. Please get a grip on your Microsoft bashing. Here's some point from a *user* of SOAP (and I'm not even using Microsoft'1 implementation).
.NET. .NET uses SOAP, but SOAP is not .NET. If it were, do you think IBM & Sun would be using SOAP?
-There are other versions of SOAP/WSDL/UDDI available. IBM has gratiously given their implementation to Apache. It looks to be the choice for open-source advocates. Sun has also announced they'll be supporting SOAP/WSDL/UDDI in the SunONE platform. Sun is also making ebXML compatible with SOAP, so that ebXML services can be called using SOAP, and vice-versa.
-IBM/Apache's implementation is interoperable with Microsoft's. Previous versions have had some major problems. But this is less a case of "embrace and extend", and more of a case of "this is new technology, and we haven't got the bugs worked out". I've seen IBM/Apache's and Microsoft's SOAP solutions call one another, from/to different languages. There are still a few quirks, but each release brings both Microsoft's and IBM/Apache's solution in greater compliance with the standard (yes, IBM's solution had some compliance problems, too!).
-Services are the next natural progression in software development. We've got from monolithic to client/server to 3-tier to n-tier develoment. The problem is that even with n-tier development, each tier relies upon the tiers next to it, in the form of a non-standard, programmer-developed API for the interface. Services free us from this, as they standardize the API between "tiers". And, by breaking down the "tier" concept, services can help bring component architecture to what was once a tier. It makes it easier to developed these components, and easier to assemble the components into an application. And it makes it easier to integrate components from third parties (such as -ack!- Hailstorm--but more importantly from small software vendors--I'm certainly not going to trust my sensitive info to Microsoft).
-XML-RPC is *not* SOAP. The only thing in common is that XML-RPC allows network programming using XML, as does SOAP. But SOAP packeges each network component into a service. This service can then be described in a standard way using WSDL (Web Services Description Language), so that programs can discover the API for a service and call the service automaticallly. Then, these services can be advertised using UDDI (Universal Description, Discovery and Integration), a sort of yellow pages for web services. XML-RPC provides RPC functionality, transferring data using XML.
-Web services do *not* have to use the Internet. This concept can work just as well on an Intranet. For large corporations, where there cannot be constant communication between the developers of services, using SOAP/WSDL/UDDI makes sense, as each development group then has a reliable and standard way of using services created by other groups.
-SOAP !=
Sorry for the long rant. I just hear way too many misconceptions. I get tired of it after a while.
--Be human.
The whole point here is the whole "Any device, anywhere" view that Microsoft has been driving at for a while now (Auto PC, Pocket PC, Tablet PCs, Web TV, upcoming Stinger cell phone, and so on). If you think about it, it's really not much different than keeping your mail on an ISP's mail server and just pulling it with imap on whatever machine you're going to read it from, except that the vision is more than mail -- it's digital pictures, digital music, contact info, free/busy info (aka, calendaring info), and more. The apps don't live in the cloud, only the data does (well, apps may keep a replicating copy in the cloud, but you don't run the app from the cloud -- it runs from whatever device it can run on). In fact, the only app neccessary for most of this is a web browser -- the rich clients are about enriching the experience, not creating the experience.
At the same time, you won't need a 24/7 internet connection to be able to work on your documents that live in the cloud. Local replication will make sure you have the latest copy of the data (as of the last time you were online) that you can work with and modify to your heart's content locally. Then the next time you connect to the net, it gets propped to the cloud, where you can then access the revised information from anywhere (PDA, laptop, cell phone, auto pc, internet kiosk, wherever). This does bring up some interesting security issues, but then those same issues exist with the current model of ISP mail servers holding mail that you then retrieve with imap, just on a smaller scale.
He deserved it.
Back in 1997 or so, Dave was bashing Apple left and right, running as fast as he could to port every bit of his code to Windows. He wrote DaveNet missives about how well MS understands and helps developers, how Apple just screwed its developers, and how Apple was on the verge of death.
Now he gets to see what comes from trying to be a pilot fish in the jaws of the big shark. It couldn't of happened to a more deserving guy.
-jon
Remember Amalek.
obligatory no login link
If you're interested, he's talking mainly about MS and IBM adding WSDL to the SOAP spec. The original userland article is here: http://davenet.userland.com/2001/03/29/unstallingS oap
And then he woke up...
War is necrophilia.
There are already dozens of standards including the humble comma delimeted file that every body can produce in a hurry. I can't tell you how many interfaces I have built in my life but I know for a fact that XML or SOAP or any other acronym will only mean more work. The single biggest success I have seen so far is HL7 (for the health care industry). They got together and created a massive standard based on fixed length data which specified not only positions and lengths but datatypes and content as well. Only when you enforce data integrity and consistency will you actually have a usable interop tool.
Tagging arbitrary data so that a generic parser can turn it into an object is pretty much useless.
What's needed is not tagging but data integrity and enforcement. Something like constraint rules in a database except over the internet. That would be cool.
War is necrophilia.
I dont understand. You are aware that you dont own your software right? Even if it is free software, unless you wrote it you dont own it. Even if it is in the public domain it is debatable whether you "own" it, as per any understanding of the word property. Perhaps when app rental is a reality the misconception that software is like that bike you got for christmas will finally die.
How we know is more important than what we know.
Sun Microsystems sales staff circa 1994?
How we know is more important than what we know.
Except that the the servers will be run by Microsoft, the protocols will be either be essentially secret, or be designed such that you *still* have to use microsoft's servers.
.net, combined with the set of other normal techniques. (they own the client software, which doesn't interoperate well with 'other' servers.... change the protocol every other year.... public protocols for encapsulation, but proprietary specifications for the data being encapsulated anyone?..... Outright proprietary protocols.)
.net as being: Basically inetd, except poorly designed. Oh, and like MSN from 1994, except cheaper for them cause they don't gotta pay for the modems or phone lines.
Even if the protocol is eventually made public, they can still force you to use their servers. (See the protocol-enforced centralization of ICQ/AIM protocols versus the DNS-based ones of (say) email or http.)
Oh, and you'll probably pay by the minute or pay by the access to use their servers, and there will with no real alternatives.
I would expect this behaivor from
This is what I see
While the real public standards would be fully public from the data, encapsulation, and transport. Probably have multiple vendors shipping servers and clients. Real competetion, run your own server, or purchase from a selection of service providers who have purchased the code... Much like HTTP or SMTP.... and the rest of the internet.
There's no free lunch; you're obviously paying for what services you use either way. But, which option will likely give you better service, more choice, higher stability, cheaper prices, and more control over your critical computing infrastructure.
One way makes Microsoft a perpetual middleman, in control and siphoning money. The other way gives you a choice.
I noticed that the NYT was much less flattering of Microsoft than Dave was.... His point seemed to be that this is a major strategic mistake on Microsoft's part.
I say, let us zig to their zag-- as they try to centralize, let us decentralize.
Also notice that Free software is the bane of this sort of model because the major arguement for centralized application serving is the fact that it can often cut the number of licenses that need to be puchased for a given piece of software.
I do think that there is a place for Application Service Providers, but that their role will probably be geared mostly to small businesses because this is the only market segment where real value can be added. This is .NET's potential market.
LedgerSMB: Open source Accounting/ERP
The nice thing about Microsoft is that they tell you exactly what they are going to do before they do it.
.01 releases, could never do.
And when MS made the "Pearl Harbor Day" annoucement that they would build a Netscape-class browswer and integrate into the Windows shell, I though they were insane. Netscape was too slow, too bloated, too crashy to ever be considered a fundemental component in the user interface.
And sure, MS's early attempts like IE 4 were pretty much the clusterfuck that I expected. However, while integration was a pretty crappy user application (and probably will always be, even with more doodads under XP or things like Natulius), it did put the pressure on MS to look at the browser as a mission critical application for the desktop. And by v5.01, they had pretty delivered. This shifit in thinking about the importantce of the browser was something that Netscape, with it's endless crappy
How many people really jump up and down at the idea of not owning software. I don't see anything in this that will ever make me not want to own my apps outright.
The idea as I understand it is to leave the gui at home and move all of the processing onto the servers. There's just no reason for that. We live in a day of celeron's and athlons. The most commonly used apps are web browsing and word processing. Word processing isn't processor intensive or at least it shouldn't be. If a word processor chews up my 433 MHz celeron it needs to go. The really processor intensive things like encoding and image editing aren't going to really benefit from this. What time would you save by uploading a huge wav and letting a remote server turn it into an mp3 and then ship it back to you.
This is just a plan to get us to get people hooked before they realize the newest Word isn't really any better than the last.
Even if linux does this I won't use it
But Yogi, the RIAA won't like that.