Programming with Microsoft Visual C++.NET 6ed [Electronic resources] نسخه متنی

Web Services

Most of this chapter has focused on using .NET as a tool for creating user-interface-based Web sites for human consumption. However, there's another use for the Internet on the horizon: programmable Web sites, also known as Web services.

COM and the Common Object Request Broker Architecture (CORBA) failed to connect the world together because DCOM and CORBA use very specialized connection protocols. As the Internet has evolved, it's become obvious that HTTP is a ubiquitous connection protocol, available on almost any device from desktop PCs to laptop computers, phones, and PDAs. The idea behind Web services is that a Web site can intercept more than just requests for HTML snapshots—it should be able to receive a SOAP request (specially formatted XML), map the contents of the request to a call stack, and execute the specified methods.

Web services will be big in the coming decade because they'll streamline business communication using common standards. Previous attempts at automating business communications and services (most notably Electronic Data Interchange, or EDI) failed for various reasons. One of the most problematic issues facing classic business communication automation was agreeing on the format for exchanging data. Web services rely on XML, which is widely understood by many computing platforms. When businesses need to communicate programmatically (to order supplies, for example), they can send a SOAP request to a Web site run by one of their suppliers. ASP.NET is probably the easiest way to create a programmable Web site.

Web Services Using Managed C++

Visual Studio .NET offers a wizard for generating managed C++ Web services. Example Ex34d shows how a managed C++ Web service provides calculator services over the Internet. Visual Studio .NET generates the required source code and sets up a virtual directory for your Web service.

There are three main parts to a managed C++ Web service: a header file, a source code file, and an ASMX file. Let's take a look at the header file first. Here's the listing for the default class (named Class1) generated by the wizard, with Add and Subtract methods included:

// Ex34d.h
#pragma once
#using <System.Web.Services.dll>
using namespace System;
using namespace System::Web;
using namespace System::Web::Services;
namespace Ex34d
{
public __gc 
class Class1 : public WebService
{
public:
[System::Web::Services::WebMethod] 
String __gc* HelloWorld();
[System::Web::Services::WebMethod] 
int Add(int x, int y);
[System::Web::Services::WebMethod] 
int Subtract(int x, int y);
};
}

The most important part of this listing is the WebMethod attribute that precedes the function definitions. HelloWorld (added by the wizard) and Add and Subtract are all declared as WebMethods, which means they'll be exposed to the outside world as Web services. Here's the listing for the implementation file for Class1:

#include "stdafx.h"
#include "Ex34d.h"
#include "Global.asax.h"
namespace Ex34d
{
String __gc* Class1::HelloWorld()
{
// TODO: Add the implementation of your Web Service here
return S"Hello World!";
}
int Class1::Add(int x, int y)
{
return x+y;
}
int Class1::Subtract(int x, int y)
{
return x-y;
}
};

While these methods are admittedly simplistic functions, they'll do nicely to illustrate how Web services work. Notice that at this point, programming Web services is much like writing a component that will run on your desktop. The last piece of the ASP.NET Web service is the ASMX file (M standing for method). In this case, the listing is very short. It's only job is to tie the Web service to the Class1 listed earlier:

<%@ WebService Class=Ex34d.Class1 %>

The WebService directive directs ASP.NET to use Class1 to run the Web service. Now that the Web service is available, how do you call it? By finding out the capabilities of the Web service through Web Services Description Language (WSDL).

WSDL and ASP.NET

Clients understand the services available from a Web service by reading WSDL. To get a copy of a Web service's WSDL code, an ASP.NET client requests the service's file (the ASMX file) and passes WSDL in the query string. Figure 34-8 shows a browser surfing to Ex34d and asking the service for its description.

Figure 34-8: WSDL code generated by Ex34d.

Once you get the WSDL for a Web service, it's easy to write a client proxy to call the Web service.

Invoking Web Methods

There are a couple of ways to create a client-side proxy for a Web service. One way is to create a Web reference using Visual Studio .NET. When you create an application using Visual Basic .NET or C# (which is beyond the scope of this book), you can right-mouse-click on the project in Visual Studio Solution Explorer and then choose Add Web Reference from the shortcut menu. You basically point Visual Studio to the URL that's hosting the Web service you're interested in, and Visual Studio will create a proxy for you that hides all the details behind the underlying SOAP call.

The other way to create a proxy is to use the WSDL command-line tool and feed it the WSDL for the service you're interested in. Here's the command line for generating a proxy for the Ex34d Web service:

WSDL /language:CS Ex34d.wsdl

The WSDL tool generates C# code. (You can ask it to generate JScript or Visual Basic .NET source code as well.) You can compile the source code into an assembly and start calling the Web service right away. Because the resulting assembly is a common language runtime assembly, you can easily call it from some managed C++ code.