asp:FeatureCompanion
LANGUAGES: VB
TECHNOLOGIES: Web Services | Visual Studio .NET
Architect Your Web Service
Learn to organize your methods and asmx files.
This is supplemental material to the article Web Service Essentials.
By Peter Vogel
You can add as many asmx files as you want to your Web Service project, and you can define as many methods for each file as you like. The question, then, is how should you organize your methods and asmx files? Should each asmx file contain a single method? Should all the methods for a service be in a single asmx file? Or is the solution somewhere in between?
The objects that comprise your Web Service will be created in response to a client request, and they'll be destroyed after servicing the request. As a result, even if a client makes several requests from your service, each request will be treated as disconnected and anonymous. This means you'll have no opportunity to share data between different requests by the same client - the typical reason developers put related routines in the same module.
If you do need to pass information between the various methods your client can call, you can store that information (at least, in theory) in the same place you would put it in an ASP project - in the Application and Session objects. The Application object works fine, but it is shared among all users of the Web Service so it isn't helpful for handling a single client. On the other hand, the Session object is designed for use by a single client.
In order to use the Session object in a method, you must enable session state through the EnableSession property on your WebService attribute:
<WebMethod(EnableSession:=True)> _
Public Function AddOne() As Integer
Unfortunately, this works only if the client also enables cookies explicitly. The code on the client side must create an instance of a CookieContainer object for the proxy that manages the Web Service:
Dim ms As localhost.MathServices
ms = New localhost.MathServices()
ms.CookieContainer = New System.Net.CookieContainer
Although creating multiple asmx files might result in performance implications, the only real restriction on dividing your code among asmx files is you should keep any support routines required by a Web Service method in the same asmx file as the method itself. And even then, if several asmx files share a routine, you should place the routine in a separate component that can be instantiated from whatever method needs it.
So the correct answer is to set up your asmx files to organize your code logically and reduce your maintenance costs. For instance, if your Web Service is composed of thousands of lines of code, putting all that code in a single asmx will make maintaining the service more difficult. Instead, organize that code into meaningful groups to make your code easier to find. As a bonus, developers accessing your service will better understand the functionality you're providing.
Peter Vogel is a principal in PH&V Information Services. He has designed, built, and installed intranet and component-based systems for Bayer AG, Exxon, Christie Digital, and the Canadian Imperial Bank of Commerce. He is editor of the Smart Access and XML Developer newsletters and author of The Visual Basic Object and Component Handbook (Prentice Hall), which is being revised for .NET,; and he presents information at conferences around the world. E-mail Peter at mailto:[email protected].
