Module 2: XML Web

Service Architectures

Contents

Overview 1
Service-Oriented Architecture 2
Lesson: Web Services Architectures and
Service-Oriented Architecture 4
Lesson: Roles in a Web Services
Architecture 8
The Web Services Programming Model 16
Review 18
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, places or events is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2001-2002 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, Active Directory, Authenticode, IntelliSense,

FrontPage, JScript, MSDN, PowerPoint, Visual Basic, Visual C++, Visual C#, Visual Studio,
Win32, and Windows Media are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
 Module 2: XML Web Service Architectures iii

Instructor Notes
Presentation: This module broadly describes the service-oriented architecture, which is a
60 Minutes conceptual architecture. Then, the module explains how XML (Extensible
Markup Language) Web service architectures are a type of service-oriented
Lab: architecture. It also describes the various roles within the Web service
00 Minutes architecture.
After completing this module, students will be able to:
„ Identify how Web service architectures are a type of service-oriented
architecture.
„ Describe the elements of a Web service architecture and explain their roles.
„ Describe the Web service programming model.

Required Materials To teach this module, you need the Microsoft® PowerPoint® file 2524C_02.ppt.
Preparation Tasks To prepare for this module:
„ Read all of the materials for this module.
„ Try out the demonstration.
iv Module 2: XML Web Service Architectures

Demonstration
This section provides demonstration procedures that are not appropriate for the
student notes.
An Electronic Funds
Transfer Web Service
Ç To demonstrate the NorthwindClient application
1. Start the application NorthwindClient.exe, which can be found in the folder
install_folder\Labfiles\CS\Lab08_2\Solution\NorthwindClient\bin\Debug or
install_folder\Labfiles\VB\Lab08_2\Solution\NorthwindClient\bin.
2. In the From list, click Woodgrove Online Bank.
3. In the To list, click Contoso Micropayments.
4. Click Transfer.
5. Explain that $100 has been transferred from an account at the Woodgrove
Bank to an account at the micropayment service, named Contoso.
6. Explain that the Northwind Traders Web service took care of all the details
of managing the transfer, including retrieving routing numbers, and so on.

Ç To show the Service Description pages for the Northwind, Woodgrove,

and Contoso Web services
1. Open three separate browser windows.
2. In the first browser window, navigate to the following URL:
http://localhost/Northwind/Traders.asmx
3. In the second browser window, navigate to the following URL:
http://localhost/Woodgrove/Bank.asmx
4. In the third browser window, navigate to the following URL:
http://localhost/Contoso/Micropayment.asmx
5. Describe the relationship between the methods that are listed on each of the
Service Description pages. Emphasize that the Northwind Web service is a
client of the other two Web services.
• Northwind/Traders/GetTransferSources returns information about the
Woodgrove Web service.
• Northwind/Traders/GetTransferSinks returns information about the
Constoso Web service.
• Northwind/Traders/EFTTransfer completes a transfer between the
source (Woodgrove) and the sink (Contoso).
• Woodgrove/Bank/TransferFunds debits the supplied account by the
supplied amount.
• Woodgrove/Bank/AuthorizeFundsTransfer ensures that the account to
transfer funds from can cover the transfer.
• Woodgrove/Bank/GetTransactionHistory returns a list of transactions on
an individual account in the given time frame.
• Woodgrove/Bank/GetAllAccounts returns a list of all accounts for a
user.
 Module 2: XML Web Service Architectures v

• Woodgrove/Bank/GetAccount returns information about an individual

account.
• Contoso/Micropayment/GetMembershipInformation returns an XML
document with information about the different membership levels that
the Contoso Micropayment service supports.
• Contoso/Micropayment/CreditAccount credits the supplied account with
the supplied amount.
• Contoso/Micropayment/GetTransactionHistory returns a list of
transactions for an individual user in the given time frame.
• Contoso/Micropayment/DeleteAccount deletes an individual account.
• Contoso/Micropayment/GetAccount returns information about an
individual account.

Ç To show that money is transferred between the accounts

1. Click the GetAccount link on the Service Description page to open the
Service Method Description page for the GetAccount method of the
Woodgrove Web service.
2. In the acctID box, type the account number by using the value of the
AccountID field for the From account in NorthwindClient.exe, and then
click Invoke.
XML data that contains the results of the method call is displayed.
3. Point out the value in the balance element in the XML document.
4. Click the Transfer button in the client application, NorthwindClient.exe.
5. Click the Refresh button on the browser window that displays the XML
document.
6. Point out that the balance has been reduced by 100.
vi Module 2: XML Web Service Architectures

Module Strategy
Use the following strategy to present this module:
„ Service-Oriented Architecture
Explain what a service-oriented architecture is. This topic is intended to
provide the students with a conceptual framework to be able to understand
the architecture of Web service-based solutions.
„ Web Service Architectures and Service-Oriented Architecture
Explain the relationship between the conceptual service-oriented
architecture and Web services architectures. Use the demonstration of the
solution of the final lab in the course to show each of the Web service
architectural elements as concrete implementations.
„ Roles in a Web Service Architecture
This topic examines the specific roles in Web service architecture and
explains that the Microsoft .NET Framework can provide assistance in
implementing the functionality for each of the entities that plays a role.
„ The Web Services Programming Model
Describe the features of the Web services programming model. Emphasize
how this model is different than the traditional stateful, monolithic
programming model. However, defer any in-depth discussion on how the
Web services programming model affects the design of XML Web services
until Module 8, “Designing XML Web Services,” in Course 2524,
Developing XML Web Services Using Microsoft ASP.NET.
 Module 2: XML Web Service Architectures 1

Overview

*****************************illegal for non-trainer use******************************

Introduction In this module, you will begin by looking at service-oriented architecture as a

conceptual architecture for distributed applications. Next, you will examine
how solution architectures that are based on XML (Extensible Markup
Language) Web services are a type of service-oriented architecture. Then, you
will examine each of the roles in a Web service architecture. Finally, you will
look at the kind of programming model that a Web service architecture
imposes.
Objectives After completing this module, you will be able to:
„ Identify how Web services architectures are a type of service-oriented
architecture.
„ Describe the elements of a Web services architecture and explain their roles.
„ Describe the Web service programming model.
2 Module 2: XML Web Service Architectures

Service-Oriented Architecture

*****************************illegal for non-trainer use******************************

Introduction To build flexible, robust distributed applications, there are a number of

requirements that must be met:
„ When integrating software resources, the resources must be loosely coupled;
that is, resources must be distinct and separate.
„ Interprogram communication must be compliant with Internet standards.
„ The service interfaces of software resources must be published for public
use, and the interface definitions and documentation must be publicly
accessible.

Building applications that meet the preceding requirements can result in the
following advantages:
„ You can construct applications by integrating core business processes with
outsourced software services and resources.
„ You can create more granular software resources.
„ Reusable third-party software resources can provide cost and productivity
benefits.
„ The sale of software as services can become widespread. For example, a
company could sell a shared calendar service as a Web accessible service
instead of selling a stand-alone calendar application.
 Module 2: XML Web Service Architectures 3

Elements of a service- A service-oriented architecture is ideal for implementing such distributed

oriented architecture applications. It is a conceptual architecture for implementing dynamic, loosely
coupled, distributed applications.
Today, most business systems and applications are made up of tightly coupled
applications and subsystems. When applications and subsystems are tightly
coupled, a change to any one subsystem can cause many dependent components
or applications to fail. This brittleness of existing systems is one of the primary
reasons for the high cost of maintaining them; it also limits how easily the
applications can be modified to satisfy changing business requirements.
A service-oriented architecture consists of three primary roles: service provider,
service consumer, and service broker. A diagram of this architecture is shown
on the preceding slide.
Service provider A service provider is a node on the network (intranet or Internet) that provides
access to the interface to a software service that performs a specific set of
operations. A service provider node provides access to the services of a
business system, a subsystem, or a component.
Service consumer A service consumer is a node on the network that binds to a service from a
service provider and uses the service to implement a business solution. In the
service-oriented architecture model, service consumers are not applications, but
nodes. However, for the purpose of this course, we will view a service
consumer as a client application on a node.
Service broker A service broker is a node on the network that is a repository of service
descriptions and can be used like an address book to find the location of
services. Service consumers can interrogate a service broker to locate a required
service provider and service. Service brokers will often also act as service
providers in cases where the requested service is service brokering.
Interaction between the The preceding three service-oriented architecture roles interact to perform three
roles basic operations:
„ Publish services
Service providers publish their services to a service broker. The information
published includes the service interface definition, location of service
providers, and possibly other supporting information or documentation.
„ Find services
Service consumers find required/desired services by using a service broker.
„ Bind to services
Service consumers bind to specific services that are provided by a service
provider. The binding process includes authentication of consumers.

Both finding and binding to services can be done dynamically to allow

applications to configure themselves dynamically. For example, if an
application finds that the response time from a service provider has become
unacceptable, then it might decide to switch to another service provider at run
time.
4 Module 2: XML Web Service Architectures

Lesson: Web Services Architectures and Service-

Oriented Architecture

*****************************illegal for non-trainer use******************************

Before delving into the details of implementing and using Web services, it is
important to understand how a Web service architecture is a type of service-
oriented architecture.
First, you will examine Web service architectures. Next, you will examine the
mapping between elements of the Web service architecture and elements of the
service-oriented architecture. Finally, you will view a demonstration of a
working example of a Web service solution, specifically the components of the
solution architecture.
 Module 2: XML Web Service Architectures 5

Overview of Web Service Architectures

*****************************illegal for non-trainer use******************************

The basic elements in a Web service architecture are:

„ The Web service provider, which is a network node hosting a Web service.
„ The Web service consumer, which is a network node hosting any client that
can communicate by using Hypertext Transfer Protocol (HTTP). The clients
include browsers, console applications, and traditional graphical user
interface (GUI) applications.
„ The Web service broker, which is a network node hosting a global registry
of available Web services much like a global address book.

All of these network nodes should be able to communicate with each other
typically through a Transmission Control Protocol/Internet Protocol (TCP/IP)
based network.
The diagram on the slide shows the relationship among the various elements of
a Web service architecture. The rest of this module focuses on how the
elements of a Web services architecture correspond to service-oriented
architecture and then focuses on the various elements of the architecture.
6 Module 2: XML Web Service Architectures

Web Services As an Implementation of a Service-Oriented

Architecture

*****************************illegal for non-trainer use******************************

Introduction In a solution based on Web services, the three network nodes defined in a
service-oriented architecture correspond to the elements of the Web services
solution.
The service broker in The role of a service broker is primarily fulfilled by a node that hosts a
Web services Universal Description, Discovery, and Integration (UDDI) registry. You will be
introduced to UDDI later in this module. For more complete coverage of
programming Web services and Web service consumers by using UDDI, see
Module 6, “Deploying and Publishing XML Web Services,” in Course 2524,
Developing XML Web Services Using Microsoft ASP.NET.
The service provider in The role of a service provider is fulfilled by nodes that expose Web services
Web services through ASP.NET pages with the extension .asmx. For more information about
the implementation details, see Module 5, “Implementing a Simple XML Web
Service,” in Course 2524, Developing XML Web Services Using Microsoft
ASP.NET.

Note The entry points to Web services that are implemented by using
ASP.NET are Web pages with the extension .asmx.

The service consumer in The role of a service consumer is fulfilled by any node that can communicate
Web services by using Simple Object Access Protocol (SOAP) or HTTP, understands the
service interface that is being used, and can supply the necessary authentication
credentials.
 Module 2: XML Web Service Architectures 7

Demonstration: An Electronic Funds Transfer Web Service

*****************************illegal for non-trainer use******************************

In this demonstration, you will see an actual implementation of the concepts

that you learned in the previous two topics. The demonstration will focus on
how to create a Web services-based solution for a sample electronic funds
transfer. You will build your own version of this solution in the labs for
Course 2524, Developing XML Web Services Using Microsoft ASP.NET.
8 Module 2: XML Web Service Architectures

Lesson: Roles in a Web Services Architecture

*****************************illegal for non-trainer use******************************

Earlier in this module, you saw that a Web service architecture consists of the
following elements: Web service provider, Web service consumer, and Web
service broker. We will now briefly examine each of these roles.
 Module 2: XML Web Service Architectures 9

The Web Service Provider

*****************************illegal for non-trainer use******************************

Introduction One of the important roles in a Web service architecture is that of the Web
service provider. In this topic, you will examine the infrastructure that a Web
service provider makes available to support and host Web services.
Some examples of the infrastructure that a Web service provider (a network
node) must provide to a Web service are HTTP protocol handling and
authentication services. If a Web service provider cannot offer such
infrastructure, then the Web service must support this infrastructure. However,
this would make developing Web services much more difficult.
You will examine some of the infrastructure that is provided when using
Microsoft Internet Information Services (IIS) and Microsoft ASP.NET on a
computer running Microsoft Windows® as the Web service provider.
Web servers At a minimum, a Web service provider must include a protocol listener. For
Web services that are developed by using the Microsoft .NET Framework and
Microsoft Visual Studio® .NET, the protocol listener must be an HTTP listener.
Because a Web service provider might be hosting multiple Web services, it
must also be able to direct the request to an appropriate Web service. This is
analogous to the Remote Procedure Call Subsystem (RPCSS) service that is
responsible for handling incoming Distributed Component Object Model
(DCOM) requests and directing them to an appropriate Component Object
Model (COM) server.
Unknown Web service consumers can access a Web service provider.
Therefore, at a minimum, the Web Server must provide basic security services
at the protocol level.
10 Module 2: XML Web Service Architectures

Microsoft Internet Information Services (IIS), which is a Web server, provides

all of the services that a Web service requires through its features:
„ IIS is an HTTP listener.
„ IIS can act as a gateway to the implementations of the various Web services
that it may host, through its pluggable Internet Server Application
Programming Interface (ISAPI) architecture.
„ IIS provides significant security infrastructure.
You will see how to secure Web services by using the security capabilities
of IIS in Module 7, “Securing XML Web Services,” in Course 2524,
Developing XML Web Services Using Microsoft ASP.NET.

IIS and Web services A Web server such as IIS can invoke a service on behalf of a client, by using
many different options. A Web server can start a Common Gateway Interface
(CGI) application; run a script interpreter as done in Microsoft Active Server
Pages (ASP), or invoke an ISAPI application.
When IIS works in conjunction with the common language runtime, it uses an
ISAPI filter to intercept requests for pages with the extension .asmx, and then
start a run-time host. The run-time host then executes the code for a Web
service that is implemented by using the .NET Framework.
IIS is not restricted to hosting .NET-based Web services. It can also host
Microsoft Active Template Library (ATL) Server-based Web services. ATL
Server-based Web services are beyond the scope of this course. However,
.NET-based Web service provides some significant advantages. One of the
most important advantages is the flexible security infrastructure that .NET
technology provides. For more information, see Module 7, “Securing XML
Web Services,” in Course 2524, Developing XML Web Services Using
Microsoft ASP.NET.
Examples of Web If an organization wants to provide Web services, it must be capable of
service providers providing some kind of electronic service. Because almost any piece of
functionality can be classified as a service, it is impossible to enumerate all the
possible kinds of Web services. However, two common examples of Web
service providers are independent software vendors and general-purpose
business processes.
Independent software vendors own products that perform a variety of tasks.
These products can be exposed as individual Web services or aggregations of
Web services. For example, a company that sells a calculation application for
personal taxes might want to make that application accessible as a Web service.
General-purpose business processes, which are sufficiently generalized for
adoption by a wide variety of clients, can also be exposed as Web services. For
example, a payroll processing service can offer its payroll management services
as a Web service.
 Module 2: XML Web Service Architectures 11

The Web Service Consumer

*****************************illegal for non-trainer use******************************

Introduction In this topic, you will look at the minimum set of functionality required for a
Web service consumer to use a Web service. You will also look at how a
consumer locates a Web service; the role of proxies in simplifying the
implementation of Web service consumers; and how to use proxies to make
asynchronous calls to Web services.
Minimum functionality To consume a Web service, a Web service consumer must call the methods of a
Web service with the appropriate parameters by using the protocols (for
example, SOAP) that the service supports.
It is difficult to correctly format messages before passing them to a Web
service, and it is also difficult to handle the details of the protocols that the Web
service supports. The .NET Framework provides classes that encapsulate most
of the low-level details. Encapsulating the low-level details frees the developer
from having to implement the infrastructure.
Service location Before a Web service can be used, a consumer must be able to locate it.
Locating a Web service can be done statically by hard-coding the endpoint in
the Web service consumer at design time. Alternately, the Web service
consumer can dynamically discover the location of a Web service at run time.
This provides a Web service consumer with the flexibility of choosing between
equivalent, competing Web services based on criteria such as price or
performance.
The standard mechanism for locating appropriate Web services, their service
description, and their endpoints is through a UDDI registry. For more
information about how a Web service consumer can make use of UDDI to
locate a Web service and how to advertise a Web service in a UDDI registry,
see Module 6, “Deploying and Publishing XML Web Services,” in
Course 2524, Developing XML Web Services Using Microsoft ASP.NET.
12 Module 2: XML Web Service Architectures

Proxies When implementing a Web service consumer, developers can spend their time
more productively on other issues, and should not have to concern themselves
with the following tasks:
„ Working with the underlying protocols.
„ Parsing byte streams to extract data.
„ Validating the inbound data streams.
„ Constructing the outbound data packets.

However, the developer is often forced to handle the preceding tasks because
there is no prebuilt code available to perform these tasks. A typical approach to
handling these tasks is to encapsulate or hide the implementation details in a
wrapper class that acts as a proxy for the Web service. Not only can the proxy
classes hide implementation details, but they also provide the developer with a
familiar programming model of calling methods on objects.
The only problem with this technique is that a proxy class must be implemented
for every Web service interface that a Web service consumer wants to interact
with.
Microsoft provides a tool called Wsdl.exe to implement Web service proxy
classes. However, there are some pitfalls inherent in making the programming
interface to a Web service appear like a local procedure call. For more
information, see Module 4, “Consuming XML Web Services,” and Module 8,
“Designing XML Web Services,” in Course 2524, Developing XML Web
Services Using Microsoft ASP.NET.
Because a Web service interface is defined by using XML, it is also fairly
straightforward to write tools that can automatically generate the proxy wrapper
classes.
Asynchronous calls Because Web services are usually accessed over networks that are not as
reliable or fast as local area networks (LANs), it is often better to implement
Web service consumers that make asynchronous calls to Web services. The
proxies that are generated by using Wsdl.exe allow the caller to make
asynchronous calls to a Web server. The proxy class in conjunction with the
runtime handles details of thread pool management, the completion of a
callback notification method, and so on. For more information about how to
make asynchronous calls to a Web service, see Module 4, “Consuming XML
Web Services,” in Course 2524, Developing XML Web Services Using
Microsoft ASP.NET.
Examples of Web Line-of-business applications will probably be the primary users of Web
service consumers services, but there a number of types of businesses that could be Web service
consumers. Two examples of these types of businesses are online newspapers
and an Application Service Provider (ASP).
An online newspaper might use multiple Web service news feeds. The
incoming news feeds could be formatted, filtered, catalogued, and made
searchable according to customer preferences.
An Application Service Provider (ASP) might host Web services, re-brand Web
services, or do both. Also, an ASP might aggregate multiple Web services and
offer the composite Web service to its customers.
 Module 2: XML Web Service Architectures 13

The Web Service Broker

*****************************illegal for non-trainer use******************************

Introduction Just as a service–oriented architecture needs a service broker, a Web service

architecture also needs a service broker. To facilitate interactions, businesses
need a comprehensive solution to publish their information to any customer or
business partner around the world. A Web service broker interacts with both
Web service providers and Web service consumers to provide this functionality.
A common means of publishing information about business services will make
it possible for organizations to:
„ Quickly discover the correct trading partners out of the millions that are
online.
„ Define how to conduct business after preferred businesses are discovered.
„ Create an industry-wide approach for businesses to quickly and easily
integrate with their customers and partners on the Internet. Organizations
will be able to share information about their products and services, and how
they prefer to be integrated into each other’s systems and business
processes.
14 Module 2: XML Web Service Architectures

Interactions between Brokers specify to providers what kinds of information needs to be made
brokers and providers public, and then publishes this information. The kinds of information published
by a broker include:
„ Classification information to allow Web services to be categorized.
„ Contact information for the Web service.
„ A textual description of the offered services.
„ Links to documents providing information about the Web services that the
provider hosts.
„ The location of endpoints for Web services.
These locations are usually stored as Uniform Resource Locators (URLs)
that denote the location of the advertised Web services. Because it is not
feasible to specify all of the information in the broker’s repository, there
may be pointers to URLs or file-based resources that will facilitate further
discovery. For example, service-level guarantees or information regarding
authentication requirements may be discoverable only at a Web service
provider’s location.

Interactions between The primary interaction between Web service consumers and the Web service
brokers and consumers broker is related to searching. Brokers must facilitate the search of their
repository to enable Web service consumers to locate the appropriate Web
service and then discover the information that is required to bind to that Web
service.
UDDI registries There are many approaches to providing the Web service brokering services.
One simple approach is to have all of the potential trading partners
communicate binding information to each other by using a specific method
created for that purpose. In this approach, you specifically do not require a
broker. For example, some organizations using electronic data interchange
(EDI) simply publish the list of required EDI document specifications that the
trading partners must use on a Web site. The problem with this approach is that
there is no easy way to discover which of the external businesses is compatible
with your business.
Another approach is to have all of the businesses publish a Web services
description file on their Web site. Then, Web crawlers can automatically access
a registered URL and can index the description files for the Web services that
are found at each Web site. A Web service broker could then provide a portal
that gives access to the indexes that the Web crawlers build. Relying on Web
crawlers to provide indexes for Web services has similar problems to the
problems encountered with standard Web search engines and catalogs that we
have today. The problem is that there is no mechanism to ensure consistency in
service description formats and for the easy tracking of changes whenever they
occur. Just as Web search engines return many invalid links, such a mechanism
for Web services would also result in out-of-date service descriptions and
binding information.
The brokering approach that has been chosen for Web services relies on a
distributed registry of businesses and their service descriptions that are
implemented in a common XML format. The solution that implements this
approach to solving the discovery problem is known as Universal Description,
Discovery, and Integration (UDDI).
 Module 2: XML Web Service Architectures 15

UDDI is a specification for distributed Web-based information registries of

Web services. UDDI is also a public set of implementations of the specification
that allow businesses to register information about the Web services that they
offer so that other businesses can find them.
The core component of a UDDI-compliant registry is a business registration
element, which is a file that describes a business entity and its Web services.
Conceptually, the information specified in a business registration has three
parts:
„ Business addresses, contact information, known identifiers, and so on.
„ Lists of industrial categorizations that are based on standard taxonomies.
„ The technical information about the Web services that the business exposes.
This information includes references to Web service interface specifications,
and potentially, pointers to various file- and URL-based discovery
mechanisms.

For more information about how to publish an XML Web service in a UDDI-
compliant registry and how to search a UDDI-compliant registry to locate Web
services, see Module 6, “Deploying and Publishing XML Web Services,” in
Course 2524, Developing XML Web Services Using Microsoft ASP.NET.
16 Module 2: XML Web Service Architectures

The Web Services Programming Model

*****************************illegal for non-trainer use******************************

Introduction To successfully implement or consume a Web service, it is important to

understand the key features of the Web services programming model. It is also
important to understand some of the ramifications of the programming model.
Web protocols The first feature of the Web services programming model is that the
communications protocol will typically be HTTP. However, HTTP does not
intrinsically support the concept of a method invocation. Because of this
constraint, Web service consumers often use the XML-based SOAP over HTTP
for invoking the Web service methods. Therefore, it is essential for a developer
to have at least a working knowledge of both HTTP and SOAP. For more
information about HTTP, XML, and SOAP, see Module 3, “The Underlying
Technologies of XML Web Services,” in Course 2524, Developing XML Web
Services Using Microsoft ASP.NET.
Stateless Most developers are familiar with a stateful object model. In other words, an
instance of a class is created and then various operations are performed on the
object. Between each method invocation, the object maintains its state. In a
stateless environment, the object retains no state between calls. Any state that
must be persisted between calls can be stored in a database or a cookie.
Web services are not objects in the traditional sense. When using ASP.NET to
implement a Web service, you can use a C# class to implement it. This class is
referenced by an ASP.NET page with the extension .asmx. When the page is
processed, an instance of this class is created. The lifetime of the .asmx page
binds the lifetime of the resulting object, which means that a different object
instance will handle every method invocation. As a result, the classes that
implement a Web service are stateless. Although designing stateless systems
can be initially more difficult, stateless systems can easily scale-out as the load
on the system increases.
 Module 2: XML Web Service Architectures 17

For more information about how to design stateless Web services and how to
manage state in stateless Web services, see Module 8, “Designing XML Web
Services,” in Course 2524, Developing XML Web Services Using Microsoft
ASP.NET.
Loosely coupled In a nondistributed application, if any of the required software resources, such
as a function library in a dynamic-link library (DLL), are available when an
application is launched, they will continue to be available for the lifetime of the
application. Usually, they will also be available on each successive use of the
application. For distributed applications, especially distributed applications that
make use of software resources over the Internet, there is an increased
likelihood that the required software resources will not always be available.
Therefore, distributed applications that are implemented by using Web services
must be more resilient to software resources becoming unavailable, even at run
time.
As a consequence, Web service-based solutions must be loosely coupled so that
they can dynamically reconfigure themselves if a resource becomes
unavailable. Loosely coupled applications also have the advantage of allowing
failover because the consumers will not have affinity with any particular
instance of a Web service.
For more information about how to design Web services to facilitate loose-
coupling, and also learn how to implement loosely coupled Web services, see
Module 8, “Designing XML Web Services,” in Course 2524, Developing XML
Web Services Using Microsoft ASP.NET.
Universal data format The universal data format that is used in Web services is XML. A complete
coverage of XML is beyond the scope of this course, but a working knowledge
of XML is imperative to implement and consume Web services.
The following are a few of the areas where XML is used in Web services:
„ The SOAP protocol is XML-based.
„ Web service descriptions are XML documents.
„ Data returned from a Web service is in an XML document.
„ Web services are registered with a UDDI registry by using XML documents
that are business service descriptions.
„ ASP.NET applications are configured by using XML configuration files.
18 Module 2: XML Web Service Architectures

Review

*****************************illegal for non-trainer use******************************

1. What are the three main components of a service-oriented architecture?

• Service provider
• Service consumer
• Service broker

2. What service-oriented architecture role does a network node with IIS and
the runtime have in a Web service architecture?
Web service provider
 Module 2: XML Web Service Architectures 19

3. Which wire format is used by a Web service and a Web service consumer to
communicate with each other?
SOAP

4. Name two of the characteristics of the Web services programming model.

The answers can be any two of the following:
• Use Web protocols
• Are stateless
• Are loosely coupled
• Use XML as the universal data format
THIS PAGE INTENTIONALLY LEFT BLANK