From EDI To XML And UDDI: A Brief History Of Web Services
Web services has the potential to change the landscape of B-to-B communications. But just where did it come from? Jason Levitt tackles Web services' history in this month's Internet Zone.
"I think it's safe to say that Microsoft wasn't the first to put these two words together," says John Montgomery, group product manager for Microsoft's .Net developer platform. "But we were the first to associate the two words with XML, SOAP, WSDL, and UDDI." And anecdotal evidence does suggest that the two words, Web services, were in fact first uttered in this context by Microsoft chairman Bill Gates at the Microsoft Professional Developers Conference in Orlando, Fla., July 12, 2000.
Web services are applications that can communicate with other apps over a network by using a set of standardized protocols. But while the words may have sprung from Microsoft's marketing efforts, Web services didn't just come from Microsoft. The technology originated from the efforts of many companies that share an interest in building electronic marketplaces.
The Precursors "Those who cannot remember the past are condemned to repeat it," wrote philosopher George Santayana, approximately 70 years before electronic data interchange was launched in 1975. EDI was the first attempt to create a standard way for businesses to communicate over a network.
In the 25 years since EDI came on the scene, there have been numerous attempts at a universal conduit for connecting business logic over a network: Common Object Request Broker Architecture, Distributed Component Object Model, Unix Remote Procedure Call, and Java Remote Method Invocation. Each of those technologies failed to gain significant market share or enough momentum to succeed. All of them exist today--each still has its uses--but each failed to gain a broad reach.
EDI was difficult to implement because of its complexity and cost. Corba, deployed mostly by Unix systems vendors, and DCOM, a Microsoft technology, competed with each other for many years. Both were relatively difficult for programmers, and neither gained broad industry support. Unix RPC, which refers to several flavors of technologies that are available on Unix systems, was never widely deployed outside the Unix vendors. Sun's Java RMI technology is a recent addition; I don't believe it will get complete industry support, because of Microsoft's break with Java.
Cost, complexity, flexibility, industry support, and even bad luck have contributed to the misfortunes of these technologies. Have vendors learned from their past mistakes? The current success of Web services suggests they have.
The Web To The Rescue
Before the Web, getting all the major software vendors to agree on a transport protocol for cross-network application services might have been impossible. But the Web rendered that decision academic, by specifying lower level transports for standardized communication.
The Web uses HTTP running on TCP/IP. TCP/IP was already a mature standard by the time the Web went mainstream in 1994, and, by 1997, HTTP had become a universal business standard. With HTTP and TCP/IP in place, all that was needed was some kind of messaging and data encapsulation standard--and a lot of vendor cooperation.
It was XML's invention that really paved the way for Web services. As a widely heralded, platform-independent standard for data description that could also be used to describe message-passing protocols, XML was a logical choice for the job of standardized application-to-application communication.
XML officially became a standard in February 1998, when the World Wide Web Consortium announced that XML 1.0 had reached draft recommendation status: suitable for deployment in applications.
By early 1998, several attempts at an XML protocol for interprocess communication were made. Allaire Corp.'s Web Distributed Data Exchange (WDDX) was one independent attempt of note, but it was SOAP, developed by Dave Winer, CEO of Userland Software, Microsoft engineers Bob Atkinson and Mohsen Al-Ghosein, and Don Box, co-founder of DevelopMentor Incorporated, that was to become the basis for Web services.
Both Dave Winer's History Of SOAP and Don Box's Brief History of SOAP have the gory details of SOAP's early evolution. Notably, Box points out that the reason Microsoft didn't release SOAP initially was because of internal politics, caused by uncertainty between Microsoft's Component Object Model group and Microsoft's XML group. As a result, it took more than a year before SOAP was unveiled to the public.
Electronic marketplaces were a hot concept in December 1999, when Microsoft held a private meeting with IBM and other interested companies to show off SOAP 1.0, its specification for a standardized message-passing protocol based on XML.
SOAP had a lot of things going for it. It was platform agnostic, flexible, and general-purpose. Its main drawback was that Microsoft was offering it.
"The problem was getting people to think it was good, even though it came from Microsoft," recalls Andrew Layman, an XML architect at Microsoft. "People were convinced, by people like Sun Microsystems CEO McNeely, that it must have been a trap."
IBM was the first major vendor to warm up to SOAP. "We liked the idea of this simple messaging protocol," says Bob Sutor, IBM's director of E-Business Standards Strategy. In March of 2000, IBM publicly backed Microsoft's SOAP and started working with the company to develop SOAP 1.1.
By the summer of 2000, SOAP was gaining wider acceptance. IBM and Microsoft were also each working on a way to programmatically describe how to connect up to a Web service. After some discussion, protocol proposals from Microsoft and IBM merged. IBM contributed Network Accessible Service Specification Language and Microsoft offered both Service Description Language and SOAP Contract Language. In the fall of 2000, the merged specification, Web Services Description Language, was announced.
With SOAP and WSDL, companies could create and describe their Web services. But someone still needed to provide a way to advertise and locate Web services. In March 2000, IBM, Microsoft, and Ariba started working on the solution: Universal Description, Discovery, and Integration. "A lot of the work that went into producing SOAP was an experiment to see how well we could work together on a specification, before we started on UDDI," Sutor says. In September 2000, UDDI 1.0 was announced.
With SOAP, WSDL, and UDDI in place, the de-facto standards to create Web services had arrived, but it wasn't until the end of 2000 that five major IT software infrastructure vendors announced their commitment to Web services. Oracle, HP, Sun, IBM, and Microsoft, an unlikely--and thus impressive--alliance, stated their intention to support and deploy the Web services standards in their products.
It took unprecedented vendor cooperation and commitment on the design of the core standards (SOAP, WSDL, and UDDI) to make Web services happen--but there's still more to be done. Additional Web services standards must be defined and adopted in order to build and integrate things like authentication and connection management.
The key is, and will continue to be, vendor commitment to these de-facto standards. By late 1999, HP's E-Speak was already established as a framework similar to Web services, but it didn't have the support of other major software vendors.
Web services have gotten this far because of cross-vendor support and attention to simplicity and flexibility of design. Have we remembered the past? I think so.
What's coming next in Web services? Tell where you think the opportunities lie--and where the challenges are hiding--in Jason Levitt's discussion forum.
How Enterprises Are Attacking the IT Security EnterpriseTo learn more about what organizations are doing to tackle attacks and threats we surveyed a group of 300 IT and infosec professionals to find out what their biggest IT security challenges are and what they're doing to defend against today's threats. Download the report to see what they're saying.
Infographic: The State of DevOps in 2017Is DevOps helping organizations reduce costs and time-to-market for software releases? What's getting in the way of DevOps adoption? Find out in this InformationWeek and Interop ITX infographic on the state of DevOps in 2017.
IT Strategies to Conquer the CloudChances are your organization is adopting cloud computing in one way or another -- or in multiple ways. Understanding the skills you need and how cloud affects IT operations and networking will help you adapt.