Numerous articles and books are being written about Web services. Without going into repeated detail about how Web services work, let's look at some attributes that you can set on the Web methods you expose. One attribute is particularly helpful because it lets you cache the data of a Web service response. This discussion assumes you have general knowledge about the Web service technology. If you're unfamiliar with Web services, see Bill Sheldon, "What Is a Web Service?" by going to http://www.winnetmag.com/email/index.cfm?action=archive&emailnewsletterid=33 and selecting May 21, 2002 from the drop-down list.
I once used the Microsoft .NET Framework to create a few Web services, but I never knew about the attributes you can set on the methods. I had used a straightforward approach: I created public methods that another application would call as many times as necessary, not thinking about the impact on the server's performance. However, if data is coming from a database, you need to minimize the number of database hits.
For Web developers, minimizing the number of SQL queries whenever possible should be second nature, especially if a query returns a large amount of data. For an ASP.NET application, Output Caching and Application Data Caching work beautifully for lessening the hits on the server by caching data that's frequently requested. Caching works great in ASP.NET Web pages, but what about Web services?
Caching in Web services is similar to caching in an ASP.NET Web page: You can use the same Output Caching and Application Data Caching mechanisms. You have at your disposal the Cache object by way of the System.Web.HttpContext class. In an ASP.NET Web page, you can call this object's Insert method with code such as
Cache.Insert("Key", object, dependencies, absoluteExpiration, slidingExpiration, CacheItemPriority.High, onRemoveCallback)
However, in Web services you can't call the Cache object directly. While researching how to implement caching, I came across two approaches. One approach is similar to the approach used for ASP.NET Web pages. You call the Cache object's Insert method, except you must call the Context class first, with code such as
Context.Cache.Insert("Key", object, dependencies, absoluteExpiration, slidingExpiration, CacheItemPriority.High, onRemoveCallback)
Another way you can implement caching for a Web service is by setting a WebMethod attribute called CacheDuration. According to the Microsoft Developer Network (MSDN), CacheDuration is the number of seconds the response should remain in the cache. The default is 0, which means the server doesn't cache the response. When you enable caching, the server holds responses in memory for the cache duration, so you must use caution if you expect responses to be large or if you expect requests to vary widely. To set the CacheDuration to 60 seconds, you use code such as
<WebMethod(CacheDuration := 60)>
Recently, I used the CacheDuration attribute. In this implementation, the Web service has a WebMethod that returns a data set. This particular method receives quite a few requests at certain times of the day, so generating a new data set every time isn't efficient. In addition, much processing takes place to produce the data set, and no input parameters affect the returned data. When the WebMethod is called, the response takes from 15 to 25 seconds to appear. The data is somewhat volatile and changes every minute. By setting the CacheDuration to 60 seconds, the response data is in sync with the source data, but when the WebMethod is called, the cached response takes only 1 to 2 seconds.
You can set two other WebMethod attributes: BufferResponse and MessageName. BufferResponse reflects how Microsoft IIS handles a request's return stream. Typically, IIS waits until an entire response is ready or the response buffer is full before sending the response to the client. However, you can have IIS start sending a response as soon as there's data to send by setting this parameter to false. If you have a large data stream, using this setting can provide slightly better performance. However, in most situations, using this setting isn't a good idea because it might hurt performance.
The MessageName attribute lets you create an alias for the method name that a Web service exposes. This capability is important because the Web Services Description Language (WSDL) doesn't support polymorphic naming. Thus, for example, if you have a class implementation in which the GetRecord method can be called internally with an integer or a string, you need to have a different method name for at least one of the WebMethods.
Being aware that Web services have some built-in flexibility as to how you can define them and how they can respond is important. You'll have more control, which is always welcome.
If, like me, you didn't know about the caching approaches and WebMethod attributes associated with Web services, check them out. For more information about the Insert method, go to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwebcachingcacheclassinserttopic.asp. For more information about the CacheDuration, BufferResponse, and MessageName attributes, go to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbtskusingwebmethodattribute.asp.