Challenges
For web services to succeed in the Internet environment, there are many technical challenges to be met. Here are some of the issues:
|
Reliability |
Some web service hosts will be more reliable than others. How can this reliability be measured and described? What happens when a web service host goes offline 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 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 Secured Sockets Layer (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 on a per-operation basis? If you sign up with a vendor that provides services around the world, how do these services learn about your security privileges? |
|
Discovery |
UDDI is the standard that address dynamic discovery of web services. It is a young standard that will probably require several iterations before it is becomes an industrial strength web services matchmaker. |
|
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 they 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 its 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 XML markup language for supporting traditional transactions? |
|
Stability |
Since it is possible to expose existing component systems like Enterprise JavaBeans (EJB) as web services, it should be possible to leverage the load balancing and other scalability mechanisms that already exist. Or are there unforeseen stumbling blocks along this path? Does there need to be a new kind of "web services" application server? |
|
Manageability |
What kinds of mechanisms are required for managing a highly distributed system? Because the properties of a system are a function of the properties of its parts, do the managers of various web services need to coordinate in a particular way? And is it possible to "outsource" the management of web services to other web services? How do you charge for web services? Will the dominant model be subscription based, or pay as you go? |
|
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 operating systems? |
It all sounds very daunting, until you realize that systems that solve these problems already exist. Two such examples are human society and biological organisms. Both 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 examples, it should be possible to create a society of web services where components collaborate to achieve their own individual goals. You can easily imagine a networked marketplace where web services rent themselves out to the highest bidder. Mojo Nation is an open source project that takes exactly that approach.