Web Services: Irreconcilable Differences In the Marriage of Distributed Computing and Document Markup Technologies?
- Web Services Are Here, But What Are They?
- SGML Roots
- XML Schemas to the Rescue
- Transport Protocol Not Part of the Web Service Equation
- Adding Traditional Middleware Features
- Different Strokes for Different Folks
- Not Ready for RPC
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
Web services combine XML and the Web. There's no argument about that, but there is still plenty of argument within the Web services community about how best to format and interpret the XML, and how it should be transported across the Internet.
One big reason for the continued debate about what Web services really are and where they are going is that XML is derived from document processing technologies, not distributed computing technologies. XML and the Web are being put to a use for which neither was originally designed or intended.
There's a natural disconnect between people steeped in document processing and markup applications and people whose roots are in distributed object-oriented middleware technology. Web services represent a marriage of those two very distinct technology worlds.
The ultimate success or failure of Web services may well revolve around the question of whether or not the differences can be reconciled between the markup and distributed object communities.
Web Services Are Here, But What Are They?
Web services are the next big thing in distributed computing. Unlike existing distributed technologies (such as CORBA, J2EE, COM, and DCE), however, they are emerging from different technology origins. Web services are descendants of text processing systems rather than binary communication protocols.
If you were to ask 10 people to define Web services today, you would probably get 10 different answers. My favorite is that Web services are asynchronous messages that exchange XML documents across a network. Web services also are responsible for mapping the XML documents into and out of executable programs, objects, databases, and legacy applications. The executable programs are not part of the definition because they are not included within the specifications that define the core Web services technologies.
Some people define Web services purely based on conformance to the SOAP, WSDL, and UDDI specifications. But clearly this collection of specifications represents a body of XML styles, conventions, and profiles that need to be interpreted by a document processing program, just as traditional document processing markup languages are.
By my definition, therefore, Web services are not executable. They are instead a collection of XML applications mapped into and out of executable programs. XML is a document markup language that shares a common heritage with the Hypertext Markup Language (HTML)—the language used to create Web pages. These languages are not compiled into binary executables (as are languages such as C++, Visual Basic, or Java—of course, Java is indirectly mapped to binary through its virtual machine byte code, but that's another story).
XML does not have verbs like a traditional programming language that can be translated into binary machine language instructions. It actually does not have much in the way of predefined syntax elements at all—its purpose in life is to define things that are interpreted by other programs.