Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Microsoft Visual C++ .NET Professional Projects - Premier Press

.pdf
Скачиваний:
180
Добавлен:
24.05.2014
Размер:
26 Мб
Скачать
☆

690 Project 7 CREATING WEB SERVICES

SOAP Body. This object contains methods and parameters that are stored as XML. The information of these XML parameters is converted back into the native format by the remote SOAP processor.

Whenever you serialize method parameter information into a SOAP packet, you require using a new set of XML tags for describing the process of serialization.

 

 

 

 

 

 

 

 

 

 

 

 

 

NOTE

 

 

Y

 

 

 

L

 

 

 

 

F

 

Serialization is the process of converting the parameter information of a method into

 

a SOAP XML packet. This conversion is done when the Web service is invoked.

 

 

 

 

M

 

 

 

 

 

 

 

 

 

A

 

 

 

 

E

 

 

Some of the important SO P terms are listed as follows:

 

 

 

T

 

 

 

Value. A string, a compound of various simple types, or a measurement

name, such as date.

Simple value. A value that does not contain named parts.

Compound value. An aggregation of relations to other values.

Simple type. A class of simple values.

Compound type. A class of compound values.

Accessor. A particular related value that is held in a compound value.

Struct. A compound value in which member values are distinguished by accessor names.

Array. A compound value in which member values are distinguished by ordinal positions.

Single reference. An accessor that you can only access directly. A single reference is generally embedded.

Multiple reference. An accessor that you can access indirectly. A multiple reference is generally independent.

Embedded. An element that appears within an independent element.

Independent. An element that appears at the top level of serialization.

Locally scoped. An accessor with a distinct name within a type. However, this name is not distinct with respect to other types.

Team-Fly®

INTRODUCTION TO WEB SERVICES

Chapter 22

691

 

 

 

 

Universally scoped. An accessor with a distinct name irrespective of its type. The name of this accessor is based upon a URI.

Web Service Description Language

After developing a Web service, you need to expose the structure of the Web service components so that a client has easy access to information about your Web service, such as it message format and supported protocols. Thus, a mechanism is required that describes the logical message structure, network properties, and syntax of Web services. The Web Service Description Language (WSDL) provides such a mechanism. WSDL is an XML-based language used for describing Web services. The main advantage of WSDL is that it can be read manually as well as by computers.

WSDL uses various abstraction layers for describing Web services. You can create abstract message definitions, service definitions, and independent datatype definitions by using the special WSDL vocabulary. You can then bind abstractions to transport protocols and message formats.

XSD is used as a standard form of type definition for WSDL, though WSDL allows you to use other schema languages as well. XSD is preferred because besides having strong industry support, XSD is the preferred type mechanism for SOAP. In addition, as mentioned earlier, XSD provides a language for defining types.

The <definition> root element is used as a container for all definitions used for describing a Web service, concrete or abstract. The <types> element is used for containing schemas or external references to schemas, which describe datatype definitions that are used within WSDL documents. You can describe any number of schemas in a <types> section. WSDL also enables you to simply reference external schemas and not include any other schemas.

NOTE

It is optional for you to include the <types> section in a Web service description.

692 Project 7 CREATING WEB SERVICES

Universal Description, Discovery, and Integration (UDDI)

Whenever you need to find a Web site that contains certain content, you must be using various Web search engines to look for it. Have you wondered how users are able to locate Web services that they require? The answer lies in a specification called Universal Description, Discovery, and Integration (UDDI), which is used for searching Web services. UDDI can be thought of as a public repository for Web service information, where an operator site acts as a repository for all Web service information. Collectively, operator sites provide a Web-based registry for searching published Web services. A registry contains information about a company and the publicly exposed interfaces of the company.

NOTE

UDDI is one of the first publicly available specifications to utilize SOAP. UDDI uses the SOAP Envelope/Body model, though it does not provide support for Headers.

Figure 22-4 illustrates the functioning of UDDI.

FIGURE 22-4 Functioning of UDDI

As Figure 22-4 indicates, service providers publish information about their Web services in the registry. To locate a Web service, a service requestor can send a query to the registry. If the registry is able to locate the Web service requested by the service requestor, the service requestor can bind to the service and use it.

INTRODUCTION TO WEB SERVICES

Chapter 22

693

 

 

 

 

If a user only wants to query the registry, the user can do so by using HTTP. However, since the published information is secured, users are required to sign up with the operator site, which involves users to acquire accounts. Authenticated access to the registry is maintained by authentication tokens, which are generated for each operator site.

.NET and Web Service Security

After creating a Web service, it is imperative for you to ensure its security to protect it from misuse as well as to protect the server on which the service is running. You might wonder whether securing a Web service would have been simple if security was incorporated into the SOAP protocol. The reason why this was not done is that incorporating security within the SOAP protocol would have made interoperable operations complex. Also, incorporating security in SOAP would require complex coding and testing. In addition, the wide variety of SOAP users might differ in their security requirements. Thus, it makes more sense to apply security systems and techniques separately for each service.

While securing Web services, security measures differ depending upon whether you are securing the service on the intranet or on the Internet. In the case of an intranet, the number of clients for the service is known, whereas in the case of the Internet, an unknown number of clients might use your service.

I will first discuss the options for ensuring Web service security over the Internet.

Ensuring Web Service Security over the Internet

Two main techniques are used to deal with Web service security over the Internet. The following sections discuss these two techniques.

Using Application-Specific Authentication

In certain situations where systems offered by local operating systems are not scalable or cannot be used interoperably, you need to use custom authentication processes. You can implement a custom authentication according to your requirements. Typically, you would use a separate login Web service along with your Web service. This Web service would return an authentication token and a session token, which will be passed either into the Web service as a method parameter or

694 Project 7 CREATING WEB SERVICES

to secured Web services. After an issued session token expires, the user must again log in to the system.

Using SOAP Digital Signatures

A SOAP digital signature offers a standard SOAP Header entry, which takes a signature that complies with the XML Signature specification in which a key is related to the referenced octet data, referred to as the data object. The key is then used to transform the data object, and this transformation is included with the signature. In SOAP digital signatures, data objects form the SOAP Body.

Ensuring Web Service Security over an Intranet

Implementing security for an intranet is easier than for the Internet because you can allow a user to access your service by simply targeting the IP address of the user. There are several security options available for implementing security for Web services over an intranet. The following sections discuss these options.

Using Firewalls

Generally, firewalls are configured at most Internet servers primarily to prevent entry of external packets into the server. However, you can use firewalls to secure your Web service over an intranet by allowing groups of IP addresses to send packets and then passing those packets through a firewall. This would enable a specific network domain to access a Web service that is placed behind a firewall.

Using IP Security

IP Security (IPSec) enables you to secure Web services without modifying the code at all. This is possible because IPSec is a system-level security process that is implemented by the systems to which you must expose your Web service, such as Internet Information Server (IIS).

Using HTTP Security

IIS is used to implement HTTP Security. HTTP Security provides different techniques that offer different levels of security. HTTP Security provide the following authentication levels:

INTRODUCTION TO WEB SERVICES

Chapter 22

695

 

 

 

 

Basic HTTP Security. Requires you to provide a password even though these passwords are transmitted over the network. Thus, this level is extremely insecure.

Basic over SSL HTTP Security. Uses bulk encryption, which means that packets are encrypted in totality.

Digest HTTP Security. Encrypts only the user ID and password rather than the entire packet.

Windows Authentication HTTP Security. Verifies the user ID and password by using Windows security subsystems.

Client Certificates HTTP Security. Requires a user to provide a digital certificate to access the Web service. This level provides the highest level of security.

Using ASP.NET Authentication

ASP.NET provides for authentication by using the following three authentication providers:

Windows authentication. This authentication provider provides authentication at two levels: at the server level, which is IIS, and at the application level, which is ASP.NET. Authentication is done first at the IIS level and then at the ASP.NET level.

Forms authentication. This authentication provider requires a user to enter user information in a form that you have specified.

Passport authentication. This authentication provider authenticates user credentials by using the Microsoft Passport authentication service.

I have discussed the various techniques used for ensuring Web service security over an intranet as well as the Internet. In .NET, you can secure a component by associating specified permissions with an assembly. Access to code in .NET is based on the combination of the following three components:

Permissions. Objects representing authorization for secured access to resources.

Policies. Carry permissions that you have assigned to each role (which is assigned to each group of users).

Evidence. Represents information that is specific to the assembly. This information is known to the runtime environment.

696 Project 7 CREATING WEB SERVICES

The preceding three aspects of securing code access together determine whether a user is authorized to use a specific assembly.

Summary

This chapter gave you an overview of Web services and the technologies related to them. You were first introduced to Web services and their functioning. In addition, you learned about the Web service architecture. Next, you learned about the various technologies related to Web services. You were introduced to XML and its various specifications. You also learned about XSD. You then learned about SOAP, WSDL, and UDDI. Finally, you learned about securing Web services.

Chapter 23

Creating a Web

Service Using

Managed

Extensions

You have read about Web services and a few related technologies. Based on that information, you might have concluded that creating Web services is a very complex task — a task that requires in-depth knowledge of XML, UDDI, WSDL, and so on. However, Visual Studio .NET does a very good job of simplifying the process of creating a Web service by encapsulating most of the tedious stuff and

allowing you to concentrate on the actual functionality of the Web service.

In Visual C++ .NET, you have the flexibility to create Web services by using either Managed C++ or the ATL Server. In this chapter, you will create a Web service using Managed C++ and also take a brief look at some of the underlying technologies. In the next chapter, you will learn to create a Web service using the ATL Server.

To begin with, consider the scenario of the Art-Shop gallery, which needs a Web service.

Art-Shop Associates Program

The promoters of Art-Shop realized that for an upcoming online store with a small Internet presence, a limited advertising budget, and a specific range of products, it is very difficult to build a significant online presence fast enough. To sell its products more aggressively, Art-Shop has reached agreements with other online stores and general portals whereby all of Art-Shop’s products displayed on the art-shop.com site will be displayed on these associate sites. Art-Shop hopes that this will increase the sales of its products to a great extent, because now the products are not restricted to Art-Shop’s site, but also are available on other sites.

The management of Art-Shop will pay these associate sites a commission for selling its products. The product range and data, from the Art-Shop database, has to be exposed to these sites for them to be able to display the art objects on their pages. Also, when a purchase is made at the associate site, the site should be able to place an order at art-shop.com.

With the requirements in place, the management once again approached the Code-Forge team to provide a solution. In the upcoming sections, you will see the

CREATING A WEB SERVICE USING MANAGED EXTENSIONS Chapter 23 699

activities performed by the Code-Forge team during the different phases of the project life cycle. By the time you reach the end of this chapter, you will have gained the skills to create a Web service using Managed C++.

Project Life Cycle

In the project-initiation phase, the project plan was finalized and the development team was also identified. The development team further prepared a comprehensive list of tasks involved in the execution and the deployment phases of the project’s life cycle.

Moving further, you will look at the tasks performed by the development team in the following stages of the project-execution phase:

Requirements analysis

Design

Construction

Testing

In the subsequent sections, I will be detailing the tasks performed by the team in each of these stages.

Requirements Analysis

During the requirement analysis phase, the Code-Forge team analyzed the requirements of the Associate program, which is the name assigned to the project. After analyzing the same, the team came up with the following list of requirements:

The product range should be available to the associates’ Web sites so that they can sell it online, integrated with their own content.

Some functionality must be exposed by the art-shop.com site, which will allow associate sites to automatically place an order whenever a sale is made through their site.

The data should be available in a standard format to be usable by different Web sites.

Based on these requirements, the team arrived at a consensus that Web services would best suit these requirements, the rationale being that Web services have a global reach.