Sybex,VisualC#ASP.NETProgramming2002.pdf

Visual C# ASP.NET

Programming

Harold Davis – Sybex 2002

Edited by ff

Creating a Web Service

• Understanding web services

• Creating a web service using Notepad

• Creating an ASP.NET web service using Visual Studio

• Adding a class module

• XML documentation tags

I believe that the best way to learn something is to plunge in. Of course, that leaves the question of

where it's best to plunge. This book is, of course, about a programming language - C# - and a

programming environment - Visual Studio .NET. It would be natural - and typical - to start with one or the

other. Another conventional possibility would be to start by creating a Windows application.

But let's not be conventional! C# is a brand new language, and web services are a genuinely new

programming concept. New languages and revolutionary programming architectures don't come along

very often. Why not plunge in in a way that keeps things interesting and isn't the 'same old, same old'?

This chapter will show you how to create a very simple ASP.NET web service by hand using Notepad (it

will be automatically compiled when the service is opened the first time). You'll also learn how to build

somewhat more complex ASP.NET web services using Visual Studio. Along the way you'll learn (of

course) about web services - and also C# language concepts, and how to work with the Visual Studio

environment.

When all is said and done, this is a book about programming in C#, and web services are only one of the

exciting things you can create using C#. In this chapter, I'll use web services as a launch pad for helping

you to understand class - based programming in C# - a truism, since all C# programming is working with

classes. Before we get there, you do need to understand a bit about web services.

Understanding Web Services

A web service is a mechanism for making components available across the Internet using open

standards, including HTTP (Hypertext Transfer Protocol) and XML (Extensible Markup Language). The

idea is to create 'black box' components that can communicate with each other, regardless of the

operating system or programming language. A little more precisely, a web service is a component, or

module, of executable code with a special interface that makes its methods available for use (also called

'consumption') by other programs using an HTTPbased request. This request is made using HTTP GET

or using HTTP POST and Simple Object Access Protocol (SOAP). (You are probably familiar with GETs

and POSTs from working with HTML web forms; SOAP is discussed further in this section.)

Component-Based Distributed Architectures

Web services are by no means the only architectural technology used for component - based distributed

computing; for example, you are probably somewhat familiar with Common Object Request Broker

Architecture (CORBA) and Distributed Component Object Model (DCOM).

Table 1.1 compares some of the characteristics of CORBA, DCOM, and web services. The protocols

listed under the Web Service column are described throughout the subsequent sections of this chapter.

Table 1.1: CORBA, DCO M, and Web Services Compared

Characteristic

CORBA

DCOM

Web Service

Mechanism for remote

procedure call (RPC)

Internet Inter - ORB

Protocol (IIOP)

Distributed Computing

Environment Remote

Procedure Call

(DCERPC)

HTTP

Encoding

Common Data

Representation (CDR)

Network Data

Representation (NDR)

XML and SOAP

Interface description

Interface Definition

Language (IDL)

IDL

WSDL

Discovery

Naming service and

trading service

System Registry

UDDI repositories

Works through firewall? No

Yes

Complexity of protocols? High

High

Low

Cross - platform?

Somewhat

Yes

As you can see from Table 1.1, web services have some significant advantages over CORBA and

DCOM: web services are less complex, can get through firewalls, and are accessible from any client

platform. Note that this, of course, does not mean that web services are always a good replacement for

CORBA and DCOM - these other protocols have their place in homogenous systems behind a firewall in

which the platform is the same and the servers are directly connected, and where performance is an

important concern.

Ways to Create Web Services

Essentially, a web service is implemented as a SOAP XML document. There are many ways to create

this document. For example, IBM provides a Web Services Toolkit, as does the Apache project. You can

also hand - format the SOAP XML. Even within the Microsoft universe, there are several different ways

of implementing SOAP - based XML web services. These include:

• Microsoft's SOAP Toolkit, which lets you expose COM components as web services (and does not

require the .NET Framework for deployment). To download the SOAP Toolkit, go to

http://msdn.microsoft.com and search for SOAP Toolkit .

• Office XP Web Services Toolkit.

• An ATL Server implementation written in C++. ATL Server is part of Visual Studio .NET but does not

require the .NET Framework for deployment.

• .NET Remoting, which lets classes inherited from a base class named MarshalByRefObject be

exposed as web services using SOAP.

• ASP.NET.

You probably will not be surprised to learn that ASP.NET - using either Visual Basic or C# ('see sharp') -

is the easiest way on this list to create web services. As I'll show you shortly, you can write an ASP.NET

web service by hand in a text editor such as Notepad and let ASP.NET compile and deploy it for you, or

you can take advantage of Visual Studio .NET's rich integrated development environment.

Note: In this book, I'll use the term 'web service' to mean an ASP.NET web service rather than any of

the other kinds of web services described above.

Simple Object Access Protocol (SOAP)

The SOAP specification can be found at www.w3.org/TR/SOAP/. According to the specification abstract,

SOAP is a lightweight protocol for exchange of information in a decentralized,

distributed environment. It is an XML based protocol that consists of three parts: an

envelope that defines a framework for describing what is in a message and how to

process it, a set of encoding rules for expressing instances of application - defined

datatypes, and a convention for representing remote procedure calls and responses.

It's worth noting that:

• While SOAP can be used as a remote procedure invocation mechanism, it can also be used to

exchange XML documents.

• SOAP uses XML namespaces.

• The SOAP envelope mentioned in the specification contains the actual message in the body of the

envelope. It also contains SOAP headers, which can be used programmatically (see Chapter 13, 'Web

Services as Architecture,' for an example).

• When you want to invoke a method remotely, you're sending a SOAP request and getting a SOAP

response.

Web Services Description Language (WSDL)

Web Services Description Language (WSDL) describes the methods supported by a web service, the

parameters the methods take, and what the web service returns. You can find the specification,

sponsored by a cross - industry group that includes IBM and Microsoft, at www.w3.org/TR/wsdl.

A WSDL document is an XML schema that provides the required information about a web service -

methods, data types, and response - so that a proxy can be created (you'll see how to create and use a

proxy in Chapter 2, 'Consuming the Service on the Web').

Generally, creators of ASP.NET web services do not have to worry themselves about WSDL; a WSDL

document is automatically generated at runtime on the fly by the ASP.NET runtime using a process

called reflection. (Reflection is a mechanism that allows metadata about a program to be examined at

runtime.)

Universal Description, Discovery, and Integration (UDDI)

How do you find a web service that you might want to consume? Conversely, how do you publish a web

service so that others can find it? One answer is word of mouth. I might tell you about a web service, or

you might tell me. Similarly, it's no problem for us to find the web services that we'll create in the

remainder of this chapter. When we want to consume them, we'll know what we named them, and what

URL to use.

Universal Description, Discovery, and Integration (UDDI) is a more general, cross - industry effort at

creating a repository for publishing and finding web services. The UDDI project (www.uddi.org) consists

of a registry and a set of APIs for accessing the registry. IBM and Microsoft maintain cross -

synchronized UDDI registries that can be browsed. The Microsoft registry can also be accessed from the

Visual Studio Start page, as explained in Chapter 2.

In addition to UDDI, there are websites that provide directories of web services you can consume. You'll

find more information about this in the 'UDDI' section of Chapter 2.

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: