Number 4
October 2002

People, Protocols, and Progress


On a recent flight from Barcelona to Amsterdam, I noticed a well-dressed, gray-haired man sitting in front of me. I thought he looked familiar, and I finally realized that I was flying with Vint Cerf, the co-creator of the TCP/IP protocols. Wearing his trademark three-piece suit, he looked every inch the elder statesman of the Internet that he is. The global acceptance of Mr. Cerf’s brainchild is what allows any machine to talk to any other machine, a necessary condition for universal networking.

But it’s not a sufficient condition. Agreement on higher layer protocols is also required, and to a large degree, that agreement exists. Protocols for email, file transfer, and web browsing are well established, and the multi-vendor alignment required for this happened many years ago. One critically important higher layer function lagged behind, however, with the vendors involved unable to reach unanimity. From the dawn of networking until now, there’s been no agreement on what protocol should be used to invoke remote operations. Plenty of candidates have been advanced, including CORBA’s IIOP, Microsoft’s DCOM, and Sun’s Java RMI. None of them had the consensus required to be universally applied, however, and so the problem remained unsolved. Now, at last, that consensus does exist, as every vendor has embraced SOAP.

The path to a standard protocol for invoking remote operations may look different, but it’s much like the route taken by TCP/IP. As the figure below shows, several transport layer protocols were once vying for the role of universal connector. A dozen years ago, OSI’s TP4 was still a candidate, as was the SPX protocol created by Xerox and used in Novell NetWare. Even DECnet’s NSP was in the running. (Remember DECnet? Remember DEC? For that matter, remember Compaq?) All of these protocols did essentially the same thing, and so it made no sense to have a world where all were used. By 1995, reality caught up with reason, and TCP reigned supreme.

Application to

Java RMI


The same thing is now happening with a protocol for invoking remote operations. In 2000, SOAP had just emerged, and IIOP, DCOM, and Java RMI were all actively competing. Yet what’s happened? The CORBA market, and thus the use of IIOP, wound up largely dominated by one company, Iona, which today is betting its future squarely on SOAP. Microsoft’s .NET Framework replaces the aging DCOM protocol with SOAP and a binary doppelganger of SOAP. Even the Java camp, while a little slow to latch on to this wave, has produced JAX-RPC, providing a multi-vendor way to use SOAP from Java. Just as it made no sense to have many equivalent transport layer protocols in use, it also makes no sense to have many equivalent application-to-application protocols. By 2005, and probably even earlier, I’m confident that SOAP will emerge as the universally used protocol for this critically important purpose. It’s taken many years too long, but agreement is finally at hand.

After creating TCP/IP, Vint Cerf became an executive at MCI, the operator of America’s largest Internet backbone network. MCI was eventually acquired by WorldCom during the Internet bubble years, and the flight I shared with Mr. Cerf happened not long after WorldCom’s accounting chicanery came to light. The company needed to lie because they greatly overestimated the growth of Internet traffic and thus invested way too much in building new network capacity. Without the universal standard of TCP/IP, this sequence of events never would have happened. I couldn’t help wondering what its creator thought about the financial tempest his brainchild had unintentionally made possible. Protocols are created by people, but like children, they’re hard to control beyond a certain point. Who knows? Maybe the next bubble will be based on outsize expectations of what SOAP can provide, and perhaps we’ll see one of SOAP’s creators join the leadership ranks of a large organization built on his technical innovations.

Yet whatever happens to the people involved, the arrival of what is effectively a TCP for the application layer is unquestionably a good thing. Calling this technology "web services" is a bit peculiar, since we’ve been shooting for this goal since well before the web existed. Still, after years of false starts, our patience has at last been rewarded. The waiting was worth it.



Over the last several years, I’ve been the keynote speaker for a variety of events in cities around the world. Many of them were Windows-oriented conferences, such as WinDev in the United States, WinSummit in Switzerland, DevelopMentor’s Conference.NET, and Microsoft TechEd conferences in various countries. I’ve also given keynotes at other events, such as last summer’s Web Services One Conference, an internal IT leadership event at a large insurance company, a software vendor’s international user conference, and a vendor-sponsored multi-city tour introducing new technologies.

An effective keynote combines several things: education, entertainment, and ideally, inspiration. I work with my keynote clients to learn what they need and what will impact the audience I’ll be speaking to, then create a presentation that addresses those requirements. For more information or to see review comments from keynote attendees, visit the Keynotes page on my web site. If you’d like a sample keynote video, contact me at






David Chappell is Principal of Chappell & Associates ( in San Francisco, California. Through his speaking, writing, and consulting, David helps information technology professionals around the world understand, use, market, and make better decisions about enterprise software technologies. David has given keynotes at conferences and in-house events in the U.S., Europe, Latin America, and the Middle East, and his seminars have been attended by tens of thousands of developers and decision makers in more than thirty countries. David’s books have been translated into ten languages and used in courses at MIT, ETH Zurich, and other universities. His consulting clients have included HP, Microsoft, Stanford University, and other technology vendors and users.



©Copyright2007 David Chappell and Associates
All rights Reserved.


To subscribe or unsubscribe to this newsletter, go to