Exposing Objects Through Web Services

The next level the new wave that's all the rage is Web Services! Actually, the premise of using the Web as a way to transfer data between two points was one of the original concepts that drove its development. This concept had several limitations, though, and only recently have the governing bodies such as the World Wide Web Consortium (W3C) started to implement standards for such technology. Implementation of Web Services in .NET is based on these standards and brings with it the chance to use XML to identify generically and send data from Point A to Point B or Point B to Point B (B2B joke, sorry).

The business case for creating Web Services is a simple premise that has many practical complications. The basic need for Jones Novelties, Incorporated, is to be able to allow other companies to access data quickly and in a manner that doesn't require them to create a user interface to access that data Web Services are perfect for this task.

Before going further, you need to be aware of a few things regarding the technology of Web Services. If you're already a pro, you may want to skip the next few paragraphs or read them anyway as a refresher.

Web Services, by definition, are objects that exchange data via an Internet protocol, such as HTTP, using XML to define either data or a set of instructions for the server to perform. These instructions may or may not include the return of data. For example, you may send a request to a Web server that is hosting a Web Service that looks like

http://www.someserver.com/services/dataserver.asmx?op=AddUserToDB&F

Name=John&LName=Doe.

In this case, we're using HTTP protocol and a GET request to call a service called dataserver that has a function AddUserToDB that takes the parameters FName and LName. Presumably, this function is adding a user to a database. It would be great, though, if we had a way to access a Web Service and have it tell us everything that it did. Luckily for us, Microsoft and others have thought of this possibility and created the Web Services Description Language (WSDL, pronounced "wiz-dull"). WSDL looks at the code in a Web Service and determines what it should tell users (human or otherwise) about the Web Service and what it does. We present an example of this function later, in the Accessing Web Services Programmatically section.

As stated, a Web Service can be accessed via the HTTP commands GET and POST. The main difference between GET and POST is that the data appended to the request is in the form of a query string for a GET request and encapsulated in the body of a POST request. Additionally, the Simple Object Access Protocol (SOAP) can be used to communicate with Web Services.

SOAP is a protocol that allows messages to be exchanged between servers via an envelope. Within this envelope are the instructions for the request. With SOAP, the envelope is specifically crafted XML as, for example,

 <?xml version="1.0" encoding="utf-8"?>  <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd=http://www. w3.org/2001/XMLSchema xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">   <soap:Body>     <ShowGetRowCountResponse xmlns="http://localhost/">   <ShowGetRowCountResult>int</ShowGetRowCountResult>     </ShowGetRowCountResponse>   </soap:Body> </soap:Envelope> 

To send a request such as this, you would need to create your own Web request and send it to the server. Fortunately, .NET provides ample functionality to handle this task in the System.NET namespace.

In an attempt to demystify, yet not understate, Web Services, you can look at them like this:

You have a database with the names of 100,000 people all aged 14 21. This data is kept up to date constantly by visitors to your Web site answering the "Question of the Day." One day, Pepsi gives you a call and wants to tap into your database for, say, $1,000,000 a month. How do you get Pepsi the data? This is where Web Services can come into play.

Another scenario may look like this:

You're running a Web site that offers authentication functionality to other Web sites. They pay you a monthly fee and send you the username and password from a Web page that sets cookies on clients, indicating whether the users were authenticated. Sounds a lot like Passport, doesn't it? Here again is an excellent opportunity to use Web Services.

Web Services gives a developer a way to expose functionality over the Web (Internet) or an internal network (intranet) that resides on the same or different machine from any other applications and/or databases that the developer may or may not know about. Web Services are what COM was supposed to be, but we can call Web Services from any machine connected to the Internet or internal network on any operating system.

Enough hype, let's take our component and add a function or two to it and see what happens.

Exposing an Existing Object Through a Web Service

It just doesn't get much easier than this. In most cases, we can expose the existing functionality of a component through a Web Service by simply placing code in the Web Service that exposes the method as public and has a return type. For example, consider our lowly GetRowCount object. To expose the GetRowCount method of the GetRowCount class through a Web Service, complete the following steps.

1. In the Novelty1 project, create a new Web Service, NoveltyServices.asmx.

   Note

   If you're in a different namespace and need to set a reference, see the Using the Component from Another Application section earlier in this chapter.

2. In the .asmx file, create a new WebMethod, ShowGetRowCount, that returns an integer. If you're unsure how to do so, refer to the code shown in Listing 12.8.

3. Add the three lines of code in the function ShowGetRowCount() in Listing 12.8.

4. Right-click on the solution name in the Solution Explorer and select Build.

5. After the build is complete, right-click on the NoveltyServices.asmx file and select View in Browser.

6. Once the browser has loaded the page, click on the ShowGetRowCount hyperlink at the top of the page.

7. View the results.

Listing 12.8 NoveltyServices.asmx.vb

 Imports System.Web.Services Imports Novelty1.GetRowCount <WebService(Namespace:="http://localhost/")> _ Public Class NoveltyServices      Inherits System.Web.Services.WebService #Region " Web Services Designer Generated Code "   Public Sub New()   MyBase.New()   'This call is required by the Web Services Designer.   InitializeComponent()   'Add your own initialization code after the   'InitializeComponent() call.   End Sub   'Required by the Web Services Designer   Private components As System.ComponentModel.IContainer   'NOTE: The following procedure is required by the Web Services   'Designer.   'It can be modified with the Web Services Designer.   'Do not modify it with the code editor.   <System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent()      components = New System.ComponentModel.Container()   End Sub   Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)     'CODEGEN: This procedure is required by the Web Services     'Designer.     'Do not modify it with the code editor.     If disposing Then       If Not (components Is Nothing) Then     components.Dispose()       End If     End If     MyBase.Dispose(disposing)   End Sub #End Region   <WebMethod()> Public Function ShowGetRowCount() As Integer     'These three lines of code haven't varied much.     Dim GRC As New GetRowCount()     ShowGetRowCount = GRC.GetRowCount     GRC.Dispose()   End Function End Class 

It really is that simple. Assuming that you had placed this code on a public Web server, anybody with a Web browser could navigate to the page and execute the functionality. More likely than not, though, accessing this code over the Web would be done programmatically. Let's see how that works.

Accessing Web Services Programmatically

The final level in this process is being able to use your program code to access a Web Service and use its functionality from within your application be it WinForms or WebForms.

Most of how to connect an application to an existing Web Service is taken care of when you create a Web reference so that's what we look at first. Recall that there are many ways to use this connection. Your request could be a simple HTTP GET request, which is usually a URL followed by a question mark (?) and ampersand delimited parameters such as

http://search.yahoo.com/bin/search?p=VB.Net

The request may be an HTTP POST request, whereby the parameters are passed in the HTTP headers. Another popular option is the Simple Object Access Protocol whereby specially crafted XML is sent to the Web server and the XML returned by the Web Service is sent back in a container established by the SOAP request.

You can also create a new Visual Studio.NET Visual Basic.NET Console Application. The console is quite basic and, as yet, we haven't used it. The principle, though, applies to any type of project. Once you have created your project, right-click on the References element in the Solution Explorer, and select Add Web Reference. You will get a dialog similar to that shown in Figure 12.1. If necessary, simply replace the URL shown at the top of the dialog and press Enter. You should momentarily have the results shown in Figure 12.1. These results are made possible by the Web Services Description Language, which embeds metadata in the code of the Web Service that describes its contents. Click on Add Reference and the dialog will close. In the Solution Explorer, you should now be able to see that the reference has been added as a Web reference, similar to that shown in Figure 12.2

Figure 12.1. Add Web Reference dialog

Figure 12.2. Web references in Solution Explorer

Note

Should the directory or Web server require any sort of authentication, that code must be present in your application and not in the Web Service.

Now that your Web reference has been added, you're just three lines of code from having an executable application that uses functionality across the Internet as if it were local. Listing 12.9 shows the entirety of ConsoleApplication1, Module1.vb.

Listing 12.9 Module1.vb

 Module Module1   Sub Main()     Dim GRC As New localhost.NoveltyServices()     Try        System.Console.WriteLine(GRC.ShowGetRowCount.ToString)        GRC.Dispose()     Catch        System.Console.WriteLine(Err.Description)     End Try   End Sub End Module 

Here, GRC is dimmed as localhost.NoveltyServices. The reason is that the server hosting the functionality in this example is named localhost. It is also the namespace set in Listing 12.8 as the namespace for the Web Service. Namespaces should be either something unique (such as the name of your company) or the fully qualified domain name that the server hosting the functionality will have. For example, if you were at Microsoft, the namespace you might use would be www.microsoft.com. Then, when someone needed to access your Web Service from his code, he would declare an object as

 new www.microsoft.com.objectname  

Again, once you have the code in place for module1 and the Web reference set, right-click on the solution name in the Solution Explorer and select Build. To execute this program, use a command window (DOS Prompt) to navigate to the directory where the application exists. By default, it will be

c:\documents and settings\<username>\My Documents\Visual Studio Projects

From there, there will be a directory with the name you gave the console application and within that directory will be a bin directory. It contains the .exe file that is your application. From the command prompt, type the filename of the application including the .exe extension and press Enter. Within a few seconds, you should see a number representing the number of rows in the tblCustomer table of the Novelty database.