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.

Comments

Some points

[The Mayor]

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

-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 != .NET. .NET uses SOAP, but SOAP is not .NET. If it were, do you think IBM & Sun would be using SOAP?

Sorry for the long rant. I just hear way too many misconceptions. I get tired of it after a while.

Data in the Cloud

[Osty]

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

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.

Dave W(h)iner gets what he deserves

[TWR]

Do you know what I think about Dave Winer having his work basically stolen by Microsoft?

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