This chapter is from the book
This chapter is from the book
This chapter is from the book
Lack of Standards
Another set of issues is associated with Web services that centers around incomplete or nonfinalized standards. Although there are ways to fix most of these problems, they are unique to each vendor's implementation. If the guiding principle of Web services is to create an open standardized interchange system for remote program execution, the utilization of any vendor-specific solutions should be avoided. The current Web services specifications and standards are lacking in the following areas:
-
Security and Privacy—Anything sent over the Internet can be viewed by others. At present, the only approved option for sending sensitive information to Web services is to use a Secure Socket Layer (SSL) program. SSL over HTTP is sometimes called HTTPS. This technology is wonderful in that it does a good job of safeguarding information such as credit card numbers, and it is easy to set up compared to other encryption techniques. The disadvantage is that SSL is slower than unencrypted HTTP transactions and is therefore unsuited to large data transfers. In addition, SSL is much more secure than most sales statistics need. Such a transaction shouldn't ordinarily be sent as clear text though. SSL encrypts the entire data stream, not just the sensitive parts. Let's consider the case in which the data being transferred contains an item's inventory tracking number, its description, and the credit card number used to pay for it. In most cases, online thieves would not care about the inventory number or the item description, but they would want to steal the credit card number. With SSL, it's an all or nothing solution. This situation is improving, however, because the W3C has several draft proposals that hopefully will resolve this problem.
-
Authentication—Authentication answers the question, "Who is contacting me?" At present, the standards ignore this issue and delegate it to the Web services Container. This causes proprietary solutions to be created and breaks down the promise of portability. Until a universal single sign-on solution is agreed upon, this problem will remain.
-
Nonrepudiation—Nonrepudiation means that you have rock-solid proof that a communication took place. This is also delegated to the Web services Container.
-
Transaction—Many activities that would be well suited to Web services are very complex. They involve dozens of smaller actions that must either all complete or all be rolled back. Closing on a new house is a good example. The last thing you need is for your financing to fall through but half the transaction (such as the escrow setup and courthouse registration of the lien) to complete anyway.
- Billing and Contracts—In most cases, you'll want to charge
for the use of your service. As a result, a way for pricing contracts to be
negotiated and maintained needs to be created. The current specifications
provide for service discovery, but do not contain a mechanism for handling
pricing for the service or performing automatic billing for the use of the
service. This issue becomes even harder if different customers want different
billing rates. This also ties into the provisioning problem because without
some sort of a contract in place, secure provisioning becomes unrealistic.
Contracts also need to determine service level agreements. (Who would pay
for a service unless a contract stated that it would be available 99% of the
time?)
Because the specifications don't have an agreed upon mechanism for handling these issues, many vendors providing Web services tools have built their own solutions. This can lead to problems when moving from one vendor's tools to another or getting two different vendor's tools to talk. As a result of this billing problem, most Web services posted to public UDDI registries are still free to use. On the other hand, companies providing Web services for their business partners typically do not post their service on public UDDI registries and can therefore control access and billing for use of the service through traditional manual billing methods.
-
Provisioning—This is the adding of valid user accounts to a system to allow users to access the service. Currently there is no agreed upon standard way to do this. The service provider and consumer need a mechanism to exchange provisioning information, and the service provider must know who it trusts as a source of that user information.
-
Scalability—Because it is possible to expose existing component systems such as 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? Some vendors have come up with mechanisms to provide for load balancing, but no standard for it currently exists.
-
Testing—Because of the new structure of Web services and the decoupling of the clients from the server, testing of Web service–based solutions can be challenging. Short of adopting a "try it and see if it worked" mentality, there really are few ways to test a Web service system. This is especially true for situations in which the client applications are written by one party and the server is written by another who charges for its use. How would one test a potentially half-built client against a service that you don't control? Even more important is what happens if that client does something to break the service?
Most, if not all, of these problems will be addressed in subsequent versions of the standards. Until then, we have no choice but to implement proprietary solutions with plans to revisit them when the technology matures.