Building Web applications with ADO. NET and XML Web services

361 Pages·2002·5.28 MB·English

by  Richard Hundhausen

Building Web
Applications with
ADO.NET and
XML Web Services
Richard Hundhausen
Steven Borg
Cole Francis
Kenneth Wilcox
Gearhead Press™
Publisher: Robert Ipsen
Editor: Theresa Hudson
Consulting Editor: Donis Marshall
Developmental Editor: Kathryn A. Malm
Managing Editor: Angela Smith
New Media Editor: Brian Snapp
Text Design & Composition: Wiley Composition Services
Designations used by companies to distinguish their products are often claimed as trade-
marks. In all instances where Wiley Publishing, Inc. is aware of a claim, the product names
appear in initial capital or ALLCAPITALLETTERS. Readers, however, should contact the appro-
priate companies for more complete information regarding trademarks and registration.
This book is printed on acid-free paper. ∞
Copyright © 2002 by Richard Hundhausen and Steven Borg. All rights reserved.
Published by Wiley Publishing, Inc., Indianapolis, Indiana
Published simultaneously in Canada
No part of this publication may be reproduced, stored in a retrieval system, or transmitted
in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or
otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright
Act, without either the prior written permission of the Publisher, or authorization through
payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rose-
wood Drive, Danvers, MA01923, [phone], fax [phone]. Requests to the Pub-
lisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc.,
10475 Crosspointe Blvd., Indianapolis, IN 46256, [phone], fax [phone], E-mail:
[email protected].
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their
best efforts in preparing this book, they make no representations or warranties with respect
to the accuracy or completeness of the contents of this book and specifically disclaim any
implied warranties of merchantability or fitness for a particular purpose. No warranty may
be created or extended by sales representatives or written sales materials. The advice and
strategies contained herein may not be suitable for your situation. You should consult with
a professional where appropriate. Neither the publisher nor author shall be liable for any
loss of profit or any other commercial damages, including but not limited to special, inci-
dental, consequential, or other damages.
For general information on our other products and services please contact our Customer
Care Department within the United States at [phone], outside the United States at
[phone] or fax [phone].
Wiley also publishes its books in a variety of electronic formats. Some content that appears
in print may not be available in electronic books.
The Gearhead Press trademark is the exclusive property of Gearhead Group Corporation.
Library of Congress Cataloging-in-Publication Data:
ISBN: 0-471-20186-3
Printed in the United States of America
10 9 8 7 6 5 4 3 2 1
Contents xi
Chapter4 Designing a SQL Database 95
Features of SQLServer 2000 96
XMLSupport 96
User-Defined Functions 100
INSTEAD OF Triggers 102
Cascading Referential Integrity 104
Multiple Instances of SQLServer 104
Access via HTTP 105
Analysis Services 110
Creating a Database Structure from Our Model 111
Executing the DDL 113
Verifying the Physical Design 118
SQLServer Enterprise Manager (EM) 120
Adding Objects 123
Stored Procedures 123
Database Care and Feeding 130
Database Maintenance Plans 130
SQLProfiler 137
Summary 140
Chapter5 Building ADO.NET Components 141
The ADO.NET Object Model 143
Some ADO.NET Classes 144
Connection 144
Command 145
Parameter 145
DataSet 147
DataTable 148
DataAdapter 148
DataReader 149
ADO.NET Data Providers 150
OLE DB .NET Data Provider (System.Data.OleDb) 150
SQLServer .NET Data Provider (System.Data.SqlClient) 151
Introduction to the Hutchings Data Layer 152
The .NET Framework and ADO.NET 153
Design of the Data Layer 153
DataSets 154
DataAdapters 157
Building the Data Layer 158
Graphically Building the DataAdapters 158
Graphically Building the First DataSet 160
What the Other DataSet Objects Look Like 162
Looking at the Code 163
Building Our WebData Component from Scratch 164
Summary 174
xii Contents
Chapter6 Creating Web Services 175
Creating the ASP.NET Web Service Project 176
Coding the XMLWeb Service 178
First Test of Our Web Service 180
Understanding the Files Created by Visual Studio .NET 185
Summary 186
Chapter 7 Deploying Web Services (UDDI) 187
Registering as a UDDI Participant and Registering
Its Web Services 189
Adding Your Business to the UDDI 193
The Advantages of Web Services 195
Public and Private UDDI 197
Summary 198
Chapter 8 The Web Services Client Business Model 199
Who’s Our Market Again? 199
We’re Tired of Pushing; Let Them Pull for a While 200
It’s a Matter of Effort 201
It’s a Matter of Trust 202
It’s a Matter of Standards 204
Partner: HutchingsPhotography.com 205
Partner: Penguin Photos 209
User Interface Integration 212
The Search Page 212
Verification Page 213
Contract and Billing Page 214
The Benefits to Penguin Photos 215
More Partners Are Lining Up at Port 80 215
Partners Who Want to Stay with Classic ASP 216
Summary 217
Chapter 9 Hutchings Photography 219
Creating a Basic .NET Web Service Consumer 220
Using the Web Service Locator 222
The Web Reference Files 224
The Discovery File 224
The WSDLFile 225
The Reference Map 225
Objects, Properties, and Code 226
Form1: frmImages.vb 226
Our Global Module 229
Form2: frmArtistInfo.vb 231
Implementing the load event code for frmArtistInfo.vb 234
Filling the DataSet 234
Using a DataSet Array to Display the Information 235
The Truth about Embedded Base64 Binary Images 237
Displaying the Data 238
Contents xiii
Form3: frmShowPhoto.vb 240
Adding the Code for the Other Searches 241
Testing the Other Searches 242
Two Features that Make Building Web Services Easy 244
Web Services and Lesser-Known XMLSchema Validations 244
The Inline Schema 245
Building the Code 246
Test-Driving the XSD 249
Building an Out-of-Process XSD 250
Constructing an XSD Document 250
Writing the Code to Use the XSD for Validating XML 255
Adding the Web Reference and Testing the Solution 257
Summary 258
Chapter 10 Penguin Photos 261
About Penguin Photos 262
Conventions Used in This Chapter 263
Borland Kylix 263
Consuming XMLWeb Services with Kylix 2 265
Web Applications with Kylix 267
Integrating Kylix and .NET 268
Consuming Hutchings Photography’s Web Service 269
The ReturnReferenceTables Web Method 271
The ReturnThumbs Web Method 272
The ReturnImage Web Method 274
Creating the Web Application 274
Apache Shared Modules 290
Summary 291
Chapter 11 Securing the Web Service 293
IIS Authentication Methods 294
Understanding the Web.Config File 298
Laying Down the Code 300
Testing Our Web Service 303
Build a VB.NET Client Application 306
Build an ASP.NET Client Application 309
Testing the .aspx Web Form Client 311
Testing the Visual Basic .NET Application 312
Allowing and Denying Users and Groups 315
Summary 315
Chapter 12 Testing the Web Service/Performance Optimizations 317
Performance 317
Web Service Clients 318
Asynchronous Service Calls 318
Callbacks 319
xiv Contents
Web Service Servers 320
Error Handling 320
Scoping the Results 322
Remote Dependencies 322
IIS Server Configuration 323
Component Services 328
Session Management 330
In-Process Mode 330
StateServer Mode 330
SQLServer Mode 330
Performance Tools and Monitoring 331
Event Viewer 331
System Monitor 332
Network Monitor 332
Task Manager 333
Web Service Stress Testing 334
ACT 334
ANTS 336
Hardware 338
Memory 338
Hard Drive 339
Central Processing Unit (CPU) 339
Database Optimization 339
Summary 340
Index 341
CHAPTER
1
What Are Web Services?
Years ago, in the Dark Ages before XML Web services, getting disparate
systems to talk to one another was difficult—sometimes very difficult. At
first, that didn’t matter. Nearly all applications were meant to stand alone
on a single machine, and if they needed to interact with another program,
doing so involved passing a floppy disk from one person to another. Even
after computers were originally networked, the majority of computing was
done inside the confines of one box. Sure, data was passed from one com-
puter to another, but computers didn’t use each other’s processing power.
With the advent and popularization of powerful database software,
things changed. When you accessed a database, you asked the machine
hosting the database to do some processing and return the results of that
effort. This proved to be a winning tactic. More applications sought to take
advantage of server power. Those of you who’ve been in the industry for a
while will remember the shift to a client/server architecture. Of course, to
communicate with the server, the client needed to be able to speak the
same language as the server. For instance, to communicate with SQL
Server, the client needed to understand Tabular Data Stream. This became
a problem, so harkening back to the wise words of David Wheeler, a layer
of indirection was added. In this case, it was Open Database Connectivity
1
2 Chapter 1
(ODBC). This allowed any client that could speak ODBC to access any
database server that could speak ODBC.
NOTE David Wheeler, a chief architect for the EDSAC project in the early
1950s, said, “Any problem in computer science can be solved with another layer
of indirection.” Wise words! And written back at the origins of computer
science.
This worked for a while, and newer layers of indirection were developed,
such as OLEDB and JDBC. But while this approach proved very successful,
it served a limited audience. Providing these useful indirection layers took
considerable industry support. This meant that as software developers
working within a single organization, we had difficulty creating servers
that could easily interoperate with numerous, diverse clients. If we wanted
to create some code with functionality that could be invoked by another
machine, we were in for a difficult time. A few technologies evolved to
assist developers, including DCOM from Microsoft, CORBA from the
Object Management Group, and, later, RMI from Sun Microsystems.
These new technologies were fairly good . . . as long as you were com-
municating with other systems using the same platform—and even that
could be rough. How many of you tried to make DCOM talk to CORBA?
How about making CORBAtalk to DCOM? Or DCOM talk to RMI? And
how many of you tried to make CORBA talk to CORBA? Yep, even that
could be hard. No matter how you sliced it, getting a Microsoft Windows
machine to talk to a Unix machine in any meaningful way was a headache.
Thus, the introduction of XML Web services. Like the technologies
before it, XMLWeb services are a layer of indirection. This time, however,
the method of invoking functionality on another machine is done through
plain text using standard W3C protocols. In one significant way, this is a
step backward—binary protocols can be much faster than an XML Web
service. This disadvantage, though, is more than made up for by the ease
with which different platforms can communicate with one another.
This benefit is simple to demonstrate using Visual Studio .NET. You can
create a project that references code running on a Linux machine in some
guy’s garage in Peoria in just a few steps. Literally in minutes, you can cre-
ate a meaningful application that is actively running code and receiving
data on a machine running an entirely different operating system.
Now that you’ve seen what XMLWeb services can do, how do you use
them? In reality, Web services are nothing more than code running on
someone’s platform that has an entry point allowing you to activate that
code using a special XML document. In the most common case, you’re
What Are Web Services? 3
sending an XMLdocument in a format called the Simple Object Access Pro-
tocol (SOAP) over HTTP. The server has a listener waiting for a SOAP
packet. When it receives one, it opens it up, and if everything is in order, it
executes the native code. It then takes the results from that code, packages
it into another SOAPpacket, and returns it to the client. That’s it. So, what’s
the fuss? Nothing, really; it’s very simple. What makes it exciting is that
this is an industry standard that is being adopted by every major technol-
ogy firm.
To be concise, Web services are nothing more than code that has been
encapsulated by an envelope of reserved words written to a Web Service
Definition Language (WSDL) and a Web Service Meta Language (WSML)
file. The WSDL and WSML files describe the code, methods, parameters,
and data types available for use.
This chapter focuses on Web services and SOAP. It discusses the back-
ground of Web services, how SOAP fits into the picture, and how distrib-
uted programming was accomplished prior to Web services. The chapter
discusses the background of Web services and how they are more robust
when compared to their RPC predecessors. Furthermore, the chapter dis-
cusses the pros and cons of using SOAP through Web services and pro-
vides you with information as to what types of businesses can benefit
using SOAP.
Last, the chapter discusses applying security to Web services. This topic
is also discussed at length in Chapter 11, “Securing the Web Service.”
SOAP (The Web Service Protocol) and the
General Protocol Pecking Order
The Simple Object Access Protocol, better known as SOAP, was introduced
to the public in 1998 when Microsoft released its Microsoft SOAP Toolkit
1.0. The objective was to find a simple interoperable technique to receive
and transfer a wide range of data across the Internet using well-defined
data types.
SOAPwas created as a collaborative work orchestrated in part by the fol-
lowing companies: Microsoft, IBM, Lotus Development, Userland Soft-
ware, and DevelopMentor. Also, a well-known standards body, the W3C
(World Wide Web Consortium), recognizes and endorses the effort as a
protocol that has already received recommended status. Please read
www.w3.og/TR/SOAP/ for more details.
Before we delve too far into SOAP, let’s discuss the order of nature in the
protocol world. Only a fraction of all protocols that exist are listed in the
4 Chapter 1
next paragraph, but many of those that are listed here are well known and
require no explanation after their introduction.
The Transmission Control Protocol/Internet Protocol, better known as
TCP/IP, is ultimately responsible for the creation of other TCP-backbone
protocols: HTTP, DHCP, SOAP, Telnet, Rlogin, DNS, FTP, RSH, IMAP, NFS,
SMTP, POP3, NNTP, SNMP, SSH, most chat protocols, and most X Window
network communications.
FTP, HTTP, and SMTPare three of many widely known standard proto-
cols that are generally supported within an organization and that rely on
TCP as a standard transport mechanism. FTP, HTTP, and SMTP are inter-
active protocols that can trigger events by either programmatic contribution
or encountering a manual user transmission of meaningful information.
We will focus on these protocols in this section because they are the proto-
cols with which most people are familiar.
In the set of circumstances surrounding the HTTP protocol, program-
matic contributions offer a robust way to exchange information between a
client and a server, and Component Services are committed to processing
information in a very efficient manner. For example, the IIS Server does an
excellent job handling HTTPuser requests and responses as well as inter-
preting and executing ASPrequests. Because of the special relationship of
IIS with MTS and COM+, known as Component Services, server-side
resources can be pooled, including connections to the database and COM+
transactions.
In effect, the SOAPprotocol overcomes the barriers discussed previously
in this chapter regarding earlier attempts at creating custom TCP-based
solutions. Because the SOAP protocol uses XML and the TCP protocol to
bypass firewalls, it masks itself as an HTTPresponse or request and is eas-
ily passed through virtually all firewalls.
Hence, without TCP/IP, the HTTP protocol could not exist. You might
think of the SOAP protocol as a third-tier protocol and FTP and HTTP as
second-tier protocols, depending on the TCP protocol that provides for
physical transmission. (See Figure 1.1.)
The TCP/IP protocol negotiates handshaking and RPC (Remote Proce-
dure Call) across an intranet and the public Internet. Handshaking is sim-
ply the method by which two programs, through their interfaces,
determine the type of relationship that exists between them. (See Figure
1.2.) RPC is a way for the programs of one computer to actually execute
code on another computer.