Last year, while reading few articles I came across one beautiful article written by Paul Ballard. That article was about top 5 web service mistakes. I had worked extensively on the web services using .NET and after reading the article I realized the importance of it. These mistakes are not syntax mistakes but they are logical mistakes. These are architectural mistakes and not technological. The key is to avoid them from beginning only and not at the time of deployment.
So many people are writing .NET based web services now days. It is very easy to write a web services using IDEs especially Visual Studio.NET. This IDE is a real beauty. All you have to do is click on create new project of type ASP.NET Web Service. The VS.NET then writes one default web method for you. All you have to do is rename it, uncomment the code and then put your business logic in it. Compile it and then you are ready for the deployment. Necessary WSDL will be created for you by VS.NET. When things are so simple, beginners find it very easy to write web services in their resumes. Such kind of easy things, if not planned and handled properly then could lead to disasters. This is the reason why you should consider following mistakes before writing web services.
Using .NET Specific Types
For a web service to be interoperable with any technology, its data contracts must be based on types defined by XML schema. If you use .NET Specific types as parameters or return values for a web service, the XML it produces may not be interoperable with Java or other technologies. For example: Passing a Dataset as a result in a web service.
In this case, the structure of the Dataset is not known until runtime. So there is no way for the WSDL to describe the internal structure. This is the web service equivalent of late binding. Since client developer has no idea about the structure of the object, they won’t be able to generate a very useful proxy. They will have to parse the XML returned to find the data they are looking for. You have probably seen demos in the past where the presenter returned a DataSet to a .NET Framework client and somehow it magically became a DataSet on the other end. This works because the Web Service infrastructure in the .NET Framework looks for a special flag in the runtime-provided XML Schema definition called IsDataSet.
Not Taking Advantages of ASP.NET
Most of the developers failed to understand the exact relationship between .NET web services and ASP.NET. The biggest drawback today in consuming Web Services is performance. Web Services developed in .NET are deployed in ASP.NET. They have access to all features of any ASP.NET Application. For performance, the two most important features are Caching and SessionState. Output Caching allows the result of a service method request to be stored in the server’s cache. Subsequent requests with the same parameters will get result from the cache.
Not Enough Bang for the Buck
The Web Service should be designed to maximize the amount of work performed with each request. It is always good idea to reduce the number of server trips. For better performance, consider combining smaller requests into a larger single request. For example: Let us assume that there is a Web Service which gives you current market price for the requested stock. Typically, developers would write a web method to accept one stock symbol and return one price at a time. So in the demo version of the Web Service, you would make ten trips to server. This can be avoided by combining multiple requests in one request.
Using Web Services for Data Access
Many Architects and Developers tend to see Web Services as means to share data. Web Services don’t just provide access to data, but they provide access to an organization’s proprietary business knowledge. The best example of the Web Service exposing functionality and not data is Google’s Web Service for searching web pages. Google has leveraged their extensive knowledge of how to search the web and that is where the value of their Web Services comes from, not their data. Remember that consumers of your Web Service want your business expertise and not just data
Trusting the Client Application
Apart from giving access to business knowledge, Web Services also have responsibility to protect business and integrity of the data. Typically, Web Services are developed at the same time as the User Interface to consume it. The Web Service acts as a backend to the application and so security is left to the UI only. The security of the UI and Web Services should be separated. Keep in mind that other applications (built by other organizations) will also use your backend. Don’t trust data that Web Services receive. The data being returned should also be protected. Tracking of Web Service usages is also important. You can also think about using SOAP Extensions for this.
There are some the mistakes which are bound to happen when you work on web services. So, next time when you want to write web service, you know what should be avoided. J
If you are core web services developer using .NET 1.1 then following are some enhancements in .NET 2.0. You would find them interesting.
1. Network Information API
2. Auto Proxy Discovery
3. HTTP Response Compression
4. Supports Decompression
5. Supports SOAP 1.1 as well as SOAP 1.2
Cheers,
Amol
No comments:
Post a Comment