Creating .NET Web Services Step 5

Step 5 - Show it Off
Congratulations are in order, for you have now built your first fully-fledged .NET XML Data Web Service, without any IDE program such a VS .NET I might add, and using a tool as simple as Notepad. Now can anyone really say this was a big ordeal? I didn't think so.
Additionally, if you're wondering how anyone else will "discover" your Web service, then look no further: with the XML Web service "discovery", you can advertise your Web service and expose its location and other information, alongside a .discomap file providing links to your files.

XML Web Service discovery, called DISCO for short, is Microsoft's Web Services Discovery tool. It "discovers" the URL for a Web Service and saves that information in a file on your local server. Here's how:
disco http://localhost/suppliers.asmx?DISCO
This creates a static discovery file containing a WSDL file with all the important information pertaining to your Web Service. Opposite this static discovery file is a dynamic discovery .vsdisco file, which notes all the available Web Services located within that URL.
Remember from Step 2 the WSDL command for creating the source file with "?WSDL"? Now, for an already "discovered" file, you can use:
wsdl.exe /l:CS /n:WService /out:bin/GetSuppliers.cs http://localhost/suppliers.wsdl
to create your source file and, in turn, your DLL for Web Service access.
When you examine the created .disco file you'll notice it includes the following information:

<contractRef ref="http://localhost/suppliers.asmx?wsdl" docRef="http://localhost/suppliers.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
This contains the link to your Web Service so others can discover it, alongside XSD schemas, and service descriptions. Using this information others can parse the WSDL document, build a proxy source file, and implement this Web Service locally!
If you do have something you'd like to share, run over to the Microsoft UDDI (Universal Description, Discovery and Integration) Business Registry (UBR) node at http://uddi.microsoft.com, which is currently supported by Microsoft, IBM and Ariba. Here you can find other available Web Services and their details, register your Web Service, and discover more about this whole business.
A little "Asynchronousity"
Before, I conclude this article I need to mention an additional method of calling Web Services from your application. Web Services by default form are called “synchronously”. As a result, both the application and its inherent Web Service will have to finish simultaneously. As such, a quicker method within the application will have to wait for any slower one to finish, before the application can fully display its results, potentially creating an unnecessary delay for the client. Likewise, since Web Service calls make use of Port 80 for communications, they can at times cause this type of delay. How would you be able to remedy such a situation? With a little asynchronousity, of course!
There are four common ways to make asynchronous method calls. Here we will demonstrate waiting for our asynchronous call utilizing the WaitHandle method, which determines when the service call is complete. The other three possible methods for asynchronous calls include:
The IsCompleted property of the IasyncResult returned by BeginInvoke, within our BeginSuppliers Method
Executing a callback method when the asynchronous call finishes
Finally, parallel any processing or code until the call completes prior to calling EndInvoke
Given that asynchronous calls can perform a given task without affecting other functions around them, let's implement our chosen technique. Going back to Step 2, you'll remember how we created our proxy class file for our .asmx Web Service file.
If you took the time to inspect it, you will have noticed that, aside from our main ShowSuppliers Dataset function, two additional functions were listed: BeginShowSuppliers and EndShowSuppliers. These are the asynchronous functions that will enable us to produce asynchronous Web Service calls implementing the WaitHandle Class’s WaitOne() Method, and here's how.
We do all this from the .aspx page we created in Step 4. Here's the additional code:
//Instantiate DLL GetInfo supInfo = new GetInfo();
// Begin the Asynchronous call to ShowSuppliers IAsyncResult AsyncWS = supInfo.BeginShowSuppliers(Catg, null, null);
//We wait for the callback AsyncWS.AsyncWaitHandle.WaitOne();
//We return the data bypassing the initial ShowSuppliers Method DataSet MyData = supInfo.EndShowSuppliers(AsyncWS);
Notice that just a few more lines of code were added. The only thing that changed was that we added our asynchronous methods right after we instantiated our dll. After this, we create an instance of the IasyncResult object that will let us know when the Web Service process has finished.
IAsyncResult AsyncWS = supInfo.BeginShowSuppliers(Catg, null, null);
Here, we called the asynchronous BeginShowSuppliers method that accepts our initial dropdown list parameter and two other mandatory arguments that, in this example, were not included, and were substituted with null. The second argument would typically call the AsyncCallBack object responsible for calling another method once the BeginShowSuppliers completes, contrary to our example. The third argument would contain information about the asynchronous operation.
We then next implement the AsyncWaitHandle that allows us to incorporate and handle different kinds of synchronization techniques. There are a few AsyncWaitHandles available to us. With the WaitOne method included below, we wait for the WaitHandle to receive a callback signal. Further available methods include: WaitAll(), which waits for all elements to receive a callback signal, and WaitAny(), which waits for any one of the elements to receive a callback signal. Both utilize specified arrays as one of the overloaded element arguments, alongside an Integer for specific time interval waiting, and/or Timespan as well. In any event, all WaitHandles have available to them multiple overload forms that can be further viewed in the .NET SDK documentation.
//We wait for the default callback AsyncWS.AsyncWaitHandle.WaitOne();
A quick digression regarding the line above: although our WaitOne method as shown in default form will work fine, it can be overloaded. To illustrate, our WaitOne Handler, once overridden in a derived class, will block the current thread until the current WaitHandle receives a signal. The two arguments it allows, paralleling what the other two Wait methods also accept, are:
waiting for a set number of milliseconds to pass, and
a Boolean value, true or false, specifying whether to exit the synchronization domain before the wait.
Once the wait is over, we return our results via the EndShowSuppliers method that got the OK from the WaitHandle.
The AsyncWaitHandle method being a resource releaser, OK'd our supInfo.EndShowSuppliers method below, and in turn obtained our data, without letting the rest of our application grow impatient.
//We return the data DataSet MyData = supInfo.EndShowSuppliers(AsyncWS);
Therefore, in coping with the possible speed limitations resulting from HTTP network traffic, we can implement our Web Service without any concern that the rest of our application will wait impatiently until it’s all completed. With some asynchronous"ity,” our application will run its entire course, in conjunction with our possibly leisurely Web Service, simply jumping in when it's finished.
In summing up, our BeginShowSuppliers method, once initialized, returns instantly (though not in this case, as we used the WaitHandler) to notify your applicable callback function that the process is done, and it's OK to call the EndShowSuppliers method and return the results.
And there you have it: a quick look at Asynchronous Web Services. As you may have wondered, yes, this can get far more complex than what we’ve discussed. Nevertheless, with the amount you have learned now, it should be a little less intimidating.
ConclusionRealizing how fast you can create a nice, functional .NET XML Data Web Service -- and an Asychronous one to boot -– should have put a smile on your face. Additionally, be sure to explore all the .NET documentation for greater detail on what was presented here for additional tweaking, implementing error handling, security, caching, and other aspects you should keep in mind when creating and consuming Web Services. There's plenty of stuff in the .NET documentation and online that goes into more detail about all this.
It's really quite easy to create and consume your own Web services, and to discover other available services over the Internet, and to consume and utilize them as if those applications reside on your local server! With each passing moment, .NET reveals itself to be a more truly amazing and extremely powerful platform. Until next time, happy .NETing!