Building and using Web Services with ASP.NET
There are many ways of looking at Web Services but only one definition that fits perfectly. Web Services are programmable application logic exposed over the Web. One could choose to place more emphasis on the SOAP protocol rather than the UDDI specification. Others could prefer the WSDL description language in lieu of the facilities of the .NET platform, or particularly appreciate the platform neutrality
of the design.
Whatever your preferred way to look at Web Services, you cannot do without the basic three points explained in this session; what a Web Service is, how to go about building one and creating Web
Service clients.
The target audience for this talk was certainly not a high-level one. The ideal attendee was one with only a faint idea of what a Web Service is, and maybe not even that. The presentation moved along quite well, with a couple of breaks to accommodate demos.
As mentioned above, the answer to the first point was, "a Web Service is programmable logic that you expose from your
web site using a standard protocol to publish callable methods and to invoke them."
The speaker used Visual Studio.NET with the C# language to build a simple Web Service. This consisted of a single HelloWorld method that returned, you guessed it, the ‘Hello world’ string. However, a Web Service is a plain text file so you could even edit it with Notepad. Once the .asmx Web Service file has been saved and the [WebMethod] attributes fully defined
(exposing the underlying methods) it was about time to see how it works in practice.
At this point, the facilities offered by the .NET platform come in handy. When you double-click on an .asmx file, a dynamically generated HTML page pops up with lots of information about the Web
Service, with buttons to run all of its Web public methods. The invocation in this case goes through the HTTP-GET protocol, which is not the best way to work with a Web Service. Both HTTP-GET and HTTP-POST protocols have limited type support, restricting you to some primitive types. Using SOAP you can employ classes and some complex data types, although you must first create a proper client application. Again, here's where the .NET facilities reveal their usefulness.
Both visually through Visual Studio.NET and manually through the wsdl.exe utility, you can generate a new C# or Visual Basic.NET class that wraps all the public functionality of the Web Service. The client .NET application then just invokes the methods of this class to obtain the services of the Web module. While generating the wrapper class you can specify the protocol for physical byte transportation – SOAP by default.
A couple of interesting things were pointed out during this session, including the importance of replacing the default http://tempuri.org namespace at the end of the development cycle. A Web Service is expected to define a unique namespace and, as you can guess, such a default string is not a great guarantee. The second thing is that a .NET client can invoke a Web Service both synchronously and asynchronously. The code to do this is automatically generated as part of the wrapper class that wsdl.exe generates for you when you add a Web reference to your Visual Studio.NET project.
The final part of the session provided a quick description of the specifications that help to publish a Web Service. They work at three different levels. UDDI
is the Web yellow pages directory for Web Services. WSDL describes the contract for a given Web Service and details its methods and the various signatures. Finally, DISCO, or Discovery Of Web Services, is a discovery behaviour algorithm that presents the list of Web Services available on a given Web server.
Dino Esposito
|
|
