Web Services Part 3: What Are Web Services?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In the first two articles, "Web Services Part I: Existing Problems" and "Web Services Part II: Current Technologies," we outlined some of the challenges that exist in the current business market and various attempts at addressing these challenges. Previous attempts to manage the inherent complexity in building distributed applications and web systems included object-oriented technology, component based development, and HTML. Each of these technologies, on their own, fell short of solving many of the aforementioned challenges. This article focuses on the definition of web services and provides the groundwork for future articles.
The concept of a web service is not a totally new idea: it is a refinement of many of the predecessor technologies. In fact, as we will see later, web services leverage (or at least integrate) much of the functionality provided by the previously mentioned technologies.
Loosely speaking, a web service is a piece of functionality (an object, a component, an application, a database call) that can be invoked over a network using a predefined syntax. The term web service is highly misleading because it has very little to with the World Wide Web, but unfortunately, the industry has adopted it.
Before continuing too much further, let us define the many ways which the term web services has been used in the industry:
Architecture—the term web services often specifies a group of technologies (SOAP, WSDL, UDDI, HTTP, and the like) on which applications can be built.
Predefined functionality that can be invoked in a distributed fashion—as mentioned earlier, a web service is callable across a network.
Market size—as usual, there have been quotes by various analyst groups about how this will be a multi-billion dollar market in the next 18 months.
More precisely, for our needs, we define a web service as:
A self describing piece of functionality that can be invoked over the Internet and can be combined to form higher level services.
A language and operating system independent architecture built on existing infrastructure and open standards (XML, HTTP, SOAP, and WSDL). The last two acronyms will be detailed in future articles.
NOTE
(Strictly speaking, web services can also invoke other protocols such as FTP (file transfer protocol) and SMTP (Simple Mail Transfer Protocol.)
Let us look at the terms in italics more closely:
Self-describing—the definition (the required parameters, the return values, and the like) of the web service is defined in a WSDL (web services definition language) document, and since WSDL is an XML grammar, the definitions for the document are embedded in the document (as opposed to being stored in an external file).
Can be combined—primitive web services can be combined to form more complex web services. This is analogous to building more complex objects or components out of simpler objects or components.
Architecture—using web services implies the existence of certain prerequisite technologies (the most fundamental being SOAP, defined further below).
Existing infrastructure—to leverage existing technologies, web services use the existing infrastructure (in most cases, the Internet) as its transport mechanism.
Open standards—a web service can be registered in a UDDI directory (UDDI is an XML grammar), its functionality is described in WSDL (an XML grammar, as described above), its result set is captured in a SOAP document (SOAP, an acronym for Simple Object Access Protocol, is also an XML grammar) and it is typically invoked via HTTP. These various technologies have been endorsed and adopted by many of the major technology vendors including Microsoft, IBM, Sun, BEA Systems, Oracle, Iona and many others. (In fact, Microsoft was a co-inventor of SOAP.) The technologies are also at various stages of standardization by the W3C standards committee, the same committee that defines many of the other Internet standards including HTML, XML, and the like.
NOTE
The term Simple Object Access Protocol is highly misleading because SOAP is not simple, nor is it object-oriented. Many developers now informally refer to SOAP as Service Oriented Architecture Protocol.
On the surface, the ability to invoke functionality across a network is nothing new (RPC, or remote procedure calls, have existed since the early days of Unix) and may seem fairly trivial. However, the adoption of web services has wide reaching implications. One of the biggest challenges of enterprise software development revolves around integrating two or more incompatible systems (either by intent or by accident). These incompatibilities usually arise because the systems were written in different languages (or different versions of the same language) and/or they use different middleware (for example, a CORBA object needs to communicate with a DCOM object), programming languages (say, Java and COBOL) or network protocols.
Traditional middleware solutions usually require that both the sender and the receiver need to be on the same platform and/or language. These factors tend to lead to high licensing costs (in the thousands and sometimes in the millions) and potential incompatibilities, which often lead to a lower adoption rate.
Web services, being based on open standards, alleviate the licensing costs (in many cases, the tools are free or built-in as part of low-cost development tools) and, being platform and language-independent, can solve many of the incompatibilities that exist with traditional middleware. As an example, rather than try to get a CORBA object to communicate to a DCOM object (not a trivial task because the two middleware have a totally different way of representing objects in their respective domains), the calling program can pass an XML document to the receiver and let the receiver populate the XML document with the result set. This sequence of steps is the core of SOAP, one of the prerequisites for a web services architecture. We will explore SOAP in greater detail in future articles.
Thus, rather than requiring one party to adopt a language (or middleware platform) of the other party, a web services architecture (or more specifically, the SOAP layer) allows both parties to keep the native platforms and communicate via XML, a more widely adopted standard than any existing proprietary middleware platform. This form of integration is considerably simpler and cheaper than traditional middleware. As a point of reference, Dollar-Rent-A-Car has implemented a solution that allows their customers to book flights with Southwest Airlines in two weeks. The implementation cost $40,000 using .Net (Microsoft's web services platform) while a competing option (presumably traditional middleware or an application server) would have cost $200,000.
The reduced integration costs allow a company to expand into new markets and more easily service existing customers. Most companies use business integration as a competitive advantage because it can lead to lower costs, better inventory visibility, and often revenue growth. To achieve any form of true business automation between two parties requires that the back end systems at the respective parties communicate directly with each other (as opposed to sending data that has to be manually reentered). Such a task has historically required a lengthy integration project (due to the challenges outlined above) and in many cases, expensive software and hardware on both ends. (In some extreme cases, the length of the project was longer than the duration of the relationship!) Consequently, many firms attempt business automation only with their largest clients or suppliers. However, if the integration costs were lower, then companies could now offer that same benefit to their smaller clients and suppliers as well. As an example of a smaller client that can benefit from business automation, consider a small firm that uses an Excel spreadsheet as a budgeting and forecasting tool. While working inside Excel, the user can write a macro to
Highlight the column with the budgetary values
Convert the highlighted fields to an XML document (using the built-in functionality of Excel)
Send an XML document (via the Internet) to his supplier
The receiving program on the supplier side can
Parse the XML document (that is, break it down to its simplest units)
Feed these simpler units directly into a quoting system
Generate a PO in the form of an XML document to be sent back to the client
The client can import the XML document into Excel and then compare it side-by-side with the budgetary values (or just display the document in a XML-aware browser, such as Internet Explorer). Note that both parties are integrated together but it is a much looser form of integration than what is normally present through traditional middleware (normally referred to as tight integration). As long as the two parties agree on the data format that needs to be exchanged, neither party needs to worry about platform or middleware compatibilities. In future articles, we will explore the various architectural patterns of web services along with real-world case studies.
The ubiquity of XML (and XML parsers) is one of the reasons why web services have such a high chance of succeeding in the market place.
NOTE
An XML parser is a program that is responsible for decomposing an XML document into meaningful data. The data is usually represented as a series of fields. Because XML defines a much stricter criteria for validness than HTML, an XML parser is considerably less complex (and hence, smaller in memory) than an HTML browser.
HTML (a platform independent lightweight markup language), combined with a browser (a universal reader and display mechanism) ushered in a new era of browsing of information (witness the explosion of web sites after the creation of the browser) because the technologies were simple, accessible and, for the most part, free or almost free. (Many have criticized the many shortcomings and lack of features of HTML, but HTML's rapid adoption as the primary Web programming language is because of its simplicity and low learning curve.)
XML promises to create even larger markets because it can be used for browsing (when combined with XLST) and for business automation, as shown in the simple example above. Additionally, it is being supported by all the major technology players (including IBM, Microsoft, Oracle, BEA, and the like) rather than created by a start-up, which then has to get market acceptance. Additionally, the adoption costs are very low (many of the tools are free) and the standards are being closely monitored and endorsed by third parties such as the W3C.
Note that web services are not the first industry attempt to solve the business-to-business automation problem. A much earlier effort at solving some of these challenges was EDI (electronic data interchange). EDI fell short of its vision because it was inflexible. As businesses evolve, they often need to add new data formats and fields, and trying to accomplish those tasks with EDI was extremely difficult. EDI's inflexibility often led to many implementations that deviated from the proposed standards (X12, EDIFACT, and so on), thus slowing down the adoption rate. Additionally, when EDI was invented, there was no global public network (that is, the Internet), and many firms had to invest in building (or paying for) proprietary networks.
NOTE
These networks are called Value Added Networks (VANs), and companies that offered these solutions include Harbinger (now part of Peregrine Systems), GE, IBM, and IBM. We will explore the counterpart to a VAN, a web service network, in a future article.
Thus, EDI is still very prevalent but only among the largest of companies (Wal-Mart, GM, and the like). We will explore EDI standards and how XML will co-exist with EDI in future articles.
The author would like to express his gratitude to the following people for their insights and help: Kevin Wittkopf, Randy Pilkenton, and Isaac Adams.