The Internet OS Framework
I have written much about the future of the Internet Infrastructure. The thesis for my view of this future is called the Internet Services Model.
The key elements of the Internet Services Model is a set of vendor-independent discreet Internet Services that are commonly accessible through a dynamic protocol framework.
Part of this framework requires an Internet-based object-model that seems to be taking shape in various forms. Here are some links can be used as references to how this protocol framework and various elements of the object model are shaping up.
Last week, Jason Levitt wrote an article published in Information Week that briefly looks at HPís e-speak, IBMís Web Services, Microsoftís .Net, Oracleís Dynamic Services, and Sunís Open Net Environment. His article doesnít frame the comparison in the context of an Internet OS, but is useful to look at since he highlights important emerging initiatives and protocols like UDDI, WSDL, and SOAP.
Jason has also written an article specifically about UDDI, WSDL, SOAP, and ebXML. He also writes more about the topic at this location.
Here are some additional links concerning web services:
http://www.webservices.org –looks at web services and how they are emerging.
http://www.xmethods.com ñ shows a bunch of web services running on various OSs that you can easily call from any OS
http://www.microsoft.com/technet/biztalk/btsdocs/biztalk_server/lat_sched_concept_qhfk.htm – XLANG intro
http://www.uddi.org ñ UDDI site
http://msdn.microsoft.com/xml/general/wsdl.asp – WSDL spec
http://msdn.microsoft.com/xml/general/soapspec.asp – SOAP spec
I will provide commentary an analysis on all of these as we proceed to look at the future of the emerging Internet OS.
A Note about Interoperability–
( Especially written for “irascible gadfly” Dave Winer.)
Anyone reading DaveNet or the Scripting News has seen him spinning a bit about all the press he has been getting as a result of being a leader in driving SOAP interoperability. A recent New York Times article describes him thusly:
“David Winer is a software designer who loves making trouble. And even if many in Silicon Valley consider him an irascible gadfly, he has a large, attentive audience.”
Here are Dave’s comments on the story.
The most difficult thing to embrace when trying to evangelize and build interoperable products is the notion that it is highly unlikely that a single thing will often emerege as the basis for such a loft objective. The higher up the network stack we go, the less likely it becomes. Things are just too complicated and there are too many political entities involved.
What does one do then? Plan for more than one element to be interoperable with. Is it completely unfeasable to consider being interoperable with both SOAP and XML-RPC? Why do we have to choose between these two things. Sure this makes the life of a developer more complicated, but it provides customers with choice. Freedom of choice is something Microsoft does very poorly. Freedom of choice is an excellent area to focus on to successfully compete with Microsoft.
The successful independent infrastructure vendors of the future will beat Microsoft at their own game by out manuvering it with customer choices.
The reason Microsoft is screwing with us and Mr. Winer is not a technology matter. SOAP technology is not necessarily better than XML-RPC technology. The approach Microsoft takes to new layers of technology is to control them through manipulation and deception. I am not saying this is a “bad” thing that should end. It isn’t going to end. I am saying this is a behavior you can count on and use to an advantage.
By planning on Microsoft trying to control emerging technology infrastructure and acting accordingly by offering cutsomers a choice is a highly effective approach with large amounts of benefit to the customer. Large amounts of customer benefit is tough to argue with when closing a sale.
Finally, if you think Microsoft is finished confusing its strategic partners and cusotmers about where it stands with SOAP and interoperability, you are in for a surprise. Until a real vendor-independent framework emerges that Microsoft can’t control, this is going to continue to be a source of contention for everybody.
The good news is that it will end and Microsoft will not control it (it can’t be controlled and it can’t be owned.)