Service Station
TECHNOLOGIES: Web Services | .NET
Weighing the Pros and Cons
Hype about Web Services Raises Many Questions
By Robert Lair
I began my column (see Fill er Up with Web Services!) by laying a foundation for future issues: I looked at what Web Services are and how they can help developers. However, some considerations are more fundamental: Are Web Services all they are hyped up to be? Are they practical? Do they perform decently? What new issues will developers face when Web Services start to become realities? In this article, I will consider these questions and try to determine if Web Services are really as good as they sound.
When Changes Occur
Dynamic Link Libraries (DLLs) provide an excellent way to reuse code. However, they also introduce a number of issues that can make things fairly messy. For example, the dreaded term DLL hell describes problems that arise when multiple versions of a DLL confuse a system. This can happen when newer applications are installed and require an updated version of a DLL that may not be compatible with older versions. Because of DLL hell, it is quite possible that installing one application can break another application or possibly even cause problems within the operating system itself.
The Microsoft .NET Framework eliminates this problem by allowing an application to have its own version of a DLL. The DLL only runs from the application with which it is installed. Therefore, the installation has no impact on the system or on other applications residing on it. However, as mentioned in Fill er Up with Web Services!, having local third-party DLLs running on your system could prevent it from obtaining updates to a DLL, even though the updates could correct errors in the DLL you have on your system.
Web Services can eliminate this problem by offering a remote component whose methods and properties can be accessed over HTTP. Because you are not installing the component locally, it has no impact on the system and its applications. This solves the DLL-version problem. Additionally, because the component resides at its source, bug fixes that do not result in a change to the service s signature can be made to the component easily without breaking the applications that consume it. This solves the problem of DLLs getting stale.
A Web Service can be updated easily as long as its signature doesn t change. But what if it does?
To access a Web Service from your application, you must build a proxy class, which handles the communication between your application and the Web Service. This proxy class will remain valid as long as the signature of the service remains the same. If a change to the component results in a new signature, a new proxy class must be generated. If the Web Service needs to be updated to the point at which its signature would change, ideally the person hosting the Web Service would expose another version of the Web Service while keeping the version you are using available as well. However, you re at the mercy of the service provider. Your application will work correctly only if it can contact and consume the Web Service successfully. This brings up another issue: connectivity.
Can Web Services Be Trusted?
The reliability of a Web application is something clients and developers take very seriously. They search long and hard to find a cozy little spot on a server that is guaranteed to be up 99.999 percent of the time, so they can rest comfortably at night knowing the site is up and all is well. With the birth of Web Services, developers have something else to worry about. When using Web Services in an application, the fact that the server is going to be up 99.999 percent of the time doesn t mean the host of the Web Service will be up 99.999 percent of the time. If the Web Service is not reachable, the application will not work correctly. You are now placing the reliability of your Web application in the hands of the service provider. Because of this, you cannot simply search the Web for a Web Service and use it in your production Web application. You must select a Web Service that is hosted by a provider you trust.
A service I foresee entering the market will be something akin to the signing of controls by companies such as VeriSign. With a service like this, a Web Service or the provider of Web Services could be certified to indicate it is reliable. This would give developers an added comfort level when consuming their Web Services. This kind of service would have to be very strict, however, in order for developers to feel more comfortable with a third-party Web Service. Nonetheless, I think this service will enter the marketplace shortly, if it doesn t exist already.
Protecting Yourself When Web Services Fail
I already mentioned the importance of selecting a reliable Web Service provider. But what happens if a Web Service isn t reachable? Consider a sinking ship. You do not want to go down with the Web Services you consume. In the event a Web Service is unreachable, or if an error occurs in the execution of the Web Service, the ideal situation would be for the application to recover gracefully.
If you wrap your Web Service calls in a Try...Catch block, you can trap any errors that may occur in the execution of the Web Service. When an error is caught, you can put plan B into action. Plan B can be just about anything depending on your situation. For example, one possibility would be to display a user-friendly message indicating an error has occurred. Another example would be to store the output from the last successful execution of the Web Service in the Cache object. In the case of an error, you could pull the output from the Cache object rather than from the service. Although this would be an excellent solution, it is limited to situations in which the output from the Web Service is not changing constantly.
How Web Services Perform
Performance of Web Services is going to be a major factor when developers consider using them in their production applications. No doubt, executing a method contained within a Web Service will be slower than calling the same method on the local server. This is because the transfer of the data itself will take a given amount of time. How much time depends on a large number of variables, but there is no question the time will be much greater than that of a local object call. Therefore, developers will need to decide if the benefits of using Web Services outweigh the performance hit.
Earlier, I described the possibility of caching Web Service output for situations in which the execution of the service fails. For situations in which caching Web Service output makes sense, developers can cache the data returned from the Web Service for a given amount of time. That way, the remote Web Service is called only when the data in the cache expires. This would allow you to gain all the benefits of Web Services without sacrificing performance. That solution would work only for a small percentage of services. But, for those services, it would work well.
I hope you ve learned that although Web Services provide a number of new options, they also introduce a number of risks. You must be very cautious with the Web Services you consume and must protect your applications in cases of failure. As with the case of the COM DLL usage, you must be aware of versioning of components and be responsible in the choices you make.
Conclusion
So, are Web Services really as good as they sound? I answer with a firm maybe. Every situation is different. In some cases, Web Services make sense. In other cases, they don t. As developers, we need to weigh the pros and cons of the different options available in implementing our applications. I hope I ve provided you with a number of things to think about when considering using remote Web Services in your applications.
Robert Lair is the president and chief executive officer of Intensity Software Inc., http://www.intensitysoftware.com, a software-development company specializing in Microsoft .NET development. He has been working with Microsoft .NET since early 2001, when he worked on the IBuySpy demo application. Robert also runs the development resource sites http://www.practicalasp.net and http://www.asppages.com. You can reach Robert with questions at mailto:[email protected] or by visiting his personal Web site at http://www.robertlair.com.
Tell us what you think! Please send any comments about this article to [email protected]. Please include the article title and author.
