Welcome to the first installment of a new column that focuses on the evolutionary and revolutionary aspects of Web services technology. "Evolutionary"because Web services are the next step in abstraction beyond object-oriented technology, and "revolutionary" because I believe they will catalyze a shift from client-server to peer-to-peer architectures.

In this series, I'll start with an overview of Web services and some of the hurdles that must be overcome in order for mass adoption to occur. Next, we'll build some simple Web services and use them to create distributed systems. Then we'll examine some of the thorny issues like security, transactions, and scalability. Finally, we'll use Web services to create some peer-to-peer systems that will demonstrate a shift in thinking away from traditional distributed architectures.

Overview

A Web service is a collection of functions that are packaged as a single entity and published to the network for use by other programs. Web services are building blocks for creating open distributed systems, and allow companies and individuals to quickly and cheaply make their digital assets available worldwide. One early example is Microsoft Passport, a convenient authentication service hosted by Microsoft. Here are some other examples:

• a credit checking service that returns credit information when given a person's social security number.
• a stock quote service that returns the stock price associated with a specified ticker symbol.
• a purchasing service that allows computer systems to buy office supplies when given an item code and a quantity.

A Web service can aggregate other Web services to provide a higher-level set of features. For example, a Web service could provide a set of high-level travel features by orchestrating lower-level Web services for car rental, air travel, and hotels. Applications of the future will be built from Web services that are dynamically selected at runtime based on their cost, quality, and availability.

Web services are pretty much guaranteed to be at the heart of the next generation of distributed systems. Here's why:

• Interoperability. Any Web service can interact with any other Web service. Thanks to SOAP, the new standard protocol  supported by all of the major vendors (and most of the minor ones too), the agonies of converting between CORBA, DCOM and other protocols should be over. And because Web services can be written in any language (even COBOL I bet), developers do not need to change their development environments in order to produce or consume web services.
• Ubiquity. Web services communicate using HTTP and XML. Therefore, any device which supports these technologies can both host and access Web services. Pretty soon, they will be present in phones, cars and even soda machines. Soda supplies getting low? No problem, the wireless-networked soda machine can contact the local supplier's Web service and order more of your favorite beverage.
• Low barrier to Entry. The concepts behind Web services are easy to understand and free toolkits from vendors like IBM and Microsoft allow developers to quickly create and deploy Web services. In addition, some of these toolkits allow pre-existing COM components and JavaBeans to be easily exposed as Web services.
• Industry Support. All of the major vendors are supporting SOAP and the surrounding Web services technology. For example, the Microsoft .NET platform is based on Web services, thereby making it very easy for components written in Visual Basic to be deployed as Web services, and consumed by Web services written using IBM VisualAge, and vice-versa.

Back to top

Challenges

So far, it all sounds good. But for Web services to succeed, there are many technical challenges that have to be met, many of which are related to the open, hostile environment in which they must survive. Here are some of the issues:

• Discovery. How does a Web service advertise itself for discovery by other services? What happens if the service changes or moves after it has been advertised? WSDL (Web Services Definition Language) and UDDI (Universal Description, Discovery and Integration) are two new standards that address this issue.
• Reliability. Some Web service hosts will be more reliable than others. How can this reliability be measured and communicated? What happens when a Web service host goes off-line temporarily? Do you locate and use an alternative service hosted by a different vendor, or do you wait around for the original one to return? How do you know which other vendors to trust?
• Security. Some Web services will be publicly available and unsecured, but most business-related services will use encrypted communications with authentication. It is likely that HTTP over SSL will provide basic security, but individual services will need a higher level of granularity. How does a Web service authenticate users? Do services need to be able to provide security at the method level? If you sign up with a vendor that provides services around the world, how do these services learn about your security privileges?
• Transactions. Traditional transaction systems use a two-phase commit approach -- all of the participating resources are gathered and locked until the entire transaction can take place, at which point, the resources are finally released. This approach works fine in a closed environment where transactions are short-lived, but doesn't work well in an open environment where transactions can span hours or even days. Microsoft supports an alternative scheme, called compensating transactions, in their new XLANG system for distributed business processes. Should this kind of transaction be integrated into Web services? If so, what is the overlap between this approach and proposed standards like XAML, an upcoming XML markup language for supporting traditional transactions?
• Scalability. Since it is possible to expose existing component systems like Enterprise Java Beans as Web services, it should be possible to leverage the load-balancing and other scalability mechanisms that already exist. But are there unforeseen stumbling blocks along this path? Does there need to be a new kind of "Web service" application server?
• Manageability. What kinds of mechanisms are required for managing a highly distributed system? Since the properties of the system are a function of the properties of its parts, do the managers of each of the various Web services need to coordinate in a particular way? Is it possible to "outsource" the management of some Web services to other Web services?
• Accountability. How do you define how long a user can access and execute a Web service? How do you charge for Web services? Will the dominant model be subscription-based, or pay-as-you-go? If you sell a Web service, how do you designate the ownership has changed? Can a Web service be totally consumed on use, or can you reuse the service multiple times as part of your purchase agreement?
• Testing. When a system is comprised of many Web services whose location and qualities are potentially dynamic, testing and debugging takes on a whole new dimension! How do you achieve predictable response times? How do you debug Web services that can come from different vendors, hosted in different environments and on different operating systems?

It all sounds rather daunting, until you realize that systems that solve these problems already exist. Two such examples are human society and biological organisms. Both of these examples exhibit the following properties:

• Fault tolerant.
• Massively parallel.
• Distributed.
• Well organized.
• Self-repairing.
• Designed in a layered fashion.
• Designed out of simple components.

By taking the lead from these existing examples, it should be possible to create a society of Web services where components collaborate with each other to achieve their own individual goals. You can easily imagine a networked marketplace where web services rent themselves out to the highest bidder. MojoNation is an open source project that takes exactly that approach.

Back to top

Peer-to-peer and Web services

Looking beyond the straightforward uses of Web services, there are many exciting applications of this technology in the world of peer-to-peer (P2P) computing. For example, imagine a P2P version of eBay where consumers install a simple auction Web service onto their home computer or smart phone. Once you've told your auction service what you want to sell and what you want to buy, it contacts other auction services around the world to hook you up with appropriate buyers and sellers. Transactions occur directly between consumer devices, and no servers are required.

An even zanier idea is a P2P cellular network, which uses other intermediate consumer's phones instead of base stations. When you make a call, the call routes itself via neighboring cell phones to reach its final destination. With this architecture, you could literally airdrop 10,000 cell phones into a previously unwired region, and as long as there was a reasonable concentration of people, you could make instantly make phone calls without any base stations or other traditional phone network infrastructure!

I think that the power and simplicity of Web services will accelerate innovation in the world of distribute computing. For the rest of this series, I aim to educate, entertain and promote discussion between developers in this area. Although the specific order of presentation is hard to predict, the following areas will be covered:

• Hands-on tutorials.
• Emerging standards like SOAP, UDDI, WSDL and XAML.
• Peer-to-peer architectures.
• Dynamic discovery.
• Security and transactions.
• User interfaces for Web services.
• Orchestration of Web services.
• Testing applications based on Web services.

The next column will lead you through every step of creating your own Web service. Until then, happy hacking!

Resources

• The UDDI organization has a white paper on UDDI interfaces.
  
  
• The Web Services Description Language 1.1 indicates how Web services can describe themselves to others. It is now part of the Emerging Technologies Toolkit.
  
  
• The Apache project also hosts useful information on SOAP.
  
  
• Check out the coming XAML transaction authority markup language.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Overview
• Challenges
• Peer-to-peer and Web services
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers