C# ПІДРУЧНИКИ / c# / Hungry Minds - ASP.NET Bible VB.NET & C#

ASP.NET provides a default configuration file for the entire Web server. This file provides the default settings for an ASP.NET application. This file, called Machine.config, is located in the %windir%\Microsoft.NET\Framework\version\CONFIG folder and is available at the machine level. In addition to this machine-level file, you can create your own Web.config file that specifies the settings for a particular application.

When a user makes a request for a resource, ASP.NET determines the configuration settings for the resources by referring to the settings in the Web.config file located in the path of the resource. In the absence of this file, ASP.NET refers to the settings in the Machine.config file.

Deploying Classes and Assemblies

A Windows application is composed of different types of files, such as EXEs and DLLs. When you deploy a new application, it might result in the installation of all the files that comprise the application. However, this may cause a number of problems, especially in case of applications that use COM-based components. COM components need to be registered so that the system can locate them. This requires several Registry settings, in the absence of which the components do not work. In addition, if an application results in installing a newer version of a component, which is shared by a number of applications on a computer, the existing applications might not work as expected.

To overcome the problems of COM-based components and to simplify the process of deploying classes and components, .NET introduces the concept of assemblies. An assembly is a single logical unit of functionality. It is the fundamental unit of class deployment.

An assembly contains an assembly manifest, which contains data about the dependencies of the files that are included in the assembly, their version requirements, security information, and all other information required to resolve references to resources and classes in the assembly.

CrossReference

After you have created an assembly, you can easily deploy it by using Windows Installer (as an MSI file), by using Internet Explorer (as CAB files), or simply by copying the assembly to the target computer. An assembly can be deployed into the local assembly cache or the global assembly cache. The local assembly cache is specific to an application. On the other hand, when you install an assembly into a global assembly cache, it can be accessed by all applications on a computer.

Usually, assemblies are deployed into the local assembly cache of the application. This ensures that the assembly can be accessed only by the code in the application. It also facilitates side-by-side versions of an application to run simultaneously, because the classes of the assemblies are private to a particular application version instance. You can deploy an assembly into the local assembly cache by copying the assembly files in the directory, which is marked as the assembly cache location for an application. ASP.NET applications are configured to use the bin directory specific to an application as the default local assembly cache. Therefore, you can copy the assembly files to the bin directory of the application.

You can install an assembly into the global assembly cache, using Windows Installer, when you want multiple applications to share the code in the assembly. Windows Installer 2.0 provides the reference-counting feature for assemblies that are shared by multiple applications.

Summary

In this chapter, you learned about the different types of deployment projects. You also learned about various editors that are used in deployment projects. Then, you learned about the configuration settings in ASP.NET. Finally, you learned about deploying classes and assemblies.

Part IV: Building Web Services

Chapter List

Chapter 22: Introduction to Web Services

Chapter 23: Web Services Infrastructure

Chapter 24: Understanding SOAP

Chapter 25: Building a Web Service

Chapter 26: Deploying and Publishing Web Services

Chapter 27: Finding Web Services

Chapter 28: Consuming Web Services

Chapter 22: Introduction to Web Services

Overview

Web Services solve a basic, but pervasive problem experienced by many of us with today's Internet. Although literally billions of pages of useful data and information are served up by the Web, it is typically difficult to extract, examine, and use that data programmatically.

Much of this difficulty arises from the fact that the Web (at least as it exists today) is designed for human consumption. Consequently, data is presented in a form that's easy for a human to read but relatively difficult and error prone for applications to read and process reliably.

In this chapter, you will learn about some of the limitations of today's Internet as a backbone for application integration and how Web services promise to deliver an effective platform for enabling the next generation of distributed, integrated applications to the Web.

The foundational elements of Web services will be covered, providing a solid understanding of the infrastructure that enables Web services to be built and consumed. In addition, some of the Web services being planned by Microsoft will be discussed, which can be leveraged for use in your own Web service implementations.

Understanding Web Services

Web services are all about delivering distributed applications via programmable components that are accessible over the Web. As an example, many e-commerce sites need to calculate shipping charges based on a variety of shipping options. Typically, such a site might maintain a set of database tables that describe the shipping options and charges for each shipping company. Obviously, this can become a time-consuming process, because the data is likely to change often, and someone must repeatedly update the tables.

A more automated approach might incorporate a process called "screen scraping." Suppose that one of the shipping companies maintains a Web site that conveniently lists the various shipping options and associated charges. By utilizing screen scraping (essentially a process of analyzing the data in a page for certain patterns in order to extract the data you are interested in processing), a program can examine the Web page and extract the shipping information from that page.

At first glance, this might appear to be an effective solution (and, in fact, it is used relatively frequently and with some success today). But, what happens if the Webmaster at the shipping company decides to change the layout or otherwise reformat the data on

the page? This might be necessary if, for example, a new shipping option is introduced. Suddenly and unexpectedly, your screen scraper may no longer be able to locate the data you need.

Now, imagine this same e-commerce site programmatically calling a Web service provided by the shipping company on its Web site that automatically calculates shipping costs based on the shipping method and package weight that you specify in your request and returns the resulting charge to you in real time.

While this is admittedly a simple example, it clearly illustrates the power and potential of Web services to transform the Web from a passive, interactive information display medium into a platform for truly distributed computing. Essentially, Web services extend the capabilities of classic distributed applications and services to the heterogeneous platform that is the Internet.

Of course, there are many other potentially valuable applications of Web services. Some of these include:

§Services that are either too difficult or too expensive to implement yourself. For example, credit card validation, financial account management, stock quotes, and so on.

§Services that provide commonly needed functionality for other services. For example, user authentication, usage billing, usage auditing, and so on.

§Services that aggregate distributed, discrete services into an orchestrated whole. A good example of this type of service would be travel booking.

§Services that integrate your business systems with your partners (or other

business systems within your own organization).

No wonder so much excitement surrounds the promise that Web services offer to programmers, systems integrators, and IT professionals.

What is a Web service?

In short, a Web service is a programmable URL. Stated another way, a Web service is an application component that is remotely callable using standard Internet protocols such as HTTP and XML. Thus, any system that supports these basic, standard protocols is capable of supporting Web services.

The ability to package application code into reusable components that is callable across process and machine boundaries is not a new concept. Today, technologies are available such as the Component Object Model (COM), the Common Object Request Broker Architecture (CORBA), Internet Inter-ORB Protocol (IIOP), and Remote Method Invocation (RMI), to name a few. A key limitation of these technologies is that they are not easily interoperable amongst the tremendous number of heterogeneous systems that comprise the Internet. This is due, in part, to dependencies on particular operating systems, programming languages, or object-model-specific protocols. Consequently, this limits their effectiveness as a standard method for programming the Web. Clearly, what is needed for Web services to succeed on the Internet is a platform that does not depend on a specific operating system, object model, or programming language.

What sets Web services apart from these prior-generation component and middleware technologies is the fact that they are built upon widely accepted Internet standards that can interoperate seamlessly in the diversity of the Web. Web services use a text-based messaging model to communicate, allowing them to operate effectively on these many different platforms.

If you are familiar with creating and consuming COM components for distributed applications, you will find creating and consuming Web services a natural evolution of what you already know.

Note The remaining chapters in Part IV, "Building Web Services," will provide you with a solid introduction to the technologies that will enable you to understand, build, and consume Web services.

As this book is being written, major platform and software vendors (including Microsoft, IBM, Sun, Hewlett-Packard, and others) have all begun delivering support for Web services with technologies and tools that enable software developers to easily create Web services on these platforms. We will, of course, be concerned with creating Web services using the Microsoft .NET Framework with the VB.NET and C# programming languages.

Foundational elements of Web services

Now that you have an idea of what Web services are and how they can be used, let's examine the key technologies that you will encounter when working with Web services.

Microsoft provides an excellent platform for building and consuming Web services with the .NET Framework, which virtually eliminates the need to learn about the "plumbing" that is a part of building and consuming Web services. If things worked right all of the time and never had the opportunity to fail, there would be no need to even discuss this plumbing. But, of course, things don't always work right and, when they don't, it is both useful and practical to have a basic understanding of the working principals of the foundation upon which Web services are built. The goal is to empower you with enough knowledge that you can effectively troubleshoot any problems you might encounter when working with Web services.

The key to the broad-reach capabilities of Web services on the Internet is a foundation built on Internet standards that does not rely on any platform-specific technology. This foundation supplies standards-based services that provide the following capabilities to Web services:

§A standard, portable method for describing data

§A standard, extensible message format for communicating requests and responses

§A standard, extensible method for describing the capabilities of Web services

§A method to discover what Web services are available at any particular site

§A method to discover what sites provide Web services

The following sections will help you to understand why these issues are important and also introduce you to the technologies that provide these capabilities to the Web services platform.

Representing Data

Web services enable consumers to programmatically request and obtain structured data. But, how is this data encoded so that it can be exchanged between service and consumer? How do you ensure a consistent and accurate interpretation of the data when the service and consumer may reside on different platforms, operating systems, object models, and/or programming languages?

To promote the ability of Web services to communicate their data unambiguously, efficiently, and effectively, a common, portable, and standard method for describing data must be used.

The simple (and logical) answer is XML. As you will soon see, XML is used extensively in every aspect of Web services. The following is an introduction to the specific XML technologies you will encounter when building or consuming Web services.

What is XML?

XML provides a standards-based method for describing data (also known as metadata). XML has the ability to describe data using a simple grammar that is highly interoperable

among the many heterogeneous systems that are connected to the Internet. Using the basic elements of the XML language, you can describe simple as well as complex data types and relationships.

XML has several key strengths that have helped it to become the de facto method for describing data (especially over HTML and other binary formats):

§XML is a text-based language, which makes it easily readable and more portable than binary data formats.

§XML gives you the ability to define your own tags to describe data and its relationships to other data (hence, the word extensible in its name).

§XML strictly enforces its language syntax, unlike HTML.

§Parsers are widely available to accurately parse and validate XML structures that you define, which means you don't have to do it yourself!

Of course, XML is not without it's weaknesses. Among these is the fact that XML can be more "wordy" than an equivalent binary format. In addition, data interoperability can be difficult to achieve due to differences in naming conventions from one application to another.

In the following sections, we will briefly examine the syntax and structure of XML documents.

XML syntax

XML is a markup language that, at first glance, looks very much like HTML. In fact, XML and HTML are both derived from the Standard Generalized Markup Language (SGML). XML (like HTML) uses a set of human-readable tags and declarations to create a document. The major difference is in the meaning implied by these tags and declarations. Whereas HTML is concerned with describing how to format information on a page, XML is concerned with describing data and its relationship to other data.

XML uses tags enclosed in < and > angle brackets to define elements that form element structures and hierarchies within an XML document.

XML document structure

An XML document consists of a prolog, document elements, and optional attributes that model a logically related set of data. An invoice is one example of such an information model. The prolog contains information that applies to the document as a whole and appears at the top of the document before the first document tag. The prolog usually contains information about the character encoding and document structure as well as other possible information. XML parsers use the prolog to correctly interpret the contents of an XML document.

The following sample illustrates the format of a simple XML document that describes the weather conditions in the city of St. Louis, Missouri:

<?xml version="1.0" encoding="UTF-8"?>

<weather>

<location city="St. Louis, MO USA">

<forecast date="2001-07-15">

<temperature units="F">80</temperature>

<humidity units="%">55</humidity>

<skies>Cloudy, 40% chance of showers</skies>

</forecast>

</location>

</weather>

Note that the indentation applied to elements is not required; however, it makes reading the document and understanding the relationship between elements easier.

From this sample, we can see that the <weather> element is a container for a collection of city-based weather conditions (in this case, the conditions for a single city, St. Louis). The weather conditions for a specific city are contained within a <location> element. Within the <location> element are elements that describe a date-based weather forecast.

Note that several of the elements contain a "units" attribute. In XML, attributes are used to further describe or qualify information related to the element in which they are contained. In this example, the "units" attribute is used to define the numeric units of the air temperature described by the <temperature> element. Other examples of attributes are "city" and "date".

As this simple example shows, XML lets you define your own tags for describing data. The XML standard does not define the meaning of the <weather> tag. However, it will enforce the grammatical rules, which are required to create a well-formed XML document.

Specifically, when creating an XML document, it is very important that you follow these basic rules:

§All elements must have an end tag.

§All elements must be cleanly nested (no overlapping like that which is tolerated in HTML today).

§All attribute values must be enclosed in quotation marks.

§Each document must have a unique first element (the document root).

Unlike HTML, syntax errors and other mistakes encountered in an XML document will cause the XML parser to halt processing of the document. This is important, because we are relying on XML to accurately describe our data. When dealing with data, there is no room for the ambiguities and loose interpretation that HTML allows in its syntax.

XML namespaces

When developing XML documents, it is common to refer to element and attribute names that share a common context as a vocabulary. Thus, we might say that our previous sample XML document belongs to a weather vocabulary.

Given that an XML document consists of a vocabulary that you define, the possibility arises that an element or attribute in that vocabulary may have a name that is identical to an element or attribute used by someone else in a different vocabulary. What's worse, what if someone else also defines a weather vocabulary that uses some of the same names, but whose elements mean something quite different or arranges the elements in a different hierarchy?

Let's take the case of our fictional weather example. The <temperature> element we used to define the current air temperature might also be used to define the temperature of a liquid or the surface temperature on Mars. How do we distinguish an air temperature from a liquid temperature or the surface temperature on Mars? Or, stated another way, how do we determine the vocabulary to which the temperature element belongs?

XML namespaces solve this ambiguity problem by associating an explicit namespace (or vocabulary) with elements and attributes in an XML document. Thus, a namespace is essentially a set of names in which all the element and attribute names can be guaranteed to be unique.

For example, we can slightly change our weather sample as follows:

<?xml version="1.0" encoding="UTF-8"?>

<weather xmlns="http://mydomain.com/xml/weather">

<location city="St. Louis, MO">

<forecast date="2001-07-15">

<temperature units="F">80</temperature>

<humidity units="%">55</humidity>

<skies>Cloudy, 40% chance of showers</skies>

</forecast>

</location>

</weather>

In this example, the <weather> element includes a namespace declaration specified by the standard xmlns attribute. This defines a namespace using a URI with the name "http:// mydomain.com/xml/weather" for the <weather> element and all the elements contained within.

It is worth pointing out here that the URI used to define the namespace does not need to point at anything (unlike a URL). It is simply a method to uniquely identify your weather vocabulary from all others. Therefore, you will typically want to define namespaces using names that you own or have control over. Generally, Internet domain names are used, because they are already guaranteed to be unique (and also identify the entity defining the namespace). However, when using the XML Schema Definition (XSD) language, this URI can point to the XSD file, which defines the schema for the XML document. We will cover the fundamental features of XSD in the next section.

A namespace can be declared using default declaration (as in our example) or explicit declaration. Let's take a brief look at these methods, because you'll see them frequently when examining XML documents related to Web services.

Default namespace declaration

Default declaration defines a namespace whose scope includes all elements contained within the element where the declaration was specified. Default declaration is typically used when a document contains elements from a single namespace. Our weather example used a default namespace declaration because all the elements shared the same context or vocabulary (in other words, none of the elements refers to elements from other namespaces).

Explicit namespace declaration

Explicit declaration defines a shorthand reference to an existing namespace. This method is used when referencing an element or attribute from other namespaces. For example, you could combine the elements from several namespaces into another XML document by using explicit namespace declaration as follows:

<weather:temperature xmlns:weather="http://md.com/xml/weather">

80</weather:temperature>

<liquid:temperature xmlns:liquid="http://md.com/xml/liquid">

150</liquid:temperature>

The name preceding the colon is called the prefix and serves as a shorthand notation so that references to the actual namespace URI do not have to be repeated everywhere an element or attribute is used within the document. Instead, you simply use the prefix to refer to the namespace. The only requirement for the shorthand name is that it must be unique within the context of the document that you are using.

Using namespaces in this way eliminates naming conflicts and guarantees that any two elements that have the same name must come from the same vocabulary. In our example, the weather temperature is clearly distinguished from the liquid temperature.

You will find explicit namespace declarations used in many places within the XML documents that are an integral part of the Web services architecture.

XML schemas

In our coverage of XML thus far, it was mentioned that the XML parser uses strict rules to ensure that the XML document is well formed. Recall that a well-formed XML document is one that follows the rules for properly closing tags, nesting tags, enclosing attributes in quotes, and using a unique first element.

However, this does not address the issue of validating that an XML document contains the proper assortment of elements and in valid combinations. What is needed is a language that will allow a generic XML parser to determine that the document conforms to these additional, user-defined rules.

The XSD language defines rules for describing the valid combinations and relationships of elements, attributes, and data types that can appear in an XML document. This enables authors as well as consumers to validate that the document is formed correctly according to the schema definition.

XSD syntax

An XSD schema document contains a top-level schema element. The schema element must define the XML schema namespace, as in the following:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

The schema element contains type definitions and element/attribute declarations. XSD enables you to use built-in data types (such as integer and string) as well as userdefined data types when specifying the valid types of data that can be specified for particular elements in the schema definition.

In addition to the built-in data types, user-defined type definitions can be built using the simpleType and complexType elements. Element and attribute definitions are built using the element and attribute tags. The following example schema (again, using our weather forecast grammar) illustrates the use of these tags:

<?xml version="1.0" encoding="utf-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="skies" type="xsd:string" />

<xsd:attribute name="city" type="xsd:string" />

<xsd:attribute name="units" type="xsd:string" />

<xsd:attribute name="date" type="xsd:date" />

<xsd:element name="temperature">

<xsd:complexType>

<xsd:attribute ref="units" />

</xsd:complexType>

</xsd:element>

<xsd:element name="humidity">

<xsd:complexType>

<xsd:attribute ref="units" />

</xsd:complexType>

</xsd:element>