Related Topics: XML Magazine

XML: Article

Exploding Web Services Myths

Exploding Web Services Myths

I was recently sketching out an overview of Web services for a colleague, including SOAP, UDDI, and WSDL. After a few minutes he came to the conclusion, "Ah, it's like CORBA, but using XML and HTTP." While this may have reflected the paucity of my description, it did seem to echo the opinions I heard "on the ground" talking to developers who are exposed to a variety of messages about Web services.

Some dangerous assumptions are being made about Web services. This is partly due to the origins of some of the technologies involved and partly to the hy-perbole surrounding this new movement in the creation of distributed systems. Even discounting any blue sky gazing about "smart" Web services, here I consider what type of application can actually be built with the Web service technologies available today.

Exploding the RPC Myth
Human beings like to compartmentalize things. We're comfortable if we can put things in a familiar "box." This is why analogy is a great aid to learning. When most people who are familiar with traditional distributed component systems see the combination of SOAP, UDDI, and WSDL, they will readily match them up with RPC, name services, and IDL respectively. This leads them, however, to think of this model of Web services as a dynamic mechanism.

It's easy to assume that applications using this model will look up the price of a commodity (for example, steel) on a daily, or even minute-by-minute, basis and will swap suppliers dynamically based on these figures. This assumption is aided and abetted by many previous visions of dynamic markets put forward as part of a future Internet.

The reality is that markets like these won't happen in the short term. Instead, the SOAP/ UDDI/WSDL combination will be used to improve existing ways of doing business. Existing Web/EDI links and prototypical (i.e., do-it-yourself) Web services will be replaced by standard Web service mechanisms. However, relationships will be set up at human speeds by human application developers and decision makers. The central determinants of the business relationship, such as the quality of the product and the trustworthiness of the supplier, will still be made in human terms.

This isn't to say that some markets won't use Web services dynamically - finance being the obvious one. Financial data already occupies a dynamic world with fortunes being made and lost on the availability of such data. An ultra-dynamic model of Web services will work well in this arena since it's simply mapping existing practices. However, many markets won't see a benefit from such dynamic Web services.

Will a company change its supplier of ball bearings to a relatively unknown company across the far side of the world based on a lower price found from a business directory? In most markets, any form of dynamic change or selection will occur within the context of a "local community" of suppliers. This parallels the way people buy certain things through the Internet, but still buy most things primarily from their local shops.

Rejecting the Global Registry
Another dangerous assumption that seems to be made by many people when they first look at Web services is the idea of the global registry. This distributed registry will contain all of the information required to find and interact with businesses throughout the world, thus enabling the ultra-dynamic Web services discussed earlier. This assumption may come about through our familiarity with the global nature of the Internet and particularly its naming service (DNS).

In many ways, DNS is a wonder of the modern world. It is one of the underpinnings of the Internet and it works fairly seamlessly; yet it's the shared responsibility of many organizations with no formal relationships between them. If DNS works, then why not have a global business registry along the same lines? There are a number of answers to this question:

  • DNS exists because it passes small amounts of data and caches well. The DNS data passed around consists of machine names and IP addresses - in the order of magnitude of 40 bytes per record. The data required to identify, select, and interact with a business service will be an order of magnitude or two greater than this, even with good compression. This amount of data being passed back and forth could help bring the current Internet to a standstill.
  • Given the amount of data in a global registry, can we really search it all using current technology? The searching of data is similar to cryptography in that it benefits from both increasing processor power and improvements in algorithms. Although Moore's law still drives processing power, some algorithmic-level improvements are needed in order to deliver such searching capability. Would it really be able to process all of this data and respond in "real time" for those people who need that level of response?
  • DNS is centrally or commonly owned and is based on simple, public standards. Registry services are one area where standards are not yet settled (for example, UDDI versus ebXML Registry and Repository), making the exchange of data far more involved.
  • Who would own and run the system? And most important, who would guarantee the searches were "fair"? No one really gains by returning his or her own IP address in place of the one searched for in DNS (apart from a few hackers). However, being the first match in a business registry could be of huge benefit in a Web services market. This means that the owners of such registries would be tempted to sell high positions on the list for maximum gain. In that respect, business registries would have more similarities with public Internet search engines.
In my opinion, there will be no global registry - at least not in the short term. What we will see is "local communities" of producers and consumers in vertical markets gathering around "portals." These portals will consist of UDDI registries (or ebXML registries and repositories) containing business data for that specific vertical market.

The provider of the portal will be able to deliver added value by providing some (potentially) trusted rating of the quality and reliability of the suppliers listed. The issue of "rigging" the searches may be solved by a certain degree of transparency, such as noting that particular companies have paid for premium entries or by having the portal run by a neutral industry body for that market, such as a trade association.

Questioning Security and Business Transactions
The final area to consider is security. Security is currently a weak part of the Web services story. Talk of security centers largely around the use of secure sockets (SSL) to pass HTTP requests from client to server and back. This provides a basic level of authentication and privacy between two servers. However, this is not enough for a global e-business infrastructure.

Consider the context for the discussion of global Web services, namely business-to-business transactions, potentially through an intermediary. In the "real" world, orders are authenticated by having signed pieces of paper that can be produced when required to provide a level of nonrepudiation for those transactions. Unless the e-business infrastructure can provide the digital equivalent of this, namely a digitally signed payload for each business message, then a free market in e-business will be seriously hampered. There must be a way to prove the authenticity of the original document, even if it has passed through several intermediaries.

As with most of the other issues stated above, the problem is more one of timing than technical capability. Efforts are afoot to add standard mechanisms of digital signing for XML documents. However, everyday, global use of this will rely on consistent and ubiquitous public key infrastructure that is itself currently proving somewhat elusive.

Going beyond the traditional EDI-style e-business models, people talk of replacing applications with globally accessible Web services that charge per-use rather than a on-off charge. The need for ubiquitous authentication and nonrepudiation is vital for this model since - if you can't identify the user in a non-repudiable way - how can you charge them for use of the service?

A final aspect in the area of business transactions is the legal basis of the transaction. If something does go wrong, whose jurisdiction does it fall under? In the world of paper contracts, this is usually written into them. For business to proceed, the same type of information must be built into electronic agreements. Even ebXML, with its Collaboration Protocol Profiles and Agreements, doesn't provide this sort of information as part of the negotiated business agreement, although it goes far beyond the simple RPC model discussed earlier in this article and takes us to a different level of binding and services.

Another issue is that ebXML doesn't form part of the most widely promoted model of Web services, namely that based around SOAP/UDDI/WSDL.

The Rush to Web Services
The philosopher George Santayana said, "Those who cannot remember the past are condemned to repeat it." In the early 1990s, the Open Software Foundation developed the Distributed Computing Environment (DCE). DCE was a rich and powerful distributed application environment providing the security and registry services required for truly distributed applications. However, DCE was perceived as too much of a heavyweight for most applications and hardware at the time, so its main legacy is the RPC mechanism that underpins Microsoft's Distributed COM. Having built basic connectivity on these foundations, Microsoft has spent much of the past five years adding in the security and registry services that were left behind in the original DCE.

The same type of issues seem to be facing ebXML - a powerful, XML-based e-business framework that addresses issues such as security and business process integrations. This is seen as being a heavyweight in Web services terms and is in danger of being sidelined (much like DCE was). However, if we don't learn the lessons of the past, we may well have to spend the next few years reinventing the parts of ebXML, and similar initiatives, that are discarded in the rush to Web services. The other side of the coin is that we may be able to survive with minimal services built on the simple building blocks. After all, the Web has come a long way on HTML and HTTP.

The real danger in all of this is that Web services are undermined by the weight of unrealistic expectations. The popular Web service technologies provide a way for us to get from A to B in a flexible and platform-independent way. The benefits of this shouldn't be underestimated, but we're a long way yet from a global e-commerce infrastructure geared around "smart" Web services.

Resources
A list of different ways that UDDI registries may be applied:

  1. www-106.ibm.com/developerworks/webservices/library/ws-rpu1.html
  2. JamCracker positioning paper on Web services, including registry ecosystems: www.itml.org/whitepapers/jamcracker
    webservicespositionpaper_wp_cust_se_0316011.pdf

More Stories By Andy Longshaw

Andy Longshaw has designed, created, and delivered technical content, training and consultancy on Java, e-commerce, XML and components. For the past four years he has tracked emerging technologies and predited how they will evolve in order to create products and offerings based on them.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.