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