Current Standards and Future Trends

In this book we have surveyed many Web services standards and seen how they can be deployed to support enterprise-class Web services applications. As we draw our discussion to a close, it is useful both to reflect over how far the individual technologies have come, and look into the near future to see how they may evolve for use in our next software projects.

XML

Given the investment that organizations have now made in this technology, there is significant inertia against changing the core XML technologies (XML, XML Infoset, and XML Schema). This core XML work is now solid (XML is an ISO standard, and each of these technologies is a W3C recommendation) and has provided the basis of the entire Web services stack. It is not expected that much will happen over time to change XML and XML Schema, and though XML 1.1 is being worked on, changes are likely to be minor and incremental.

For the peripheral XML technologies like XSL, XPath and so forth some less minor revisions are occurring. While it is anticipated that revisions to these technologies will be backwardly compatible that XML inertia helping out again the newer versions of these technologies are adding additional levels of functionality and richness that has been found lacking by current XML and Web services work. A classic example of this is the greater breadth of types available in XPath 2.0 compared to its predecessor.

The popular XML processing technologies SAX and DOM are also undergoing revision. While SAX has stabilized at version 2.0 and is being worked on at implementation level by the community, DOM has now evolved from level 2 to level 3 where its interfaces have been refined in the light of experience from the DOM level 2 compliant implementations. Though DOM level 3 is indeed a major revision, anyone comfortable with level 2 will have little difficulty migrating once level 3 becomes widespread.

SOAP and WSDL

SOAP 1.1 and WSDL 1.1 are already the single most ubiquitous de facto standards for Web services. Going forward, SOAP 1.1 will be replaced by SOAP 1.2 whose features have matured in the light of amassed experience with both SOAP 1.0 and 1.1.

SOAP 1.1 and 1.2 are sufficiently different to cause interoperability problems at the wire level. However, semantically they remain similar, so that we expect SOAP servers and toolkits to be able to support both versions and encapsulate the protocol detail away from applications behind APIs.

While the move to SOAP 1.2 will ultimately be thought of as more of an incremental upgrade than a major revolution, something more fundamental is happening to WSDL. In the future, we expect to see more high-level protocols exploiting WSDL extensibility elements and thus extending WSDL to build new Web services technology. WSDL will, in addition to its role as the Web services IDL, become the protocol toolkit for the description and development of new Web services protocol.

To summarize the evolution of these two technologies is simple: SOAP bootstrapped the whole Web service architecture and was the single most important standard until now. The SOAP community will continue to innovate and simplify, but their efforts will begin to go more unnoticed as the Web services community takes SOAP for granted. WSDL will be where future business-focused innovation in the Web services space will occur, and it is WSDL which will drive the second phase of Web services development and deployment.

UDDI

In the heyday of Web services hyperbole, UDDI was touted as the central hub of the Web services universe. These early days of UDDI focused almost exclusively on the Universal Business Registry as the technology that would allow services to automatically locate, bind, and interact with one another seamlessly across the Internet.

While the great promise of an Internet-scale network of Web services supported by UDDI has yet come to fruition and it may never do so UDDI has continued to grow in popularity in private networks. From being the glue that binds the universal Web services network together, UDDI has started to become an invaluable service for providing in-house Web services directories for individual enterprises, and for bringing together networks of partner Web services.

As we look forward to the future of UDDI, it is almost certain that the current sparsely populated Universal Business Directory will not dominate the Web services network globally. Instead, it is more likely that federations of smaller, more private UDDI registries will begin to build upward toward that ultimate goal. Though it is not necessarily the case that a truly global federated network of UDDI registries will ever reach the same scale as that originally envisioned UDDI is certain to remain a feature of the Web services landscape.

Transactions

With the advent of WS-Transaction, the incumbent OASIS BTP standard for Web services transactions has a new rival. This rivalry goes beyond technical differences between the specifications, of which there are many, and is really a symptom of the larger battle for the Web services environment.

Given that the WS-Transaction specification has the support of arguably the two biggest players in the Web services arena (IBM and Microsoft), it has been suggested that WS-Transaction will naturally be the transaction protocol of choice for the industry. However, to ensure success, WS-Transaction must counter the fact that the OASIS BTP standard is more mature and has the support of several shipping implementations, as well as the backing of a number of relatively influential players in the Web services field (such as Sun, HP, and Oracle).

What is clear at time of writing is that the arrival of WS-Transaction has put the brakes on much of the potential BTP deployments as the industry waits to see which of the two protocols will become dominant, or indeed whether there is any scope for convergence. Technically, both models have strengths and weaknesses, but ultimately which protocol dominates might come down to pure muscle on behalf of their backers.

Security

The lack of understanding of security issues for Web services together with the immaturity of technologies and standards to address these issues are one of the most important reasons of limiting the deployment of enterprise Web services. Much of the experience companies have with security is with Web sites and Web applications. Both of these applications involve sending HTML between the server and the client (e.g., Internet browser). Web services involve applications exchanging data and information through defined application programming interfaces (APIs). These APIs can contain literally dozens of methods and operations, each of which presents hackers with potential entry points to compromise the security and integrity of a system. Moreover, information that is exchanged between client applications and Web services must be secured and kept confidential, while not overburdening applications and servers with the large overheads associated with encrypting and decrypting all packets and all parts of each packet.

The XML security specifications, XML Encryption and XML Digital Signatures, make great strides in specifying security constructs that are sufficiently robust and flexible to meet the demands and trade-offs inherent to securing enterprise systems. The WS-Security specification builds on the XML security specifications and encapsulates them within SOAP envelopes. This brings to bear all of the benefits of the XML security specifications while removing any dependence on the specific transport layer, and also furthers interoperability. The WS-Security specifications are quickly emerging as the de facto standard for Web service security, and address many of the critical security needs of Web service environments. The remainder of the WS specifications roadmap (as laid out by IBM and Microsoft), once fully completed, will result in a comprehensive framework that supports and enables securing of many scenarios that are not possible today.

Conversations

Although WSCL received the accolade of being the conversation language of choice for UDDI.org, there has been no widespread acceptance of temporal interfaces for Web services as many architects and developers have only recently become familiar with static WSDL interfaces. While the technology undoubtedly has promise, the value of advertising temporal interfaces can only be realized when they are widely deployed, perhaps at the same order of magnitude as WSDL itself.

However, WSCL is not about to disappear completely. While it now seems likely that take-up of single-party conversation technology may be low in the near future, WSCL has become one of the technologies (along with WSCI) for the W3C's choreography working group that aims to tackle the general concepts of business process management over Web services. If this is ultimately the line taken, we may see elements of WSCL taken forward as single endpoint conversations become a subset of more general process choreography involving multiple parties.

Workflow

In the Web services workflow arena, BPEL4WS enjoys a dominant position in the field by dint that it is second-generation technology supported by arguably the most important commercial Web services players. While the royalty-free status of BPEL4WS is yet to be ascertained, implementations are already available from the BPEL4WS creators and third-party implementers, all of which add to its momentum. BPEL4WS itself is going through another revision, as alluded to in the "future directions" part of the specification. However, most of the work on the spec will be in integrating the BPEL4WS technology with other supporting Web services technologies, like reliable messaging and context management, and it is not thought that that BPEL4WS will undergo any radical changes in semantics.

All other competing standards in the Web services orchestration and choreography area have been subsumed by the W3C Choreography working group that has a two year charter to produce a choreography standard that meshes with the W3C's overall Web services architecture. This effort has the backing of some major players in the Web services arena and has taken on-board the WSCL and WSCI specifications as well as other non-Web services specifications to try to take a broad view of the problem.

However, given the broad view and lengthy charter of this group, it is entirely possible that BPEL4WS, with a smaller and nimbler set of participants backed up by huge engineering organizations, will steal a march on the W3C's efforts in the mean time.

Quality of Service

As more and more Web services become available, quality of service (QoS) becomes an important differentiating feature that will directly drive the popularity and the overall usefulness of a service. Exposing a piece of business logic as a Web service is not difficult; architecting the system so that it meets the needs of potential users with respect to performance, latency, reliability, and so on is the difficult part.

To support QoS, Web services themselves must be carefully architected and implemented, but standards and technologies must also emerge to monitor the QoS of individual Web services and then publish that information to potential client applications and Web service brokers. Although no dominant standard exists for monitoring and publishing QoS information, there are some likely candidates including extending WSDL to support QoS.

Mobile and Wireless

Mobile and wireless devices are no longer just novelty items within corporations. In fact, mobile devices are critical tools within the arsenal of 24x7 enterprise operations. Many challenges exist in the development of mobile systems that are usually not an issue in the development of non-mobile systems. Issues such as application energy consumption, network bandwidth utilization, limited computational resources, and small form factor user interfaces all come together to make the design of mobile applications difficult.

J2EE servlets are a well-understood and standard technology for bridging between existing systems (or new ones) and mobile environments. The servlet acts either as a proxy for mobile applications or generates the actual content that is displayed through a mobile browser. Since servlets can accommodate data in any format, the mobile system does not need to parse or generate XML data (e.g., SOAP envelopes), thus obviating the need for large footprint XML parsers.

Mobile devices can also directly access Web services without any proxy. In these situations, resource-limited SOAP and XML platforms, such as kSOAP and kXML, can be used. The Java 2 Micro Edition (J2ME) Web Service specification (JSR-172) is also emerging as a de facto standard for a larger framework for Web services operating within mobile environments. Once fully defined, the specification will articulate mechanisms by which to efficiently access Web services from mobile devices as well as to deploy Web services onto mobile devices.