perfectxml.com: Learn to use XML in your applications

The Book of Visual Studio .NET by Robert B. Dunaway
The complete guide to developing applications with Visual Studio .NET.

ISBN: 1886411697
Published: September 2002
Pages: 450

This book surveys each .NET server and related technologies, with a focus on Visual Studio .NET. Hands-on examples cover building forms, data retrieval, moving to COM+, and implementing web services. Other key issues and solutions include upgrading from Visual Basic, source control services, and remoting.

Chapter 10 from The Book of Visual Studio .NET (ISBN 1886411697) by Robert Dunaway appears courtesy of No Starch Press. Available in fine bookstores everywhere or call 800-420-7240 or visit www.nostarch.com. Copyright © 2001 by Robert Dunaway.

Since the inception of the network and, more recently, the Internet, attempts have been made to allow programs to extend their functionality across machine boundaries. Several successful attempts have encompassed much of the distributed world, including Java RMI, CORBA, and DCOM, but they have tended to be both platform and language dependent.

A web service is a remotely accessible method in which data is stored in XML and transmitted over HTTP. In English, that means a web service method is accessible by clients while communicate using TCP/IP and understand XML. This includes nearly every programming platform available. The application service provider builds the web services and makes it available to client applications known as consumers.

In this chapter, you’ll learn about the industry accepted technologies that make cross-platform interoperability possible, and the underlying concept of web services.

Web Service Technologies

Web services are delivered using a combination of technologies. While Visual Studio .NET shields you from much of the complexities of these technologies, you should have a basic understanding of what these technologies are and how they work. If you work with web services for any length of time you will need to be able to modify some of the supporting files manually, just as a web developer might modify HTML pages after they are generated. So, let’s have a quick look at the basics of each underlying technology.

XML

XML is designed for ease of implementation and for interoperability with both SGML and HTML. XML (Extensible Markup Language) is a self-describing language that is stored and transmitted as a string. The ability to transmit XML as a string is significant because all programming languages and platforms understand how to handle a string, making XML ideal for passing between disparate systems. Figure 10-1 shows an example of how contact information might be stored in XML format. The plain English tags of XML (for example, <contact>, </contact>) make XML readable and easy to learn and understand.


<contacts>
	<contact>
		<name>Tamarah Dunaway</name>
		<phone>555-555-5555</phone>
		<email>td@myEmail.com</email>
	</contact>
	<contact>
		<name>David Hill</name>
		<phone>555-555-5555</phone>
		<email>dh@myEmail.com</email>
	</contact>
	<contact>
		<name>Sharon Hill</name>
		<phone>555-555-5555</phone>
		<email>sh@myEmail.com</email>
	</contact>
	<contact>
		<name>Zac Hill</name>
		<phone>555-555-5555</phone>
		<email>zh@myEmail.com</email>
	</contact>
	<contact>
		<name>Lindzee Hill</name>
		<phone>555-555-5555</phone>
		<email>lh@myEmail.com</email>
	</contact>
</contacts>

Figure 10-1: Contact information stored in XML format.

XML Schema

XML Schemas define the data schema of the data stored in the XML document and is a handy tool for further defining the data structure, data types, and constraints for XML documents. The data schema can be used by applications that understand XML to enforce data specific business rules such as data types.

This extended data definition (XML Schema) can reflect the underlying database, such as data types and rules, in an effort to validate the data before transmitting it. This will save both time and effort for developers because all data validation is defined in a single location as well as reduces unnecessary round trips for data that doesn’t transmit properly the first time due to data violations. As a result, an XML Schema is often referred to as a contract between exchanging partners because it defines what is (and is not) valid data.

XSLT

XSLT (eXtensible Stylesheet Language Transformations) is a language used to transform XML data into other XML data formats. For instance, two different companies store customer information but store different information for each customer. Transforming XML documents extends the usability of your XML document for other systems and devices by transforming XML data into a format that other systems use. XML documents can also be formatted, using XSLT, for display purposes.

HTTP

HTTP (HyperText Transfer Protocol) is an IP protocol used for transition. HTTP is the data transfer mechanism of SOAP, as well as Microsoft’s web services, although web services are not strictly defined as using HTTP as its sole form of transport. Other forms of transfer are available for web services, such as .NET Remoting; however, this is beyond the scope of this book. For additional information on SOAP and .NET Remoting, refer to Applied SOAP: Implementing .NET XML Web Services or MSDN online.

WSDL

WSDL (Web Service Definition Language) defines the interface and behavior of web services. WSDL allows remote developers to communicate with web services without necessarily contacting the developer of the web service. WSDL effectively decouples the web service consumer’s developer from the web service’s developer. Visual Studio .NET creates the WSDL for each Web Service.

UDDI

UDDI (Universal Description, discovery, and Integration) is like a DNS server for web services. A DNS server stores a list of domain names and associated IP addresses; when a request is made to the DNS server for the IP address of a specific domain name, the DNS server resolves the name to an IP address, and the client can connect directly to the desired domain.

The UDDI aids in the discovery of businesses that provide Web Services. Businesses use UDDI to publish Web Services so that consumers can find and consume the Web Services.

Eliminating Batch Processing Paradigms

For example, how many times have you suggested that a system might provide a better service to the customer if it were real-time, only to have a developer tell you that it can’t be real-time because it is based on a batch process of file transfers between disparate systems, followed by nightly processing of those files. While it is not necessarily true that the system cannot be modified to support real-time transactions, the batch process tends to be the hammer or the only tool available. Web services allow us to get rid of old batch processing paradigms and begin working toward more transactional based, real-time solutions.

Ability to Charge for Web Services

Another advantage of web services is the ability to charge for services rendered by your web service. If your web service provides a proprietary function that other applications wish to use, you can charge back to the customer a monthly service or even a transactional fee. Charge back options are truly endless and limited only by the imagination.

Web Service Hubs

Web services can also be combined to form hubs for other services offering greater flexbility in the way information is distributed. For example, as shown in Figure 10-2, one financial company might act as a hub for other financial services: The web services client would call each web service (such as Taxes, Loans, etc.), or talk only to the hub (the Financial Hub), while the hub communicates with the appropriate service on the client’s behalf.

Creating a Simple Web Service

Let’s create a simple web service to demonstrate several common tasks that must be performed on all new web services.

Create a new project using the "ASP.NET Web Service" application template under the "Visual Basic Projects" project types.
When creating the new project, change the web service name by replacing the location with the desired service name "FullName", as shown in Figure 10-3, which includes the namespace of the new web service.
Rename the "Service1.asmx" file, which is automatically added to the project, to "NameService.asmx".
Open the code window of the "NameService.asmx" file and replace the default class name with "FullName".
```
Public Class FullName
   Inherits System.Web.Services.WebService
```
Now, import the System.Text namespace at the very top of the code window for the NameService.asmx file.
```
Imports System.Text
```

Create a new web method with the following code that uses the StringBuilder class. (You imported the System.Text namespace so you could access the class more easily. If you hadn’t imported it you could have accessed the class with its fully qualified namespace, System.Text.StringBuilder.)

<WebMethod()> Public Function FullName(ByVal strFName As String, _
             ByVal strLName As String) As String
   Dim objStringBuilder As StringBuilder
   objStringBuilder.Append(strFName)
   objStringBuilder.Append(" ")
   objStringBuilder.Append(strLName)
   Return objStringBuilder.ToString
End Function

Add a description to our new web service as an attribute of the FullName with the web method’s class declaration statement:

<WebService(Description:="This web service returns a full name.", _
             Namespace:="http://tempuri.org/")> _

Public Class FullName

Compiling the Web Service

You can test the new web service without even a consuming application. To do so, press F5 to run the web method. The web service will first compile and then display a web page pointing to the "NameService.asmx" web service, as shown in Figure 10-4. The URL, http://localhost/FullName/NameService.asmx, contains the fully qualified namespace of the web service. As you can see in the figure, the browser window displays the name of the web service class, FullName, as well as a description of the class: "This web service returns a full name."

Finally, you’ll see the warning displayed in Figure 10-5. When creating a new web service a temporary namespace is supplied by default; this warning reminds you that you need to replace the default.

To replace this temporary namespace, return to the code window and replace "http://tempuri.org/" with "http://localhost/FullName/". Once you have a server on the Internet, replace "localhost" with your server’s real host name. Run the web service again and you’ll see that the warning is gone.

Viewing the WSDL

To see the WSDL for the web service, select "Service Description". You should see the screen shown in Figure 10-6.

Testing the Web Service

Now that you’ve compiled the web service and examined its WDSL, you should test it:

Press the browser’s Back button to return to our web service page then click the "FullName" hyperlink. You should see the test page shown in Figure 10-7. The test page, automatically generated by Visual Studio .NET, is the consumer of our web service.
Now enter a first and last name in the text boxes and then click Invoke. The result is an HTTP 500 – Internal server error, as shown in Figure 10-8.

Oops! Looks like you’ve got a bug. The page can’t be displayed.

Debugging our Web Service

Like many error messages this one tells you nearly nothing about what has gone disastrously wrong, so you’ll have to debug things:

Close the browser and return to the web service code page. Because the error message provides little information concerning the violation, you’ll place a breakpoint on the declaration line of the "FullName" web method, which will trigger once the breakpoint is reached.
Run the web service again and then enter a first and last name. Click Invoke. The break point will trigger, as shown in Figure 10-9, stopping execution, and allowing you to step through the code.
Step into the code by pressing F11. You’ll notice that while you declared "objStringBuilder" as a StringBuilder object, you never actually created the object in memory before referencing it. To correct this, replace the objStringBuilder declaration line with the following declaration and instantiation line.
```
Dim objStringBuilder As New StringBuilder
```
Remove the breakpoint and run the web service again. This time it should execute successfully, as shown in Figure 10-10.

Consuming the Web Service

Now that you’ve created and tested the web service, your job may be complete. However, in many cases, you are creating web services for consumption by your own applications. For instance, you may want to expose functionality to a Windows Form application that resides outside the company network.
(Historically, form-based applications could not communicate through a firewall because all but port 80 were often blocked. Because web services operate on port 80, this manner of distributed computing is made possible.)

The following sample application will consume the new web service:

Create a new Visual Basic "Windows Application" and name it "WinFullName."
Drag-and-drop the controls that are listed in Table 10-1 onto the Windows Form. (The end result should look similar to Figure 10-11.)

Adding a Web Reference to Access the Service

Before you can access the web service you must reference it from the consuming application. To do so, follow these steps:

Right-click on the "WinFullName" project and select "Add Web Reference".
Enter the URL of the web service in the "Address" text box and press enter. A screen should appear similar to Figure 10-12. Press "Add Reference."
Right-click on "localhost" under Web References and rename it to "WSFullName". (This allows you to couple the code loosely in the client with the web service. If you ever choose another web service provider for your client, all you need to do is change the reference.)

Place the following code behind the "Submit" button. This code will consume the web service and then display the results.

Private Sub btnSubmit_Click(ByVal sender As System.Object, _
         ByVal e As System.EventArgs) Handles btnSubmit.Click

   Dim objWSFullName As New WSFullName.FullName()
   lblResult.Text = objWSFullName.FullName(txtFName.Text, _
         txtLName.Text)

End Sub

Now test the application by inputting a first and last name. Click Submit. If all goes well, your Windows Form should look like Figure 10-13. The Web Service concatenated the first and last names and returned the full name for display in the consuming client application.

Debugging a Web Service from the Client

As you’ve just seen, it’s easy to debug a web service with Visual Studio .NET, but you have yet to debug the web service from the new client. The ability to debug a web service from the client application can be useful as the web service developer may not always be in possession of the client code. To do so, follow these steps:

Load both projects in separate instances of Visual Studio .NET.
Place breakpoints in the web service project and run it (ignoring the test web page).
Now run the WinFullName application and click the Submit button. The web service project will break into debug mode; you may perform any debugging task you wish.

Summary

Web services are a new and powerful addition to your development tool set, allowing you to build applications with other developers and to build their consuming applications independently. Thanks to technologies such as WSDL, you can couple both developers and applications.

The cross-platform characteristics of web services means a new paradigm must exist for building and delivering distributed applications. This new paradigm extends the Windows DNA application architecture and mode to include components of platforms other than Microsoft specific platforms. As the .NET paradigm shift continues and the Windows DNA model adjusts to the new technology, you will discover and learn new models or alterations of models for delivering N-tier distributed applications.

This chapter has demonstrated each aspect of web service development. Despite the simplicity of each example, the processes of creation, publication, consumption, and testing are the same.