- Common Language Runtime
- Core Classes
- NET
- A PriceCheck Client in .NET
- Exposing .NET Web Services: Package Tracking for SkatesTown
This chapter is from the book
This chapter is from the book
This chapter is from the book
Exposing .NET Web Services: Package Tracking for SkatesTown
Okay, so building clients in .NET is pretty simple. What about exposing services? Luckily, with ASP.NET, it's even easier. (For you Windows 98 folks out there, sorry—this section won't work for you. .NET's server-side components are strictly for Windows 2000 or later. If you want to try the example, please make sure that you install the .NET server side components plus all prerequisites.)
Let's bring our attention back to SkatesTown for a minute for this example. For some months now, SkatesTown has been using ShipIt, Inc., to send its packages. All the shipping has happened behind the scenes, but some customers have (quite reasonably) been asking for the ability to get tracking numbers for their shipments. We'll walk you through a simple version of what ShipIt might do on its .NET-based system to provide this feature to SkatesTown.
We'll simulate the package-tracking application in .NET by building an .asmx file. As you'll see, ASMX files are a lot like JWS files—they allow you to drop source code into a regular old text file and have the ASP.NET framework automatically compile and execute the code for you on demand. There are some differences, though.
For one thing, all ASMX files require a WebService directive at the beginning of the file, which tells the infrastructure what language the source code is expressed in and the name of the class that implements the actual service. ASMX files can use any of the supported .NET languages for Web services (right now that's C#, Visual Basic, and Jscript).
Another difference is that ASMX files automatically support an HTTP GET and POST binding as well as access via SOAP. This means that you can call an ASMX-based Web service with just a browser, passing arguments as query string parameters or form fields. Of course, this doesn't allow for the kind of rich data mapping you can do with XML, but it is handy for services that only deal in simple types.
Let's take a look at a simple service implemented as an ASMX file; see Listing 1. This service does two things. First, it generates new tracking numbers, which tie to instances of a PackageInfo class. Second, it returns a tracking report for an existing tracking number. (This example is not a real simulation of the situation—it has been vastly simplified to let us focus more on the Web service infrastructure and less on the application logic.)
Listing 1: C# Package Tracking Service in .NET
<%@ WebService Language="C#" Class="ShipIt.PackageService" %>
using System.Collections;
using System.Web.Services;
using System.Web.Services.Protocols;
namespace ShipIt {
// Here's the "PackageInfo" class which represents
// a package in transit.
//
public class PackageInfo {
static int maxHops = 4;
int hop = 1;
int trackingNumber;
string currentReport;
public PackageInfo(int id)
{
trackingNumber = id;
currentReport = "<h2>Tracking Report<h2> <ul>";
}
// Move a package one hop and update its
// tracking log. Don't bother if it has
// reached its destination.
public void movePackage() {
if (hop < maxHops) {
currentReport += "<li>Arrived at hop #" + hop + "\n";
hop++;
} else if (hop == maxHops) {
currentReport += "<li>Delivered!\n";
hop++;
}
}
public string getTrackingReport() {
return currentReport + "</ul>";
}
}
[WebService(Namepace="http://BWS-ShipIt.com/")]
// This is a SOAP RPC service
[SoapRpcService]
public class PackageService : WebService {
static int lastTrackingNumber = 1;
static Hashtable trackedPackages = new Hashtable();
[WebMethod]
public int getTrackingNumber() {
PackageInfo pi = new PackageInfo(lastTrackingNumber);
trackedPackages.Add(lastTrackingNumber, pi);
return lastTrackingNumber++;
}
[WebMethod]
public string getTrackingReport(int trackingNumber) {
PackageInfo pi =
(PackageInfo)trackedPackages[trackingNumber];
if (pi != null) {
// For the sake of example, we move the package
// one "step" each time this is called.
pi.movePackage();
return pi.getTrackingReport();
}
return "No such tracking number!";
}
}
}
We have a C# class; this is nothing new. But the text in the square brackets ([]) is different; these directives tell the runtime any metainformation that we need to convey. In this case, we're marking each method that we would like to publish as a [WebMethod]. This tells the runtime that the marked methods are accessible via Web service interfaces from outside and should be included in a WSDL description of the service. There is also a [SoapRPCService] directive at the top of the class. It indicates that our class is a SOAP service that uses section 5–encoded payloads and the SOAP RPC style. By default, all .NET services are document-oriented and use literal encoding. The [WebService] directive just above that one allows us to specify the namespace of the service (this will be the namespace of the body elements for the service requests and responses).
The getTrackingNumber() method creates a PackageInfo object and inserts that PackageInfo into a hashtable, indexed by an integer tracking number that we return to the user.
When generateTrackingReport() is called, we first look up the PackageInfo that was previously stored. Then, for the purposes of this simple example, we call movePackage() to move the package one hop along the path to its destination. Clearly, in the real world, getting a tracking report for a package does not actually move it closer to its destination (much as we might wish otherwise), but this is a quick and easy way for us to simulate movement. Once the PackageInfo has been moved, we simply return the tracking report generated by the PackageInfo class.
To deploy this service, just drop it into your Web hierarchy. For our purposes, we've put it in Inetpub\wwwroot\shipit\PackageService.asmx. Figure 2 shows what happens if we hit it with a browser.
){kind=link}
Figure 2 Browser view of .NET Package service URL.
This page is automatically generated for us by .NET, and it allows us to not only see what methods are available, but also to actually test the methods in the browser. You can try this out by clicking the method names to get a page that looks like Figure 3.
){kind=link}
Figure 3 Expanded view of the getTrackingReport method.
You'll find the source code to this service in the dotnet/ directory of the examples. If you deploy this service to the location shipIt/PackageService.asmx on your machine (in other words, drop the file in IIS under wwwroot/shipIt/packageService.asmx), you'll be able to try an example that integrates this service into SkatesTown's order processing system. Just bring up the modified order page, submit the request, and you'll get a package tracking number along with your invoice (see Figure 4). Clicking the tracking link will get you a package tracking report.
){kind=link}
Figure 4 PO results with package tracking.
We encourage you to examine the Java source for the tracking page (track.jsp) to see how this works; as usual, we've just got a JSP front end that calls a remote Web service. The only difference is that, for this one, the service is provided by .NET—interoperability in action!
The modified POSubmissionClient class is also worth a look; it works exactly the same way as we've traditionally been writing this class for our examples—in particular, it doesn't expect the SOAP body (the returned invoice) to change in order to carry the tracking number. Rather, we do that by introducing a SOAP header that is plucked out by the client.
The header is produced by a modified version of the POSubmission service—TrackingSubmission.java, which you'll find in com/skatestown/services alongside the normal POSubmission class.