Writing a Web Service in Managed C

Writing a Web Service in Managed C++

Not surprisingly, Visual Studio .NET has a wizard to help you create a Web Service. Before you get started, make sure you have IIS running on your development machine. Your Web Service is going to need a Web server to run on. Choose File, New, Project to get started. Choose .NET Projects and then, on the left, select ASP.NET Web Service. Name the project Utilities .

Because a Web Service is implemented on ASP.NET, Visual Studio opens the file in design view. However, because a Web Service doesn't have a user interface, design view isn't very useful. Click the link labeled "click here to switch to code view" and examine the code that was generated for you. Unlike some of the other projects produced by code generators, the Web Service code is split between a header file and an implementation file. With the comments removed for space reasons, the header file looks like this:

 #pragma once using namespace System; using namespace System::Web; using namespace System::Web::Services; namespace Utilities {     public __gc         class UtilitiesClass : public System::Web::Services::WebService     {     public:       UtilitiesClass()       {          InitializeComponent();       }    protected:       void Dispose(Boolean disposing)       {          if (disposing && components)          {             components->Dispose();          }          __super: :Dispose(disposing);       }    private:       System::ComponentModel::Container * components;       void InitializeComponent()       {       }    public:         [System::Web::Services::WebMethod]         String __gc* HelloWorld();     }; } 

This header declares a class called UtilitiesClass with a constructor, a Dispose() method, and an InitializeComponent() method. These " boilerplate " methods rarely need editing by you. In addition, the class has a public method with a WebMethod attribute, and this method has been implemented in UtilitiesClass.cpp. That file, again with comments removed for space, looks like this:

 #include "stdafx.h"  #include "UtilitiesClass.h"  #include "Global.asax.h"  namespace Utilities {     String __gc* UtilitiesClass::HelloWorld()     {       return S" Hello World!";     } }; 

The HelloWorld() method is included only as an example. Remove it from both the header and the implementation files. In the header file, add these lines where the declaration of HelloWorld() was:

 [System::Web::Services::WebMethod] bool Factor(int i, double d); [System::Web::Services::WebMethod] bool Weekend(DateTime d); 

Each of these methods is decorated with the WebMethod attribute, which is what makes it a Web method. In the implementation file, add these lines where the implementation of HelloWorld () was:

 bool UtilitiesClass::Factor(int i, double d) {     int j = (int)( i / d);     return (j*d == i); } bool UtilitiesClass::Weekend(DateTime d) {     int dow = d.DayOfWeek;     return (dow == DayOfWeek::Saturday          dow == DayOfWeek::Sunday); } 

These functions are simple. Factor() divides the double into the integer, and then multiplies the result by the double again. If the result of that is the same as the original integer, the double is a factor. If not, it isn't. The last line of factor can be written more verbosely as

 if (j*d == i)     return true; else     return false; 

Condensing this to a single line has no impact on the performance of the application, but makes it simpler to read for experienced C++ programmers. Weekend() uses the DayOfWeek property of the DateTime structure, and compares it to two constants that are defined in the Base Class Library. It returns true if the day of the week is Saturday or Sunday, and false otherwise .

Build the solution and watch your output as the build progresses: You will see messages from the compiler and the linker, but then that familiar output is followed by something like this:

[View full width]

 
 [View full width] 
 Deploying the web files... Copied file from e:\Utilities\Utilities.asmx to c:\inetpub\wwwroot\Utilities\Utilities.asmx Copied file from e:\Utilities\Global.asax to c:\inetpub\wwwroot\Utilities\Global.asax Copied file from e:\Utilities\Web.config to c:\inetpub\wwwroot\Utilities\Web.config Copied file from e:\Utilities\Debug\Utilities.dll to c:\inetpub\wwwroot\Utilities\bin  \Utilities.dll Copied file from E:\Utilities\Debug\Utilities.pdb to c:\inetpub\wwwroot\Utilities\bin  \Utilities.pdb 

All of the files that are necessary to test and deploy your XML Web Service are copied to a folder where IIS can serve them over the Internet. As you can see, there's a tremendous amount of work being done for you. Not all of it is needed for such a simple service, but when you go to write a real service, you'll be pleased to have such simple deployment.

After the service is built, it should be tested . The deployment process created a folder on the default Web site of the target machine called Utilities, and added a file called Utilities.asmx to that folder. Open a Web browser and type in the URL to the .asmx file (on most machines http://localhost/Utilities/Utilities.asmx will workif you use a proxy server or if localhost doesn't seem to work for you, use your machine name or IP address instead). You should see a machine-generated description of your service, like the one shown in Figure 10.1. Alternatively, you can just run the project: Running a Web Services project runs a browser and loads the .asmx file into it.

Figure 10.1. The .asmx file serves the information about the Web Service.

The .asmx file was generated for you when the project was created. It contains only a single line:

 <%@ WebService Class=Utilities.UtilitiesClass %> 

This directs ASP.NET to load the class called UtilitiesClass in the Utilities namespace. The methods in that class are the Web methods offered by your Web Service.

Just as your class is in a C++ namespace, supported by the .NET Framework, so your Web Service can be in a namespace. That way if there are several Utilities Web Services, they can be distinguished. By default, your Web Service is in a namespace called tempuri.org, and when you load it, the browser reminds you that this should be changed to a real namespace before the application is deployed. To do so, add an attribute to the class declaration in UtilitiesClass.h, so that the class definition starts like this:

 [System::Web::Services::WebServiceAttribute(     Namespace=" http://gregcons.com/vcdotnetkickstart")] public __gc     class UtilitiesClass : public System::Web::Services::WebService { 

Namespaces for Web Services are generally based on domain names , because they are globally unique. There is no requirement that any particular server exist at the domain name you enter, or that the path following the domain name correspond to an actual path on the server. It's simply a way to construct a string that won't conflict with a string chosen by another developer. If you are building this application yourself, change my domain name ( gregcons.com ) to your own domain.

After adding the attribute, build and run the application again. The warning message about the Web Services namespace will be gone.

The Web page lists the Web methods offered by the Web Service: Factor() and Weekend() . The name of each is a link. Click the link for Factor and you'll see more details about it, and have an opportunity to call the service straight from the Web browser. Enter test values for i and d and click Invoke. A new browser window appears with the result, expressed in XML, of the Web method. For example, if you enter 3 for i and 1.5 for d , you see XML like this:

 <?xml version=" 1.0"  encoding=" utf-8"  ?> <boolean xmlns=" http://gregcons.com/vcdotnetkickstart" >true</boolean> 

The answer, true , is wrapped in a boolean element. The results from a Web Service call are always wrapped in XML for you. When you use a Web Service from an Visual C++ application, you don't need to write code to parse the XML and get the results; it's done for you. But this same Web Service can be used by applications written in any development tool or environment, in any programming language, on any operating system. All that's required is the capability to make an HTTP request of a specific URL, passing the parameters in the GET or POST , optionally wrapped in SOAP XML, and then to parse the XML that's returned from the Web Service. This is what makes Web Services a technology that changes the way software is built. They can be written in almost any language, and used from any language, without requiring any interaction between the environments beyond the most simple and generally availableto make an HTTP request, to build XML, and to parse XML to get the information it contains.