12.2 Future Directions
In this section, I'll look at some of the larger issues facing web services, including the complexity of development, the need for a business model, security, and finally present a mental model for tracking the evolution of web services over the near future.
12.2.1 Lowering the Bar
In this text, we've focused on Java as our development language of choice. Over time, a variety of scripting languages have appeared, promising to broaden the range of programming and development to a wider audience. Many vendors of development tools talk of a three-tiered model, with "ordinary users," "scripters," and "software developers" occupying the three ranks. Sometimes, this is broken down as "HTML," "scripting," "procedural," and "object-oriented" development.
In some ways, it would be more accurate to break down the complexity of web service development along the lines of client development and server development. This text has focused almost exclusively on client development?not web service server development. Applications may function as a server relative to the user's web browser, but we have not attempted to provide our own web services (save for an RSS feed).
As the component model for web application development matures, it's possible that the use of the more complex web service infrastructure such as SOAP and WSDL will be sufficiently encapsulated so as to make the development of web service applications accessible via visual builder tools. For example, several commercial tools now available allow a user to specify a WSDL and automatically generate web service components.
12.2.2 Understanding the Business Model
Almost all of the web services offered by various companies are provided for free in conjunction with an offline service of some kind. For example, FedEx provides the web services for free, but they charge to actually ship something. Similarly, Amazon offers free web services (indeed, they pay for you to publish material using their associates program), but they charge to actually ship products.
An open question is the viability of charging for web service access in and of itself. For example, eBay keeps track of the overall usage of the web services system and charges fees based on the access. In practice, this means that eBay is charging auction fees and also fees to view and post auctions. It's unlikely that eBay would have been successful if had applied a per-page-fee formula to ordinary web browsing.
This is very important and very significant for the future of the Internet. For example, an inexpensive pay-per-access web service model could pave the way for a micropayment system for access to content and software. Alternatively, it could also provide for richer integration between a client and a server for specific applications.
It introduces the potential for a richer economic model between a publisher of a service and desktop software. For example, a vendor that sells music online might offer a set of interfaces to access the system. The makers of desktop software could then create new clients to access the system with different capabilities, obtaining a commission for music sold through the system. In this fashion, a richer economic model is created, with more customer choice.
To date, this has been limited by the tendency of a corporation to want to own the entire chain of experience between themselves and the end user. This is the difference between the vendor of an application or a point product and a platform.
12.2.3 Security
Security in web services is still a somewhat mixed system. Throughout this text, we've seen a variety of approaches, and this variety is likely to continue for some time. Some services support HTTPS- and SSL-based connection encryption. A minor gesture is made toward security with the use of an MD5 hash for passing along passwords. There are a variety of tokens required to access different systems. At minimum, the following are all required to access a service: a single developer token, an authentication token, an application token, a user account, and a password.
It's easy to criticize the efforts with regard to security that have been made, but one of the biggest advantages of web services is the very reliance on the underlying standards. For higher security environments, it's easy to envision using existing technologies such as SSH or a VPN. Proxy servers and services can provide for robust logging and debugging capability. The same XML that SOAP relies on makes it easy for a proxy system to inspect the messages being sent.
12.2.4 Consolidation
The wide availability of SOAP clients and servers and the broad industry support from both small and large vendors is a very positive sign. XML-RPC also enjoys wide support, and the simplicity and stability of the specification mean that many of the libraries used are also stable. RSS also enjoys widespread support, but the sheer variety of feeds and the various "interpretations" of the specification make it much harder to work with than one might hope.
Interestingly, all of these rely on XML. There is a rich tradition of text-based protocols underlying the Internet, and XML allows a developer to provide a text-based representation without having to write a parser (one of the nastier, more error-prone pieces of software one can write). Even REST, one of the more aggressive alternative approaches, relies on XML as a primary data type.
The bright side is that virtually all vendors have agreed on XML as a universal glue. With the exception of CDDB, every service in this book uses XML in some fashion. It's likely that all these systems are going to move along a more or less predictable axis toward SOAP and WSDL as the developers of both the client and server side of the software get tired of reinventing the wheel. For example, why bother constantly recreating binding layers between your preferred development language and your server when simply standardizing on SOAP and WSDL gives you multilanguage bindings "for free?" Indeed, many systems automatically provide WSDL bindings automatically when you build a SOAP service.
Figure 12-7 attempts to capture the "evolution" of systems as they move from a more closed, binary system to a more mature, open, pure web services model. It's extremely trivial for most development systems to render a binary data file or push binary data "across the wire." This is almost useless for a web service model, as few developers have the time or inclination to support a specific, binary interface. It's difficult to maintain, and more often than not requires locking both the service provider and the clients into a potentially very fragile system.
Figure 12-7. Web service openness and maturity
The next stage, raw (or very loosely formatted) text, typically piped over TCP/IP, is much easier to work with than a binary format. Prior to the popularity of XML, this was the de facto standard for virtually all Internet protocols. FTP, HTTP, NNTP, Gopher, SMTP, MIME are all based on specific text markers for delimiting data. For example, if you browse through the IETF site and looking at the original specification for HTTP (at http://www.ietf.org/rfc/rfc1945.txt?number=1945), you'll notice that tremendous attention is paid to low level detail (the same sort of detail and Backus-Naur Form [BNF] grammar rules that one might expect from a compiler specification). The Internet Engineering Task Force (IETF) lists a tremendous number of low-level protocols that form the technological backbone of the Internet, but as developers began working with HTML and XML, the conversation moved beyond low-level BNF notation into a more accessible realm.
The popularity of the World Wide Web, specifically, HTTP, meant that virtually every major programming language soon included the ability to open a HTTP connection. Instead of engaging in the IETF-level semantics of a protocol, a developer could merely open a connection and get back data. XML, a stripped-down version of SGML, looked a lot like HTML but was easy to validate. A number of XML parsers were developed for a variety of languages, and suddenly, we could all move data back and forth very easily.
XML-RPC codified this notion into something that looks a lot more like a remote method call. Notice that there is no true object-oriented aspect to XML-RPC? no notion of inheritance or polymorphism, for example. This ensured that XML-RPC was accessible to nonobject-oriented systems, and that support would be available from a variety of systems.
SOAP, despite the original notion of "Simple Object Access Protocol," has over time acknowledged that it neither truly simple nor object-oriented, and the protocol officially no longer has any meaning (it's an acronym without an expansion). While the implementation of supporting libraries is more difficult, as we've seen it's not tremendously more difficult for a developer to either publish a SOAP service or use it.
The final addition of WSDL makes an application much easier to work with?as time has passed, virtually every modern development environment now has support for SOAP (at least as a client) and WSDL. Even such limited environments as Palm OS (http://www.palmos.com/dev/tech/webservices/) and PocketPC (http://www.pocketsoap.com/ or http://msdn.microsoft.com/library/en-us/wcesoap/html/ceconSOAP.asp) now support both SOAP and WSDL.
There will likely be a period of time in which an enterprising developer can offer bridge services between less mature services and the richer world of SOAP and WSDL (for example, it's easy to envision offering a SOAP view of the CDDB system). However, as of this writing, many of the organizations that currently offer non-SOAP systems (such as eBay) have already publicly indicated their desire to move to this environment.
The future of web services beyond SOAP and WSDL is far less clear. Some discuss the notion of choreography, which gives definition to the back and forth communication required to perform a transaction. Others point to a need for more coherence in terms of the actual APIs provided, or the details of what is meant by a transaction (for example, industry agreement over what is meant by a "purchase order" would make it easier to process an order across a supply chain). Savvy businesses and developers are too cautious to embrace a complex standard prematurely, and a lack of a clear, authoritative, credible organization has impeded efforts. Upon occasion, a very large organization is able to mandate a "standard" to partners, but typically these efforts are locked in as a proprietary system, not put forth as an open system.
It's not an accident that most of the popular systems (for example, XML-RPC, SOAP, and WSDL) have had complete implementations donated to a trusted, well known organization such as the Apache Group. Even if the software available isn't the best (although sometimes it is), a developer can work with the software, bundle it into their application, and otherwise take advantage of the "plumbing" provided without feeling encumbered by any potential proprietary system.
Probably the only real predication that can be made with any degree of certainty is the eventual coalescence of web services around SOAP and WSDL. Many of the services that don't implement SOAP already implement systems very closely. While SOAP and WSDL may never be as prevalent as HTTP and HTML, they will almost certainly eventually play as important a role in your development toolkit as TCP/IP or SQL.
