Web Services: Building Reusable Web Components with SOAP and ASP.NET
David S. Platt
This article assumes you’re familiar with XML and Visual Basic
Level of Difficulty 1 2 3
Download the code for this article: WebComp.exe(93KB)
Browse the code for this article at Code Center: TimeServiceDemo
SUMMARY XML and HTTP are cross-platform technologies especially suited for building applications that can communicate with each other over the Internet, regardless of the platform they are running _disibledevent=>Access will soon be built into nearly every program anyone ever writes. You won't use a generic browser, except when you feel like browsing generically. Instead, you will use dedicated programs that are optimized for accomplishing specific tasks. You won't be aware of the program's Internet access (except when it breaks).
An early example of this type of program is Napster, which allows you to search the shared hard drives of thousands of participating users for music files that meet specified criteria, and download the _disibledevent=>C++ or Visual Basic®? Which vendor is it from? Which version is it? Right now you can barely solve this problem _disibledevent=>words, when bytes are transferred from _disibledevent=>Machine in the form of a string, either with or without the seconds digits. You can download the sample code for this service from the link at the top of this article to follow this description more closely. You will need to download and install the Microsoft .NET SDK if you want to run it as well.
I wrote this Web Service in the form of an .asmx page to avoid distracting you with other software packages. I first installed the .NET SDK. Then I used the administrative tools in Microsoft Internet Information Services (IIS) to set up a virtual Directory pointing to the folder in which I would do my service file development. Then I wrote my ASP.NET code in a file called TimeService.asmx _disibledevent=>Java-language geeks often refer to physically cutting and pasting code as editor inheritance.
The WebService class is provided by the new .NET runtime library, just as many objects used in Visual Basic 6.0 were provided with the operating system. WebService contains all the prefabricated plumbing required to handle the incoming HTTP requests and route them to the proper methods _disibledevent=>FrontPage® 2000 to write a form that does this. A screen shot is shown in Figure 9, and the HTML code in Figure 10. The file is provided as GetTimeThroughHttpPost.htm. When the request reaches the server, ASP.NET creates the TimeService object, pulls the parameters from the form's controls, and calls the GetTime method.
Figure 9 Sending a Request via HTTP POST
Case 3: SOAP
The Web Service will accept an incoming call request via an HTTP POST request that has all of its information encoded in a SOAP packet. SOAP is an XML vocabulary that describes function calls and their parameters. Newcomers to SOAP will probably benefit from reading "Develop a Web Service: Up and Running with the Soap Toolkit for Visual Studio" in the August 2000 issue of MSDN Magazine, and A Young Person's Guide to the Simple Object Access Protocol in the March 2000 issue.
The portion of the SDL file describing my Web Service's support for the HTTP POST operation is shown in Figure 11. I've written a sample program, shown in Figure 12, that uses SOAP to call the GetTime method of the Web Service. It uses the Microsoft Internet transfer control to do the actual HTTP communication. Note that, unlike the previous two examples where the URL pointed at the method within the service, SOAP encoding is directed to the .asmx page containing all the methods of the Web Service. The SOAP packet sent to the server contains the name of the function and its parameters, encoded in XML according to an agreed-upon schema, as you can see in the top edit control. When the SOAP packet reaches the server, ASP.NET recognizes it, parses the method name and its parameters out of the packet, creates the object, and makes the call.
Figure 12 Soap Client
The XML encoding of the request packet varies somewhat from that used by the SOAP Toolkit Rob Caron discussed in his August 2000 article and the examples that come with it. SOAP and .NET are currently very much under development, so this type of divergence is _disibledevent=>VB /path:timeservice.sdl
The Visual Basic-based proxy code is shown in Figure 13. It contains both synchronous and asynchronous versions of functions for getting the time from the Web Service. I'll discuss the synchronous version here, and the asynchronous version in the next section. The proxy class inherits from the base class System.Web.Services.Protocols.SoapClientProtocol (you're going to have these long names, so get used to them), which contains the actual code. The proxy class contains a property called Path, which the proxy inherits from the base class. This property specifies the URL of the server to which the call is directed. It contains a default value that it got from the original SDL file, but the sample program demonstrates how you can change it at runtime if you want. The client calls the named method _disibledevent=>Codebehind="WebService1.vb"
Class="VS7DemoTimeService.WebService1" %>
The Codebehind attribute tells it where to find the code that backs up the service.
The file globals.vb is where event handler functions live that handle project-wide events, such ApplicationStart and ApplicationEnd. You put your own code in these functions, and ASP.NET will call it when the specified event takes place. The file globals.asax is the connection between these files and ASP.NET.
When you build your project, Visual Studio.NET automatically publishes it to the Web server you specify (in this case, the system default). To test the Web Service, simply start the debugger from the Visual Studio.NET main menu. It opens a testing page similar to the _disibledevent=>office that dispenses maps _disibledevent=>sql server™, do similar things.
It's usually best to perform authorization checks as early in the access process as possible, so that if they fail, you've wasted the minimum amount of processing time. Your Web Service object can perform its own authorization via the intrinsic object named User. This contains a method called IsCallerInRole, which will tell you whether the user is a member of an administrative group you've set up elsewhere. It is conceptually identical to the similar method seen in COM+. If you want to go deeper, you can use the Identity property of the User object. This returns an IIdentity interface, which tells you the user name and authentication mechanism used to verify that user name. You can write your own code that uses that information to decide if the user is allowed to do this or that.
Web Services will, at some future time, support Passport authentication and cookie-based authentication, which would make many lives easier. That is beyond the scope of this article.
Conclusion
All programmers would like to write programs that talk to each other over the Internet, no matter what type of system they're running on. You can accomplish this by settling on the lowest common denominator of XML and HTTP. The Web Services portion of the Microsoft .NET technology suite makes it easy for you to write your business logic in the form of .NET components and expose them to all Web clients that speak HTTP GET, HTTP POST, or SOAP. That's just about everyone in the world. An SDL file, also generated by the Web Services infrastructure, provides a machine-readable description of the functionality available through the Web Service. A proxy generator provides function-based access to a Web Service, making it easier to write client programs. Visual Studio.NET provides a productive environment for developing Web Services. The Web Service infrastructure provides several options for setting up the security required by a Web app. These tools allow you to write better Internet applications much more quickly—a good combination.
--------------------------------------------------------------------------------
For related articles see:
Visual Studio.NET: Build Web Applications Faster and Easier Using Web Services and XML
P2P: Writing Peer-to-Peer Networked Apps with the Microsoft .NET Framework
--------------------------------------------------------------------------------
David S. Platt is president and founder of Rolling Thunder Computing Inc. He teaches COM and COM+ at Harvard University and at companies all over the world. He publishes a free e-mail newsletter on COM+, available at http://www.rollthunder.com. David is the author of Understanding COM+ (Microsoft Press) and an upcoming book introducing the Microsoft .NET Platform, due in Spring 2001 (Microsoft Press).
--------------------------------------------------------------------------------
From the February 2001 issue of MSDN Magazine.
Get it at your local newsstand, or better yet, subscribe.
Back to top
最新评论