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

Figure 22-3: The UDDI Register page

More than 280 companies have now come on board to support the specification, and the outlook is good that UDDI will become the standard method for locating business partners and Web services on the Internet. In addition, the service is free to use.

Searching the UDDI database from the UDDI Web site is free and does not require registration or authentication. However, if you wish to register your company in the database, you must first obtain a username/password from the registry site before you can register your company. This is necessary so that you can control who is able to change your company information in the database.

For its part, Microsoft is using (or has plans to use) UDDI as a core building block in the

.NET platform. It has plans to integrate UDDI into such products as Microsoft BizTalk Server, Microsoft PassPort, Microsoft bCentral, and the Microsoft .NET Framework. And, as mentioned earlier, support for UDDI is also built into Visual Studio .NET.

Note For more information about UDDI, you can visit http://www.uddi.org.

Microsoft HailStorm

With the creation of such an important and far-reaching technology as Web services, it is not surprising that major software vendors are planning to deliver a horizontal set of useful Web services that will be needed by many next-generation Web-based applications.

Microsoft itself has announced that it will deliver a set of Web services based on the

.NET technologies codenamed "HailStorm." These services collect and store personal information that can be shared with other applications and services based entirely on your consent and control.

Nearly all of us have dealt with the frustration of having multiple usernames, passwords, and profiles for the myriad sites and services that we visit on the Web. What's more, each site that retains this personal information has differing privacy policies and procedures for sharing this information with partners.

HailStorm promises to eliminate this frustration and lack of control over your personal information and replace it with a single source for this data that is under your complete control with respect to accessing this information.

Microsoft has announced that it will release the following sets of HailStorm services initially:

§MyAddress: Electronic and geographic address for an identity. For example, your mailing address and/or your e-mail address can be managed by this service.

§MyProfile: Name, nickname, special dates, pictures, and other more personal information about yourself.

§MyContacts: Electronic relationships/address book that maintains names, e- mail addresses, and other information about your personal contacts.

§MyLocation: Electronic and geographical location and rendezvous. This

service provides information to help locate you electronically.

§MyNotifications: Notification subscription, management, and routing provide services that let you control automatic notifications via e-mail, paging, etc for items that are important to you.

§MyInbox: Inbox items like e-mail and voice mail, including existing mail systems enables you to centrally manage your e-mail and related information.

§MyCalendar: Time and task management services.

§MyDocuments: Raw document storage. Think of this as a virtual disk drive

that exists in the Internet for storing your documents so that they are available no matter where you are.

§MyApplicationSettings: This service permits your application-specific preferences and other settings to be centrally managed and available to your applications regardless of where you use them.

§MyFavoriteWebSites: Favorite URLs and other Web identifiers are made

available to you no matter where you are when browsing the Web.

§MyWallet: Receipts, payment instruments, coupons, and other transaction records are managed by this service so that they can be used by many Web applications that need this information, without having to duplicate it over and over.

§MyDevices: Device settings, capabilities, and related information about the devices that you use on your computer or network -attached devices.

§MyServices: Services provided for an identity.

§MyUsage: Usage report for services that can report what services you used

how much (or how often) you used them, and so on.

Of course, one of the most important issues related to the use of these technologies is personal data security. Because all of these services store personal information of some nature, it is imperative that this data be protected according to your wishes. Consequently, interaction with your personal data will only be allowed with your explicit authorization. You will be able to do the following:

§Determine who or what services have access to your data

§Revoke or deny these privileges at will or on a timed basis

Unfortunately, not very much information was available about HailStorm when this book was being written. By the time you read this, however, a broadly available beta version of these initial HailStorm services is expected to be released. For more information about HailStorm, visit http://www.microsoft.com/net and http://msdn.microsoft.com/net.

Summary

Providing a foundation for the creation and consumption of Web services based on standards such as XML, SOAP, WSDL, DISCO, and UDDI makes Web services capable of being supported on any platform that implements XML and HTTP. What's more, having an infrastructure that supports these standards makes it possible for development tools and platforms such as the .NE T Framework and Visual Studio .NET to supply these capabilities to your Web services automatically, greatly simplifying and accelerating the Web service development process. We will see the fruits of this labor as we begin working with the Microsoft .NET Framework tools to create a Web service.

Chapter 23: Web Services Infrastructure

Overview

In this chapter, you will learn about the Microsoft technologies and tools that provide the essential architectural elements for executing, creating, and consuming Web services on the Microsoft platform.

Although it is possible to build or consume Web services on a platform with support for only the core technologies (XML, TCP/IP, HTTP, and SOAP), it is certainly not a task suited for the beginning programmer or the easily intimidated.

The power of the infrastructure on which the Microsoft Web Services implementation is built is embodied in the basic design principal that Web services should be simple to create and easy to consume. Rather than waste your time writing Web service infrastructure code, you should be able to focus your time and energy on the actual functionality of your application and let the platform do the rest.

The technologies and tools provided in the Microsoft .NET Framework do just that. These technologies give you an excellent, easy-to-use platform for building and consuming Web services quickly and efficiently.

Microsoft Web Services Platform

In the last chapter, you learned that Web services are built on the foundation of XML, HTTP, and SOAP. Using these technologies, Web services enable the creation of distributed applications that can easily leverage the size and diversity of the Internet.

One of the primary motivations behind the creation of the Web services architecture was the inadequacy of existing distributed object model technologies, such as DCOM, CORBA, and IIOP, for Internet-based applications. Although each of these technologies worked well in a controlled, homogeneous environment, this obviously cannot be guaranteed for systems on the Internet.

What's more, these legacy object technologies could also be extremely large and complex (some more than others). Again, this makes it difficult to rely on these older technologies as a foundation for distributed computing on the Internet.

One of the major advantages of the Web services foundation is its simplicity as well as its reliance on existing (or emerging) Internet standards. This ensures that Web services can be implemented on and available across the diverse systems of the Internet.

Although the Web services foundation does a great job of enabling a programmable Internet composed of distributed building blocks, there's really much more to creating scalable, robust, distributed applications. Each individual platform must supply these services, because the Web services foundation does not attempt to address these issues.

The Microsoft .NET platform is specifically designed to provide these essential services, which makes it easy to create world-class Web Services. Figure 23-1 illustrates the Microsoft Web Services platform architecture.

Figure 23-1: Microsoft Web Services platform architecture

The Common Language Runtime (CLR) is built on top of the system platform (such as Windows 2000). Layered on the CLR is the .NET Framework Class Library, which provides a large set of services via a hierarchically arranged collection of classes and types. On top of this base is the ASP.NET Web platform and Windows Forms environments. We will take a look at most of these architectural pieces in upcoming sections of this chapter, as they relate to the development and consumption of Web services.

One of the primary goals of the Microsoft Web Services platform is to make it easy to build Web services that can solve complex, business-critical issues. The following sections take a look at the Web Services platform features that supply critical services that not only make it possible to create these types of applications, but also make it easy.

The Microsoft .NET Framework

The .NET Framework is Microsoft's next-generation platform for building and deploying robust Web services. It has been designed specifically to address the many requirements of delivering Web services that can fulfill the vision of the programmable Internet.

Key features of the .NET Framework that provide support for Web services include:

§The Common Language Runtime (CLR)

§The .NET Framework Class Library

§ASP.NET

Let's examine some of the features of these key .NET Framework pieces that provide a solid environment for the creation and execution of world-class Web services.

The Common Language Runtime

The CLR provides the foundation for the .NET Framework. The CLR is responsible for managing code at execution time and provides the following services:

§Cross-language integration

§Self-describing objects

§Automatic memory management

§Thread management

§Remoting

§Code safety and security

§Code versioning and deployment support

Code that targets the CLR is called managed code. Compatible language compilers generate code that enables the CLR to manage the execution of your applications. To do this, compilers generate what is called Microsoft Intermediate Language (MSIL). This intermediate code is platform-independent; in other words, it can be hosted on any processor architecture supported by the CLR. A Just-In-Time (JIT) compiler is used to convert MSIL to processor-specific code at run time. During execution, CLR-managed code automatically receives the benefits of memory management, cross-language debugging support, security, and many other features.

Managed code is packaged into units called assemblies. Assemblies are the building blocks of .NET Framework applications and form the fundamental unit of deployment, version control, reuse, and security. An assembly contains all the information necessary for the CLR to provide its services.

A major design goal of the CLR (as is true of all the pieces in the Web Services architecture) is to make the development process easier. As you can see, the CLR provides an excellent execution environment for Web services, relieving developers from the responsibility of providing and managing these features themselves, thereby allowing them to easily and quickly build and deploy robust Web service applications that take advantage of the CLR.

Now that you know a little about the CLR and its contribution to the Web Services platform, let's take a few moments to look into the next layer of the architecture: the .NET Framework Class Library.

The .NET Framework Class Library

The .NET Framework Class Library is a collection of classes that are organized into a single hierarchical tree of namespaces. The Class Library provides access to system features via classes, interfaces, and value types, which greatly enhances programmer productivity and simplifies the development process. The Class Library is built on top of the CLR. Therefore, it is also managed code that receives all the benefits provided by the CLR.

At the root of the Class Library hierarchy is the System namespace, which contains over 100 core types and classes that are used by all .NET applications. In addition to the System namespace, the Class Library contains namespaces for abstract base classes and derived class implementations. This includes file I/O, messaging, networking, security, and, of course, access to the Internet. You can use these classes as is, or derive from them to create your own implementations.

The .NET Framework uses a dot-based naming scheme to represent grouped classes and types that comprise a namespace. Namespaces make it easier to search for and reference classes and types. The namespace name includes everything from the beginning of the name up to the last dot in the name. The remaining part of the name identifies the type name. For example, the System.Web namespace defines the Web type, which belongs to the System namespace.

Table 23-1 lists some of the namespaces that implement features of Web services on the .NET platform.

Table 23-1: .NET Web Service namespaces

unprecedented speed, flexibility, and ease. ASP.NET is fully supported by the .NET Framework, enabling you to take full advantage of the CLR, type safety, inheritance, and all the other features of that platform.

Unlike Active Server Pages (ASP), ASP.NET is a compiled, .NET-based platform. ASP.NET applications can be built using any .NET-compatible programming language. Also, because ASP.NET is built on top of the .NET Framework, your ASP.NET applications have access to the entire range of functionality provided by the framework.

Among the major advantages of the ASP.NET environment are the following:

§ASP.NET applications are fully compiled .NET applications, providing superior performance characteristics.

§ASP.NET supports WYSIWYG HTML editors and programming environments such as Visual Studio .NET. This enables you to be very productive when developing ASP.NET applications and enables you to leverage the many features of these tools.

§ASP.NET applications support extensive configuration capabilities based on XML configuration files.

§ASP.NET provides flexible, advanced, and easy-to-use application and session state management features that can be extended or replaced with custom schemes.

§ASP.NET implements multiple authentication and authorization schemes that can be extended or replaced with custom schemes.

ASP.NET provides two programming models that can be used to create Web applications: Web Forms and Web Services. Web Forms enable you to build formsbased Web applications using a technology called server controls, which enable you to create user interfaces from common UI elements such as text boxes, list boxes, and so on. Web Services, of course, are the subject of this chapter.

ASP.NET Web Services can take advantage of all ASP.NET features as well as the features of the .NET Framework and CLR. Let's take a look at some of these features, because you will likely interact with many of them when implementing your Web service applications. ASP.NET leverages the classes found in the .NET Framework Class Library to support Web services and the many other features this environment provides to developers.

As you read through the ASP.NET feature overviews found in the following sections, remember that each of these features can be leveraged by your Web service applications. As you will see, having these capabilities at your fingertips makes developing world-class Web services much easier.

ASP.NET applications

An ASP.NET application consists of all the files, pages, handlers, modules, and executable code that reside in a Web server virtual directory (and any subdirectories). Web services are also ASP.NET applications and, therefore, are governed by the same configuration rules as any other ASP.NET application.

Each ASP.NET application can include an optional Global.asax file in the root virtual directory. This file contains handlers for application-level events that can be raised by ASP.NET. For example, you can handle such events as Application_OnStart and Application_OnEnd in the Global.asax file.

In addition to these events, you have access to any events exposed by HTTPModules. An HTTPModule is a class that can process information from any HTTP requests made to your ASP.NET application. You can customize or extend modules supplied by ASP.NET or create your own. Any events raised by HTTPModules are handled within the Global.asax file.

ASP.NET applications also support a hierarchical application configuration architecture. Application configuration settings are stored in an XML file named Web.config. The settings stored in this file are applied hierarchically as follows:

§Web.config files supply their settings to the directory in which they are located as well as to all subdirectories.

§Configuration settings for a Web resource are supplied by the Web.config file located in the same directory as the resource and by all configuration files in all parent directories.

The default, global configuration file is named Machine.config and is stored at %SYSTEM_ROOT%\Microsoft.NET\Framework\ version\CONFIG. If no developersupplied configuration files are found, the settings in this file will apply to your Web application.

State management

HTTP is a stateless protocol. This means that HTTP does not retain any information or knowledge from one request to the next even though those requests may come from the same user session and may even be related to each other. Of course, if you are building Web applications, the lack of such state information can make it extremely difficult to develop applications that require such information.

ASP.NET provides both application state and session state management capabilities for Web applications. Application state is used to store data that applies to the application as a whole and is available to all sessions using the application. Session state is used to store data that is specific to each browser session using the application. Session state is not visible across different sessions (unlike application state).

Both application and session state information is stored in key/value dictionary objects. Access to this information is supplied through an Application object (for application state) and a Session object (for session state).

Application state is essentially a global variable-storage mechanism for ASP.NET applications. Experienced developers know that global variables come with specific issues and must be considered and used sparingly. This is even more important in a server-based scenario, such as ASP.NET applications. In particular, you should be aware of the following when considering the use of application state in ASP.NET applications:

§Memory used by application variables is not released between requests. Thus, it can have extended effects on server memory use. Therefore, you should be a good custodian of application state memory.

§Application variables have concurrency and synchronization issues. Because multiple requests can be executing simultaneously, any changes to application-scoped variables must be synchronized. This can cause concurrency issues and slow down server performance.

§Application state is not shared across a Web farm (where an application is hosted on multiple servers) or Web garden (where an application is hosted on multiple processes on a single server).

These issues are certainly not meant to scare you away from using application state. On the contrary, used properly, application state can be a very valuable tool for Web applications. Before embarking on their use, however, you need to clearly understand the capabilities and limitations of application state within ASP.NET and the typical applications in which application state can be used effectively.

Session state permits you to automatically identify requests that come from the same browser client as well as store information specific to that session. ASP.NET session state provides the following features:

§Session state can survive IIS and worker-process restarts without losing session state information.

§Session state can be used in both Web farm and Web garden configurations.

§Session state can be used even if the client browser does not support cookies.

ASP.NET session state can be fully configured to meet your specific needs via the Config.web configuration files. For Web applications that require session state, ASP.NET provides excellent, reliable, and scalable support for maintaining session state.

Caching

One of the most important factors in creating highly scalable, high-performance Web applications is through the use of caching. Essentially, caching permits the Web application to supply the results of a previous request to other requests for the same information without having to involve the server in regenerating this information. This can greatly increase the performance of your Web application.

ASP.NET provides two types of caching capabilities. Output caching supplies the output of previous requests from the output cache instead of re-executing the server code necessary to generate the output a second time. The application cache is a programmatic cache that applications can use to store objects and other resources that can take a lot of time to re-create.

Transactions

A transaction is a set of related tasks that either succeed or fail as a unit. By combining a set of related operations into a unit that either completely succeeds or completely fails, you can simplify error recovery and make your application more reliable.

ASP.NET Web Services support declarative, attribute-based transactions at the method level. This means that you can specify, via a property of the WebMethod attribute, what, if any, type of transaction support is required for your Web service method.

Subsequently, any resource managers that you interact with during the execution of the Web method (such as SQL Server, Message Queue Server, SNA Server, Oracle Server, and so on) will be transacted.

Security

ASP.NET provides a comprehensive, flexible, and extensible security framework that enables you to secure your Web services. The security framework addresses four fundamental security needs:

§Authentication: To determine that a user is who he/she claims to be

§Authorization: To control access to resources based on the identity of a user

§Impersonation: To assume the identity of the requesting user when accessing resources

§Code Access Security: To restrict the operations that a piece of code can perform (or has intentions of performing)

Fundamentally, ASP.NET uses the services of Internet Information Services (IIS) to obtain requests for pages or Web services. Thus, ASP.NET is capable of utilizing the security features of IIS. Currently, ASP.NET is hosted by IIS 5.0, which means that it relies on the basic security features provided by IIS 5.0. Three authentication mechanisms are supported by IIS 5.0: Basic, Digest, and Integrated Windows.

In addition to the authentication services provided by IIS, ASP.NET supports two additional types of authentication: Forms and Passport. Forms authentication enables custom authentication to occur via support provided by the application. For example, you may use a custom SQL Server database of defined users and passwords to identify users. Passport authentication is a centralized authentication service provided by Microsoft that offers a single sign-on feature along with basic profile services.

ASP.NET security is configured in the ASP.NET application configuration file (named Web.config). Using this configuration file, you can specify how users are authenticated, control access to resources via authorization settings, and determine impersonation settings.

Web Services Infrastructure

In the last chapter, you learned that four primary infrastructure pieces are specifically needed to support Web services:

§Web Service Directories, which provide a means to locate providers of Web services

§Web Service Discovery, which provides the capability to locate Web services

§Web Service Description, which enables Web service capabilities to be

described

§Web Service Wire Formats, which allow Web services to exchange data and messages

Collectively, these technologies provide services that are essential to the creation and consumption of Web services. In the next few sections, you will learn how this Web service infrastructure is provided on the Microsoft .NET Web Services platform.

Web Service directories

Recall that Web service directories provide a centralized, Internet-accessible location that consumers can use to find Web services that have been offered for use by other companies or organizations. You can think of Web service directories as a type of Web portal or "Yellow Pages" specifically suited for listing and locating Web services.

Using Web service directories, you can search for Web services using a variety of structured criteria, such as business type, industry, type of goods produced, services offered, and so on. For example, if you were looking for a credit card validation Web service, you could search the directory using personal credit companies as the criteria. Currently, the Universal Description, Discovery, and Integration (UDDI) specification is the de facto standard for cataloging and finding Web services. The UDDI organization (located on the Web at http://www.uddi.org), composed of several hundred industry participants, has created a directory schema, distributed repository, and APIs for manipulating and querying the repository.

Currently, Microsoft and IBM both have cooperating UDDI directories operational and available for general use. These sites include operational Web services, which can be called to programmatically manipulate and query the UDDI registry database.

If you are using Microsoft Visual Studio .NET to create your Web services or Web service consumer applications, the Web Reference feature of Visual Studio has the ability to search these online UDDI directories automatically. In fact, the Visual Studio

.NET Web Reference feature is itself a consumer of the UDDI Web servi ces.

Alternatively, if you are not using Visual Studio .NET, you can use the UDDI Web site to search for Web services. The Web site contains interactive forms for manipulating and querying the registry database.

If neither of these methods suits your needs, you can also download a UDDI SDK from either Microsoft or IBM, which you can use to create your own custom search tool.

We will examine in detail how to use these services in Chapter 28, "Consuming Web Services."

Web Service discovery

Web service discovery is the process of locating one or more related documents that describe a specific Web service. Recall that Web services are described in terms of the