12.1 Future Technologies
The number of technologies lumped with web services is often overwhelming. In this section, I'll describe REST, cited by some as an alternative to SOAP, the UDDI registry; local service registration with Rendezvous; and touch briefly on BPEL.
12.1.1 REST
Representational State Transfer (REST) is a SOAP alternative. An elegant description of REST can be found at http://www.xfront.com/REST-Web-Services.html:
Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.
Roy Fieldinghttp://www.ics.uci.edu/%7Efielding/pubs/webarch_icse2000.pdf
In practice, REST simply refers to a mechanism with which you pass a request query and receive an XML document in response. As you've seen, this is likely to lead to extensive code that can parse these documents. In the Java case, this means writing Java objects to help work with XML documents. Using Axis and WSDL, you (or the API vendor) can automatically generate this bridge code.
That said, informal sources point to broader adoption of REST versus SOAP. Amazon offers both REST and SOAP interfaces. Indeed, there are reports that as much as 85% of the traffic using Amazon's web services is based on REST instead of SOAP (http://www.oreillynet.com/pub/wlg/3005). Unfortunately, if the examples as shown in this book are any indication, REST-based projects are liable to lead to considerably more client code for the maintenance of the XML processing as compared to SOAP-based solutions.
12.1.2 UDDI
One of the specifications often associated with web services is Universal Description, Discovery and Integration (UDDI). You can learn more about UDDI at http://www.uddi.org/ and find additional services at http://www.uddi.org/find.html.
UDDI offers a system for discovery based on a developer browsing a registry. There has been some talk of allowing dynamic discovery of web services, but little agreement and little in the way of broadly accepted implementations. Figure 12-1 shows the basic model: a centralized UDDI server is responsible for the location of clients. While the theory sounds nice, in practice there are few services that seem to use this system. As we've seen, few services use even SOAP and WSDL, and UDDI is a relatively complex system with relatively little apparent benefit for the complexity presented.
Figure 12-1. UDDI discovery model
A somewhat more human-palatable version of the UDDI registry is presented by the services afforded by http://www.bindingpoint.com/ and http://www.xmethods.net/.
As shown in Figure 12-2, you can see a variety of web services broken up along various categories. As of this writing, the categories (and the services listed) are broken up as shown in Figure 12-3.
Figure 12-2. BindingPoint web site
Figure 12-3. BindingPoint category listings
It's not surprising that the majority of the listings are in the Business and Economy section. We've covered some of the top rated web services in this book, including Amazon and Interfax's fax service. Others are less useful?for example, a joke-of-the-day service.
The difficult thing about measuring the success of "web services" is that for any given service, there's no way to track the total number of users. So, if there are 10 major web services (for example, the ones described in this book) and another 200 or 300 trivial ones, but the major ones are used by tens of thousands of developers, does that count as success?
The XMethods web site (Figure 12-4), in addition to free system for registering web services, offers a useful WSDL validation utility at http://www.xmethods.net/ve2/Tools.po. You can see the results of the validation utility when pointed at Amazon's WSDL file (http://soap.amazon.com/schemas3/AmazonWebServices.wsdl) in Figure 12-5.
Figure 12-4. XMethods web site
Figure 12-5. Amazon WSDL analyzed
As you can see, this is a useful exploratory tool and shows the importance of WSDL for tools and mechanical "self-disclosure" of web services.
Despite this functionality, UDDI has not enjoyed broad public adoption, despite tremendous and vocal support from a variety of vendors over a period of several years. Most web service vendors seem content to publish a WSDL URI on a web site in lieu of a UDDI infrastructure.
12.1.3 Rendezvous
At the other end of the spectrum from UDDI is a technology known as Zero Configuration Networking, or "ZeroConf." This technology is designed to allow easy network access and browsing via TCP/IP networks (similar to the browsing capabilities of AppleTalk for Mac OS X and NETBIOS on Windows). As shown in Figure 12-6, in lieu of a centralized server, ZeroConf specifies an automatic discovery protocol. Clients can still connect using standard TCP/IP services (such as DNS or direct IP addressing) across wide area network boundaries.
Figure 12-6. ZeroConf discovery model
Apple bundles ZeroConf technology as a core part of Mac OS X under the name Rendezvous. It's used in a variety of areas?for example, discovering local web sites in the Safari web browser, finding local chat and videoconferencing systems with iChat, finding printers, and even connecting your Mac OS X system to your TiVo without complex configuration.
For Java developers, it's easy to add support for discovering ZeroConf/Rendezvous services using the library at http://jmdns.sourceforge.net/. The library is still in an early stage, but it does offer a glimpse of a possible future direction for web services. It provides a simple way for a "server" application to broadcast the connection point for a set of SOAP interfaces, and if a listening "client" knows about the provided interface, it can communicate using SOAP interfaces.
At a human level, this is almost obvious; it's easy to imagine a work group in which systems and services appear and are immediately useful and necessary, but small failures are more or less inconsequential. Consider, for example, a peer-to-peer file sharing application or chat application. If the system fails, you have a simple, informal fall-back system, in large part based on the human interaction. Conversely, larger scale business processes require trust and a high bar for discovery and integration. If you want to purchase a large number of components to build a product for commercial sale, you're going to have a lot of requirements in terms of quality,
12.1.4 BPEL/BPEL4WS
Business Process Expression Language (BPEL), describes a process that accesses multiple synchronous and asynchronous web services given WSDL. The original submitters for BPEL were IBM, Microsoft, and BEA, so it's likely we'll see support for the these vendors. In addition, Collaxa has done significant work around BPEL and BPEL4WS (BPEL for Web Services). In addition to their products, a tutorial can be found at http://www.collaxa.com/developer.bpel101.html. That said, it's difficult to find much in the way of concrete support or interest for BPEL/BPEL4WS.
