SolutionsTechnical Guide
February 2002
168Z-0202A-WWEN
Prepared by:
Internet & E-Commerce Solutions
Compaq Computer Corporation
Microsoft .NET Web Services
Solutions
Contents
Abstract: This document identifies the technologies associated with
Microsoft XML Web Services and documents best practices for
developing, deploying, consuming, securing, and managing a Web
service. This document also discuses the performance, scaling, and
availability concerns of Web Services. .NET is Microsoft’s
implementation of an Internet application development platform
using a suite of technologies, tools, products, and standard protocols.
The .NET Platform is used to develop XML Web Services (or .NET
Web Services), which are Microsoft’s implementation of Web
services. An XML Web Services prototype example, with associated
source code, is provided in an appendix of the document.
Introduction ................................. 3
What is a Web Service? .............. 3
Microsoft .NET ............................. 3
Microsoft Web Services .............. 4
.NET Technologies Used to
Develop an XML Web
Service ....................................... 4
Deployment of XML Web
Services ..................................... 6
Consuming a .NET Web
Service ....................................... 7
Private Web Services ................ 8
Public .NET Web Services ......... 9
Performance Considerations ... 10
Security Considerations ........... 10
Discoverable Web Service
(UDDI) ..................................... 14
Management of Web
Services ................................... 16
DISA and a Web Services ......... 20
The DISA Architecture ............. 20
DISA Key Principles................. 21
Conclusion ................................. 22
APPENDIX A - Microsoft’s
CLR ............................................. 23
APPENDIX B - Example ............ 25
Overview of a B2B Web
Service Demonstration ............ 25
Sample Web Service
Processing Flow ...................... 29
Files and Code Samples of
Sample Process Flow .............. 31
APPENDIX C - System
Software ..................................... 35
APPENDIX D – References ....... 37
APPENDIX E - Glossary ............ 43
The target audience of this document is any individual who needs a
better understanding on how to develop, deploy, consume, secure, or
manage a Web service. The reader should already understand
Microsoft’s .NET and Web Services concepts.
Microsoft .NET Web Services Solutions
2
Notice
This publication does not constitute an endorsement of the product or products that were tested. The
configuration or configurations tested or described may or may not be the only available solution. This test
is not a determination of product quality or correctness, nor does it ensure compliance with any federal,
state or local requirements.
Compaq, the Compaq logo, ActiveAnswers, Compaq Insight Manager, SmartStart, SoftPaq, and ProLiant
are trademarks of Compaq Information Technologies Group, L.P. in the U.S. and/or other countries.
The .Net logo, Microsoft, Windows, Windows NT, BizTalk, SharePoint, Visio, Visual Basic, Visual C#,
Visual Studio, Win32, and Visual C++ are trademarks of Microsoft Corporation in the U.S. and/or other
countries.
All other product names mentioned herein may be trademarks of their respective companies.
Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information
is provided “as is” without warranty of any kind and is subject to change without notice. The warranties for
Compaq products are set forth in the express limited warranty statements accompanying such products.
Nothing herein should be construed as constituting an additional warranty.
©2016 Compaq Information Technologies Group, L.P.
Microsoft .NET Web Services Solutions
Solutions Guide prepared by Internet & E-Commerce Solutions
First Edition (February 2002)
168Z-0202A-WWEN
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
3
Introduction
Today most businesses on the Internet revolve around websites, which typically do a good job of
providing information to a user. These websites can support transactions and commerce using the
Internet. Typically, these websites fall into two general categories: a static or brochure type of
site, or a dynamic or commerce site.
Other types of businesses on the Internet include non-website-centric businesses like Business-toBusiness (B2B) and market exchanges. These types of businesses are still evolving and are a
fertile ground for the technology referred to in this document.
For these businesses to evolve on the Internet, they must use methods to interact with one another
as well as with users, other applications and systems.
Web services represent the evolution of the website. Taking the modular aspects of modern
software applications and allowing them to communicate through standard Internet protocols,
such as XML1 and SOAP2, Web services offer a direct means by which business processes can
interact. Applications hosted internally, as well as on remote systems, can be stitched together,
allowing businesses to program the Web—quickly and economically creating specialized
solutions that meet unique business needs.
Compaq enhances Microsoft .XML Web Services by providing an implementation and
deployment blueprint as well as a set of recommended best practices based on years of experience
deploying the Compaq Distributed Internet Server Array (DISA) architecture. Microsoft XML
Web Services can be readily deployed in a highly available and scalable fashion using the DISA
architecture. This document addresses how to decrease both the implementation time and risk
associated with the deployment of Microsoft XML Web Services.
What is a Web Service?
A Web service is a piece of business functionality exposed via Internet protocols. Web services
are Internet-based modular applications that perform a specific business task and conform to a
specific technical format. The modular technical format allows for these self-contained business
services (from the same or different companies) to mix and match easily to create a complete
business process.
Microsoft .NET
.NET is Microsoft’s implementation of an Internet-application-development platform using a
suite of technologies, tools, products, and standard protocols. The .NET Platform is used to
develop XML Web Services, which are Microsoft’s implementation of Web services.
There are many definitions for what .NET is (and is not). It is not within the scope of this
document to define .NET, but to discuss Microsoft XML Web Services in the context of .NET
technologies. Below are just a few of the definitions currently available for Microsoft .NET:
1 An initiative from the W3C defining an "extremely simple" dialect of SGML suitable for use on the World-Wide Web.
http://www.w3.org/TR/REC-xml.html
2
Simple Object Access Protocol (SOAP) is a lightweight protocol for exchange of information in a decentralized, distributed
environment. It is an XML-based protocol that consists of four parts: an envelope that defines a framework for describing what is in
a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, a convention for
representing remote procedure calls and responses, and a binding convention for exchanging messages using an underlying protocol.
http://www.w3.org/TR/2001/WD-soap12-20010709/ http://www.soaprpc.com/mirror/ietf/draft-box-http-soap-01.txt.html
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
4

“Microsoft .NET is an XML Web services platform that will enable developers to create
programs that transcend device boundaries and fully harness the connectivity of the Internet.”
(Source: Microsoft: Welcome to the MSDN Library)

“Microsoft’s .NET is a company-wide effort to move Microsoft’s developers, products,
customers, and services from the client-server computing model to Microsoft’s vision of the
Web services model” (Source: The Burton Group: Network Strategy Report)

“.NET is an all-inclusive Web-based software architecture for internal and external use.
Microsoft browsers, applications and new versions of Windows will be .NET enabled.”
(Source: TechWeb Encyclopedia)

“When you look at the fundamentals about what's happening with .NET, this is the ability to
really create a very rapid deployment at a much lower cost of Internet applications,’ Michael
Capellas, CEO of Compaq Computer Corp., told reporters during a break in the meeting. ‘It's
freeing our applications developers not to have to worry about all the basic-level services. It
lowers the cost and creates a much better user experience on the front end,’ he added. ‘It
actually finally allows us to really come with a much, much more rapid development process
around Internet applications.’ Calling .NET ‘a major move,’ he emphasized that Compaq is
‘going full-bore behind" the strategy.’ ” (Source: BridgeNews Bulletins, Thursday, May 24,
2001)
Microsoft Web Services
Microsoft XML Web Services are Microsoft’s implementation of XML-based Web services and
are developed using .NET platform technologies. This section of the document assists the reader
with some of the infrastructure issues associated with deploying .NET Web Services.
.NET Technologies Used to Develop an XML Web Service

.NET Enterprise Servers:
–
Application Server 2000
–
BizTalk Server 2000
–
Commerce Server 2000
–
Content Management Server 2001
–
Exchange Server 2000
–
Host Integration Server 2000
–
Internet Security and Acceleration Server 2000
–
Mobile Information Server 2001
–
SharePoint Portal Server 2001
–
SQL Server 2000

Windows 2000 Servers: (Windows Family Home Page)

.NET Framework: (.NET Framework). A Windows run-time environment that provides an
enhanced set of system-level functionality designed to assist in the development and
management of Microsoft XML Web Services:
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions



5
Common Language Runtime (CLR) Managed Code: Provides a richer set of OS Services
than is available to the Win32 OS itself. (Additional information on Microsoft’s CLR can
be found in the Appendix)
–
Memory Management (Automatic Garbage collection of Methods and Objects no
longer in use)
–
Version Management (DLLs, EXEs)
–
Object Oriented Programming (OOPs) support across languages (same feature sets
across multiple languages)
–
Hierarchical Namespace organization
–
Code Security (built in granular security controls)
–
Interoperability with COM (uses a Runtime Callable Wrapper (RCW) to run a COM
object from a .NET Client and a COM Callable Wrapper (CCW) to run a .NET
object from a COM Client.)
–
ASP.NET (.NET version of Active Server Pages): It includes a tool (.NET Web
Forms), which is an easy to use UI for ASP.
Visual Studio.NET: (Microsoft Visual Studio: Microsoft Visual Studio .NET - Next
Generation)
–
Visual Basic
–
C++
–
C#
–
Other Languages see:
http://msdn.microsoft.com/vstudio/partners/languages/default.asp
.NET Windows Forms: (Introducing Windows Forms) A new forms package that provides an
interface UI design environment for the features of the .NET Framework.
In addition, there are other standard technologies used by .NET (Reference: Welcome to the
MSDN Library):

ADO.NET - ActiveX Data Objects, Microsoft's high-level interface for data objects.

XML - Extensible Markup Language, a specification developed by the W3C. XML is a
pared-down version of SGML, designed especially for Web documents.

HTTP - HyperText Transfer Protocol, the underlying protocol used by the World Wide
Web.

SMTP - Simple Mail Transfer Protocol, a protocol for sending e-mail messages between
servers.

TCP/IP - Transmission Control Protocol over Internet Protocol. TCP is one of the main
protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables
two hosts to establish a connection and exchange streams of data.

SOAP – Simple Object Access Protocol (SOAP) is a lightweight protocol for exchange of
information in a decentralized, distributed environment. SOAP relies on the use of a transport
protocol, and while it is not tied to a particular transport protocol, currently HTTP is the
only one that has been defined by the W3C.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
6

UDDI - Universal Description, Discovery and Integration creates a platform-independent,
open framework for describing services, discovering businesses, and integrating business
services.

WSDL – Web Services Description Language is an XML format for describing network
services as a set of endpoints operating on messages containing either document-oriented or
procedure-oriented information. The operations and messages are described abstractly, and
then bound to a concrete network protocol and message format to define an endpoint. Related
concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to
allow description of endpoints and their messages regardless of what message formats or
network protocols are used to communicate. Visual Studio.NET has the ability to autogenerate proxies of Web services based on WSDL. This feature automatically allows
developers to have an SDK to work with at the object level without having to do string
manipulation to build SOAP Requests.
Note: Additional information can be found in the Glossary in APPENDIX E - Glossary.
Deployment of XML Web Services
While a Microsoft XML Web Service (Web Service) can be defined as any URL-addressable
resource that provides Web-exposed business functionality, there are standards and technologies
that have been developed to facilitate the implementation of Web Services.
Creating and Publishing a Web Service
By publishing a Web Service, an application can be created that exposes functionality to clients
via the Web. Creating a Web Service is similar to creating any component that provides
programmatic access to its application logic.
To create a Web Service, you need:

Functionality that constitutes the service you wish to expose

A service description that defines how to use the service

A messaging infrastructure to support request processing and response dispatch
Publishing a Web Service is the process of creating application code that handles requests and
responses as method calls. These method calls take parameters and return values. There are three
basic steps involved in Web service creation and publishing:

Create your Web Service

Test the Web Service using remote debugging

Publish your Web Service to the server from which it will be accessible and verify that it is
accessible from a client. Publishing a Web service involves:
–
Deploying your solution to the Web server on which it will reside
–
Creating the necessary discovery mechanisms so that users can find out about your
service and make use of it.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
7
Web Services are made available to users via a discovery mechanism that usually takes the form
of a dynamic discovery document. The discovery document contains a reference to the WSDL
(Web Service Description Language) description location. End users browse the root of the Web
server to locate discovery documents, and from these files, they determine what services are
available to them. This discovery document is deployed with the project and placed in the
directory in which the solution is installed on the server. For example, suppose you have a Web
application project created in Microsoft VisualStudio.NET named StockServicesSolution
that contains a Web service named StockServices. By default, the solution contains a
discovery file called StockServices.disco. When you deploy this solution to the server,
the following structure is created:
\inetpub
\wwwroot
\StockServices
StockServices.disco
StockServices.asmx
Other files for your Web Service
End users can access this discovery file by accessing its URL. In this case, the URL would be
http://webserver/StockServices/StockServices.disco.
The .NET Framework provides the infrastructure on which to develop Web Services. This
infrastructure includes built in SOAP support, a Web Services Description Language (WSDL)
Tool, a Web Services Discovery Tool, XML Schema Definition Tool, Code Access and Role
Based Security, and built in Web Service support to handle XML, POST, GET and SOAP.
Consuming a .NET Web Service
To access a Web Service, you need:

To locate a Web Service that provides needed business functionality

To locate the service description that defines how to use the service

To use a messaging infrastructure to support request processing, and response dispatch
The location of a Web Service, as well as the service description, is accomplished using UDDI
(Universal Description, Discovery, and Integration). The goal is to create and operate a global
registry for business-to-business commerce over the Internet. The service description is composed
of WSDL (Web Services Description Language). WSDL is an XML-based language used to
describe programs accessible via the Internet (or other networks), and the message formats and
protocols used to communicate with them. WSDL is important because it enables Web Services
to describe their capabilities in a standard way, enabling easier interoperability among Web
Services and development tools.
A Web Service can be consumed via three different methods: HTTP POST, HTTP GET, or
SOAP. SOAP (Simple Object Access Protocol) is an Internet-friendly way of using XML to send
messages and access dynamic Web Services across distributed networks.
Typically, Enterprises will deploy two types of Web Services: secure and public. A secure Web
Service is one published for use by an enterprise’s trusted trading partner or customer. A public
Web Service is published and available for everyone to consume with few privacy or security
requirements.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
8
Private Web Services
Enterprises will have the need to publish Web Services that are going to be consumed by trading
partners or customers. Since these types of Web Services will be consumed by these
organizations to conduct business, they will become mission critical to all parties involved. With
mission-critical requirements for the Web Services, availability and scalability become critical
attributes of the components within the architecture. Figure 1 shows a typical scenario for hosting
the Web services.
Figure 1: Private Web Service consumed by a trusted trading partner.
In this scenario, the Web Service is published and consumed by the trading partners on the DMZ.
An example of this transaction would be the need for the trading partner to submit SAP orders
into the organization. The port used to access the Web Service is determined by an agreement
between both parties involved – the trading partner and the enterprise. The requests come in the
form of XML documents from the trading partner. The first step is a farm of Web/application
servers running Microsoft BizTalk Server 2000. Using a farm of servers, rather than a single
server, is done for availability and scalability. In this scenario, BizTalk Server 2000 serves
multiple purposes – XML document validation and authentication, aggregation of various XML
schemas to one common scheme, and guaranteed message delivery. Next is the use of the
published Web Service. In this scenario, the Web Service is used to publish data consumed from
another Web Service or as an adapter for a back-end ERP system. Using the Web Service as an
adapter eliminates the need for highly customized software and communications components.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
9
Another use of a Web Service in this scenario is to have an application in the DMZ consume data
from a Web Service located in the corporate network. This type of transaction uses Simple Object
Access Protocol (SOAP), eliminating the need to have multiple ports open on the back-end
firewall. In all instances, the Web Services are hosted on farms of Web servers using load
balancing to provide scalability and availability.
Public .NET Web Services
In addition to secure Web Services, enterprises may have occasion to publish data that is to be
consumed by everyone. This type of Web Service does not require authorization, authentication
or privacy. Examples of these types of Web Services would be ones that provide the company’s
stock price or a current listing of products. Figure 2 shows this type of deployment.
Figure 2: Public Web Service consumed by anonymous users.
In this scenario, an anonymous user consumes data published from a Web Service within the
company’s DMZ. Since the company wishes to make this available for everyone, the request uses
port 80. In this example, the Web Service is used to publish the latest product listings from the
company’s back-end ERP system or to publish data that is consumed from an internal Web
Service. In all instances, the Web Services are hosted on farms of Web servers using load
balancing to provide scalability and availability.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
10
Performance Considerations
As with most applications, performance should be addressed. When considering performance,
two attributes should be looked at – the Web Service itself and the platform for the Web Service.
Web Services have the ability to consume and publish data. With this in mind, it is easy to see
that Web Services that are not planned correctly will run into performance issues. For example,
consider a Web Service that consumes from another Web Service. The performance of the Web
Service that is consuming is dependent on the performance of the Web Service it consumes from.
Further, without knowing the design of the Web Service that you are consuming from, you can
get into a situation where you consume from a Web Service that consumes from a Web Service,
which consumes from yet another Web Service, and so on. This type of daisy chaining may lead
to performance problems. Further, this type of implementation leads to availability issues should
one of the Web Services in the chain fail.
The platform for hosting the Web Service should also be addressed when considering the
system’s performance. For this reason, Compaq recommends a Scale Out approach when scaling
the Web/Application Server resources. Scaling out is often the better approach when applications
can support session state management and/or when load balancing provides a more cost-effective
solution and/or when Internet services can be distributed across multiple servers.
Advantages to scaling out are:

Scalable and highly available services can be deployed, allowing capacity improvements
without interruptions.

Servers can be maintained and supported much more easily since services are not required to
go down to add or remove a server for repair or replacement.

There are linear and predictable costs associated with scaling out an application across
multiple servers.
Disadvantages to scaling out:

Depending on the application, the cost per server and the cost of hardware load balancing
may be higher than an implementation on one server.

Software licenses may be higher when licenses are sold on a per-server basis.

Management may increase for each server added to the array if appropriate best practices are
not defined for the environment.
For a complete discussion on Scaling Up and Scaling Out, see the Compaq white paper titled
“Scaling Up and Scaling Out with Compaq ProLiant Servers and Microsoft Windows” found at:
http://www.compaq.com/activeanswers.
Security Considerations
As stated earlier, privacy and security become most important when publishing a Web Service for
doing business with a trading partner or customer.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
11
Security Technologies
HTTP offers support for many security technologies. There are three areas of security in ecommerce transactions: authentication, authorization, and privacy. Authentication verifies the
identity of the requestor of services. Authorization verifies that the given identity has access to
the requested services. Privacy guarantees that the message cannot be read, copied, or
manipulated in transit.
Authentication
Authentication can be done with the HTTP protocol and, in the future, in the SOAP message (if a
legal extension to the SOAP protocol were made). The IBM Research Center in Tokyo has
submitted a Note to the W3C to propose a legal SOAP extension that is nearly equivalent to the
SSL client-certificate approach. The extension uses the SOAP Header to transmit authentication
information and to guarantee data-integrity at the same time. While this Note has been submitted
to the W3C suggesting an extension to the SOAP protocol, until it is accepted or approved the
only viable option is to let authentication be handled by the HTTP protocol. The table below lists
the authentication options within HTTP when using Microsoft IIS as the Web server.
Basic
Use for non-secure or semi-secure identification of
clients, as username and password are sent in plain text.
IIS will authorize access to the Web Service if the
credentials match a valid user account.
Basic over SSL
Same as Basic authentication except that username and
password are sent over the network with SSL encryption
rather than in plain text. A good option for Internet
scenarios; however, using SSL has a significant impact
on performance.
Digest
Uses hashing to transmit client credentials in a secure
way. However, not widely supported on non-Windows
platforms. IIS will authorize access to the Web Service if
the credentials match a valid user account.
Integrated
Windows
authentication
Useful only for intranet scenarios. Uses NTLM or
Kerberos. It can’t be used across proxy servers or other
firewalls. IIS (or other security application) will authorize
access to the Web Service if the credentials match a valid
user account.
Client
certificates
Requires each client to obtain a certificate. Certificates
are mapped to user accounts, which are used by IIS (or
other security application) for authorizing access to the
Web Service. A viable option for Internet scenarios,
although use of digital certificates is not widespread at
this time.
The Basic, Basic over SSL, Digest, and Integrated Windows authentication (NTLM) methods all
rely on passwords to authenticate a user. However, Basic authentication sends passwords over
the network in clear text. In certain circumstances, Basic over SSL will also send passwords over
the network in clear text. Basic over SSL can be made relatively secure with additional
modifications that allow the password to be encrypted.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
12
If a password-based scheme is not sufficient to authenticate the user, the Secure Sockets Layer
(SSL) architecture allows verifying the identity of users through client certificates. The protocol
known as HTTPS is really HTTP over SSL. These client certificates are a result of Public Key
Infrastructure (PKI) technology. PKI forms the technology that issues, manages and validates
digital certificates. A digital certificate issued by a certificate authority (CA) binds a public key to
a specific user and details the operations it can be used for, as well as its validity duration. It also
identifies the CA that issued it with the issuer's signature. This public key can be used in concert
with its associated private key to authenticate the user and perform cryptographic operations. A
digital certificate can be assigned to a server or to an individual.
Privacy
As with authentication, there are two ways to go about it: by HTTP protocol or by SOAP
extension. The IBM proposal mentioned above also covers the extension variant for privacy;
however, as this extension has not been approved, only the HTTP protocol options will be
considered in this document.
For HTTP, the choice is obviously HTTP over SSL (HTTPS). HTTPS is a secure protocol that
will encrypt all traffic between client and server. With the recent changes in U.S. legislation, 128bit wide, strong encryptions keys are now available almost anywhere, and SSL is the most widely
deployed privacy infrastructure for e-commerce. Because HTTP's integration with SSL is
transparent for the implementation of HTTP services (although it comes with some cost in
performance and scalability), it can readily be used with any SOAP implementation that sits on
top of an HTTPS-aware infrastructure.
Authorization
Privacy and authentication can be achieved by using either HTTPS with a password-based
scheme or HTTPS with digital certificates. However, possibly the most difficult aspect of security
can be authorization. The use of digital certificates for authorization is extremely inflexible. Each
certificate is issued with V3 attributes that cannot be altered. If a user’s access level changes, a
new certificate must be issued. Either before or after a user is authenticated, you must decide if
the identity presented is authorized to have access to the requested system, data, or functionality.
The trust policy must be managed and enforced at the application level. The application level
contains the code that accesses and processes all sensitive data such as purchase orders, prices,
revenues, customers, employees, salaries and so on. This is further emphasized because of the
need for outside B2B users to be given access to a specific application or Web Service.
Applications, which typically have unrestricted access to pass traffic through a firewall as needed,
are expected to check these users against their own access control list.
Security Strategy
While the SOAP specification does seemingly ignore all security issues, the infrastructure to
deploy SOAP on HTTPS in a secure way exists now. By using all features of SSL (including
client-side certificates), authentication, integrity and privacy can be guaranteed for all traffic. For
password-based authentication, RFC2617 can replace client-certificates and still be used with
SSL encryption.
In addition, the SOAP extensibility mechanism allows for the extension of the protocol for the
purpose of introducing message integrity, privacy and even authentication within the message
itself in a way that is compliant with the specification but, most importantly, optional.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
13
Access to secure Web Services published and shared with trading partners should be severely
restricted as these Web Services provide direct access to business logic functionality and data.
Some items to consider for restricting this access are:

The inside firewall protecting the Corporate Network should not allow any traffic over port
80.

The inside firewall protecting the Corporate Network should allow HTTPS traffic on a port
not known to the outside world.

The inside firewall protecting the Corporate Network should restrict HTTPS traffic on a
point-to-point basis. (For example, a known/trusted IP address to another known/trusted IP
address)

The Web Services should run under a specific local user account thus restricting access to the
COM components or managed classes to that user account. This account will have limited
privileges (no write access, or local admin, etc.)

Digital Certificates are the most secure solution. If certificates cannot be supported, an SSL
encrypted password-based authentication scheme should be used.

Authorization should be handled by mapping the user name and password to a local account
on the Web server.

For custom-developed Web Services, each Web Service should satisfy only one particular
XML function.

All Web Services should validate the incoming message (SOAP Request) against the schema
before processing the request.

All machines hosting Web Services that use SSL traffic should be equipped with an SSL
acceleration controller(s) or other means of accelerating SSL processing. This provides a true
performance increase while using SSL.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
14
Discoverable Web Service (UDDI)
For Web Services to be utilized, they need to be discoverable to businesses on the Internet.
Therefore, UDDI is considered an important part of the Web Services protocol stack, and thus an
important aspect of the Microsoft XML Web Services offering.
What is UDDI?
UDDI, which stands for Universal Description, Discovery, and Integration, is a global registry
managed by Microsoft, IBM, and Hewlett Packard that allows any business to discover and be
discovered by other businesses from anywhere around the world so that they may conduct
economic transactions more efficiently. Think of UDDI as the “yellow pages” for the Internet. In
addition, UDDI not only allows for the discovery of trading partners but also describes services,
whether they are Web Services or manual services.
UDDI is more than a search engine for businesses and the services they provide. Discovering
potential partners is only part of the solution. More importantly, a means of communication
among your many varying partners must be inherently defined in a dynamic way regardless of the
platform or application they are using to conduct business. In an ideal environment, an internal
business application, which will be UDDI aware, will go out on the Web, search the UDDI
registry, identify and download technical specifications to allow seamless integration between the
internal application and the discovered external one, and conduct automated transactions with
little to no human intervention.
For example, suppose a company wanted to order auto parts electronically via the Web. An
individual at that company would access an internal service to search the UDDI global registry, a
Web Service in itself, for all suppliers of auto parts. Once the service has “discovered” all
potential suppliers, the next objective is to identify which suppliers provide an online order entry
Web Service. Finally, once multiple trading partners are identified that expose this service, it
must be determined if the internal business application (electronic invoicing Web service) is
compatible / interoperable with those discovered.
Work is currently underway to provide enterprises with a private implementation of UDDI
Business Registries (UBR). This UDDI implementation would help a large organization register
and manage its internal Web Services, an example being Enterprise Application Integration. In
this implementation, the entries are for Web Services provided by departments or groups within
an organization. This type of UDDI implementation is completely hidden from external users
behind an enterprise’s firewall. Publish-and-find operations are completely restricted to
applications within the enterprise.
Why use UDDI?
In developing a Web Service, UDDI should be used primarily to stay competitive with other
companies using Web Services. Without adopting the UDDI initiative, the organization runs the
risk of overlooking multiple revenue streams from acquiring new trading partners. More
importantly, the business’ existing suppliers / vendors will go else where to conduct business in a
more efficient / automated fashion through UDDI and Web Services. Web Services are the next
logical evolutionary step in the Internet space that allows programmable elements to be called by
other applications (Application-to-Application (A2A) Integration) in a distributed manner.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
15
Without UDDI, businesses that want to conduct transactions with their trading partners (partners
by choice or coerced partnerships) must either build their own proprietary software or leverage
someone else’s technology, which can become very costly. As the numbers of businesses expand
online, so have the numbers of proprietary software for A2A integration. This influx of in-house
software has created a Web of non-standardized forms of communications that has led to a slow
time to market for products and services. With the adoption of UDDI, time to market for services
are reduced, and A2A integrations on independent systems lead to smoother, more efficient
transactions, the way the Internet was meant to be.
What problem does UDDI solve?
No longer do you have to be a fortune 500 company with the financial depth needed to implement
or lease proprietary software in order to conduct B2B e-commerce. UDDI essentially levels the
playing field for companies of all sizes – small, medium, and large – to dynamically discover and
be discovered, as illustrated in Figure 3, which relates to higher profit with little to no additional
cost (marketing). In addition, a standardized specification for doing business will alleviate the
need for many businesses to purchase very expensive proprietary technology.
Figure 3. A UDDI registry node exposes the registry contents using a standard, SOAP-based API.
Registry nodes also replicate the registry data with one another to ensure changes at the one node
are propagated to all nodes. Source: www.xmlmag.com
As more and more businesses transform their business functions into Web Services, it has
become imperative for companies, small and large, to discover, describe, and integrate
incompatible systems and applications to stay competitive in the B2B marketplace.
In essence, UDDI provides three distinctive types of data:
1. White Pages data = name of the organization, contact name, phone number, address, and
other general information
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
16
2. Yellow Pages data = displays multiple categories based on industry-standard taxonomies such
as NAICS (North American Industrial Classification System), geographic location, and the
products and services that they provide.
3. Green Pages data = Displays a company’s key business processes such as the applications
supported by their system, payment methods, shipping requirements, billing requirements,
and types of protocols supported. More importantly, it displays or directs you to technical
specifications necessary for applications to locate and consume Web Services with other
companies or applications.
With these three types of data, any company can register and indicate the services they provide on
the UDDI registry node. Buyers and vendors will search the UDDI registry for trading partners in
hopes of getting a competitive advantage in the market, as illustrated in Figure 4. Company
specifications will be published and accessible by other organizations for system / application
interoperability.
Figure 4: Functionality of UDDI Registration
Management of Web Services
Maintaining a website and Web Services is as important as maintaining a vehicle. For example,
you can change the vehicle's oil regularly, much the same as updating your system to the latest
revision. Similarly, you could choose not to so do and experience costly downtime that could just
as easily have been prevented with a few minutes worth of work at a minimal cost. Verifying that
resources are not being depleted or that a component in the system is beginning to fail could
provide invaluable insight to the availability required by Web Services.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
17
Tools and Services
Compaq and Microsoft provide tools that assist in effectively managing Web Services and
monitoring performance to maintain response time and provide consistent availability while
targeting a lights out operation. Tables 1 and 2 outline many of the various tools and services
available from Compaq and Microsoft. Most of the software-based tools from Compaq are
located in the Compaq SmartStart and Management CDs provided with every new server or can
be downloaded from the Compaq website. Most of the tools listed below from Microsoft can be
found on the Windows Server installation CD, or Product Application CD.
Table 1: Compaq and Microsoft Tools and Services Available
Special
Services
Hardware
Management Tools
System Management
Tools
Application
Management Tools
Compaq
Pre-Failure
Warranty
Compaq SmartStart
Compaq Integration
Server
Microsoft SQL
Manager
Compaq Insight
Manager
Microsoft Internet
Information Services
Manager
Compaq Survey Utility
Compaq System
Partition Utilities
Compaq System
Partition Administration
Compaq Automatic
Recovery Server
Compaq Standby
Recovery Server
Compaq Integrated
Remote Console
Compaq Remote Insight
Lights-Out Edition
Compaq Asynchronous
Management
Compaq SNMP3 Agents
Compaq Network
Management Software
Compaq Insight
Manager XE
Compaq Availability
Agents
Microsoft
Management
Console
Microsoft Application
Center 2000
Microsoft Remote
Access Services (RAS)
Microsoft Dial-Up
Networking
Microsoft Netmon
Microsoft Performance
Monitor
Microsoft Terminal
Server
Table 2: Compaq DISA Architecture Management Components
Component
Hardware
Management Tools
Local Management
Console
Compaq SmartStart
3
System Management Application
Tools
Management Tools
Integration Server
(repository for
Compaq Survey Utility
configurations)
Compaq System
Compaq Insight
Partition
Manager
Administration Utility
Compaq Insight
Compaq Remote
Microsoft SQL Server
Agent
Microsoft IIS Manager
Microsoft Application
Center 2000
SNMP (Simple Network Management Protocol) is a network management protocol that was designed to create a communication
medium between different type networks. The primary functions performed by this protocol are: reading terminal data, setting
terminal data, and trap network events, such as terminal startups or shutdowns.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
Component
18
Hardware
Management Tools
System Management Application
Tools
Management Tools
Insight Lights-Out
Edition
Manager XE
Three (3) Analog
(POTS) lines for dialup access
Compaq SNMP
agents
Remote Management
Console
Microsoft
Performance Monitor
Microsoft Remote
Access Services
(RAS)
Analog (POTS) line
for dial-up access
Compaq Insight
Manager
Compaq SNMP
agents
Compaq Insight
Manager XE
Compaq Availability
Agents
Microsoft Dial-Up
Networking
Firewall
Compaq SmartStart
Compaq Survey Utility
Compaq System
Partition
Administration Utility
Compaq Insight
Manager
Firewall vendor
management tool
Microsoft
Performance Monitor
Compaq Remote
Insight Lights-Out
Edition
Analog (POTS) line
for dial-up access
Load Balancer
Compaq SNMP
agents
Web and Application
Server Layer
Compaq SmartStart
Vendor supplied tools
Compaq Management Microsoft IIS Manager
Agents
Compaq Survey Utility
Microsoft
Microsoft
Management Console
Compaq System
Performance Monitor
Partition
Compaq Availability
Administration Utility
Microsoft Netmon
Agents
Compaq Integrated
Remote Console
Microsoft Application
Center 2000
Compaq Remote
Insight Lights-Out
Edition
Analog (POTS) line
for dial-up access
Compaq SNMP
agents
Database Firewall
Compaq SmartStart
Compaq Survey Utility
Compaq System
168Z-0202A-WWEN
Microsoft
Performance Monitor
Firewall vendor
management tool
Microsoft .NET Web Services Solutions
Component
19
Hardware
Management Tools
System Management Application
Tools
Management Tools
Partition
Administration Utility
Compaq Remote
Insight Lights-Out
Edition
Analog (POTS) line
for dial-up access
Data Resources Layer Compaq SmartStart
Compaq Survey Utility
Compaq System
Partition
Administration Utility
Compaq Management Microsoft SQL Server
Agents
Manager
Microsoft
Performance Monitor
Compaq Availability
Agents
Microsoft Netmon
Compaq Remote
Insight Lights-Out
Edition
Analog (POTS) line
for dial-up access
Compaq SNMP
agents
Network Access
Device
Compaq SNMP
agents
Microsoft Netmon
Network access
device.
Vendor supplied
management tools
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
20
DISA and a Web Services
The Compaq DISA architecture is a natural and complementary architecture with both Web
Services development and the .NET Framework. DISA’s multi-layer model is directly
complementary with Microsoft’s three-tier .NET development architecture. The Microsoft
architecture recommends a presentation tier, a business logic tier and a data tier. In Compaq’s
architecture for deployment, Compaq recommends an access and acceleration layer (for load
balancing, firewall and caching devices), a Web and application layer, and a data resource layer.
These two architectures provide synergies for design, development and deployment of distributed
applications.
The DISA Architecture
The Compaq Distributed Internet Server Array (DISA) architecture, illustrated
in Figure 5, is a blueprint and set of recommended best practices for
deploying highly available and highly scalable e-commerce/Internet
applications.
Clients
Internet
Access &
Acceleration
Resources
Load
Balance
r
Web &
Application
Resources
Web
Servers
&
Application
Servers
Data
Resources
Data
Servers
Figure 5: DISA Architecture
168Z-0202A-WWEN
Microsoft Windows NT
Load Balancing Service
(WLBS)
Access
Clients
Microsoft .NET Web Services Solutions
21
DISA Key Principles
Use multiple application servers rather than a single server. When combined with intelligent
load-balancing technology, multiple application servers are more scalable and available than a
single server with additional processors and memory. In cases where availability is critical,
Compaq recommends a minimum of three servers, allowing for a single server to be serviced
offline while keeping a redundant pair of servers online at all times. Application servers may have
one or more processors, depending on the characteristics of the particular application. By using
appropriate load-balancing technology, it may be possible to combine servers with different
processing power and I/O characteristics into a single application server array.
When applicable, data resources, such as static content and application code, can be
centralized on amply-configured, highly-available data resources layer servers rather than
replicating them on the application servers in the Web and applications resources layer. If
appropriate fail-over techniques are applied, centralized data resource servers can simplify the
task of managing rapidly changing application resources. Centralizing application resources also
simplifies capacity expansion and failure recovery. To minimize downtime and ensure good
performance, data resource servers should be amply configured with multiple processors,
sufficient RAM, and redundant components (NICs, power supplies, and fans). Clustering
technologies significantly improve the availability of centralized resources. Again, it should be
noted that based on business requirements and application support, centralization may not always
be appropriate.
Use redundancy at potential single points of failure. Fail-over configurations are advisable for
load balancers, firewalls, and networking devices. Intelligent load-balancing technology provides
fail over for redundant application servers. Clustering databases and network storage ensures
uptime for data resources. Redundant NICs, power supplies, and fans are advisable to enhance
uptime on data resource servers. Redundant network connectivity through multi-homing and an
uninterruptible power supply (UPS) are also advisable. The right degree of redundancy depends
on the underlying business requirement and the available budget.
Build applications to ensure that user state information is not maintained on a single
application server. Applications that maintain user state on a single-application server may not
function with certain load balancing algorithms. Some load-balancing products avoid such
problems by managing load on an individual user basis to ensure that each user stays with the
same application server throughout the session.
It is recommended that data resources servers are scaled up and Web/application servers
are scaled out. This recommendation is based on testing that indicates Web/e-commerce
applications can handle increased load best when scaled out while database-centered applications
scale up adequately for most of today’s deployments. Compaq recommends proof-of-concept
testing in a non-production environment using the actual target application as a matter of best
practice for all application deployments. Testing the actual target application in a production
environment is the most effective way to estimate system behavior. For a detailed discussion on
scaling Compaq ProLiant servers, see the white paper titled: Scaling Up and Scaling Out with
Compaq ProLiant Servers and Microsoft Windows found at
http://activeanswers.compaq.com/ActiveAnswers/Render/1,1027,4808-6-100-225-1,00.htm
Additional information about DISA can be found at:
http://activeanswers.compaq.com/ActiveAnswers/Render/1,1027,1573-6-100-225-1,00.htm.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
22
Conclusion
This document has identified the technologies associated with Microsoft XML Web Services and
discusses best practices for developing, deploying, consuming, securing, and managing a Web
Service from a Microsoft .NET platform.
This document provided information on how to develop, deploy, consume, secure, and manage a
Web Service.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
23
APPENDIX A - Microsoft’s CLR
The most important component of the .NET Framework is the Common Language Runtime
(CLR). Its functions include:

manages and executes code written in .NET languages

forms the basis of the .NET architecture

activates objects

performs security checks on objects

lays objects out in memory

executes objects

garbage collects objects
The CLR environment includes the following concepts:

the CLR

executables

metadata

assemblies

manifests

the CTS (Common Type System)

the CLS (Common Language Specification)
.NET PE File
.NET PE File
.NET PE File
Common Runtime Language
Figure A-1. The CLR environment.
Figure A-1 shows the two portions of the .NET environment, with the bottom portion
representing the CLR and the top portion representing the CLR executable or Portable Executable
(PE) files which are .NET assemblies or basic units of deployable code. The CLR is the runtime
engine that loads required classes, performs just-in-time compilation on needed methods,
enforces security checks, and accomplishes a number of other runtime functionalities. Microsoft
.NET executables are different from typical Windows executables in that they carry not only code
and data, but also metadata.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
24
Metadata is machine-readable information about a resource, or "data about data." In .NET,
metadata is a common mechanism or dialect that the runtime, compilers, and tools can all use.
Microsoft .NET uses metadata to describe all types of machine-readable information that are used
and exposed by a particular .NET assembly. In this sense, metadata describes an assembly in
detail, including descriptions of its identity (a combination of an assembly name, version, culture,
and public key), the types of data that it references, the types of data that it exports, and the
security requirements for execution. Metadata provides enough information for any runtime, tool,
or program to find out literally anything that is needed for component integration. Stated another
way, any application, tool or utility that can read metadata from an assembly can make use of that
assembly.
Metadata provides language interoperability, an essential element to .NET, since all languages
must use the same types of data in order to generate a valid .NET PE file. The .NET runtime
cannot support such features as memory management, security management, memory layout, type
checking, debugging, and so on without the richness of metadata. It can safely be said that there
would be no .NET without metadata.
The different types of runtime, tool, component or utility must expose their metadata to allow
tools and programs to access them and benefit from their services. Metadata for these items is not
enough. To simplify software plug-and -play and configuration or installation of the component
or software, we also need metadata about the component that hosts these types of data. This leads
to a discussion about .NET assemblies (deployable units) and manifests (the metadata that
describes the assemblies).
An assembly is a logical collection of one or more EXE or DLL files containing an application’s
code and resources. An assembly also contains a manifest, which is a metadata description of the
code and resources “inside” the assembly. An assembly can be a single file, either EXE or DLL.
Although an assembly often resides in a single file, it can be a logical, non-physical collection of
more than one file residing in the same directory. The manifest specifying the files can reside in
one of the code-containing EXE or DLL files of the assembly, or it can reside in a separate EXE
or DLL file that contains nothing but the manifest.
Assemblies can be public or private, depending on whether they will be used by one application
or several. The .NET framework allows assemblies to be shared by placing them in the global
assembly cache (GAC), which is the \\winnt\assembly directory. Shared assemblies use public
key cryptography to ensure that their names are unique (strong names). The public/private key
algorithm also provides a check on the integrity of the assembly’s files. The .NET Framework
incorporates functionality for versioning using the assembly’s metadata.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
25
APPENDIX B - Example
Overview of a B2B Web Service Demonstration
This demonstration takes Microsoft’s “Learn BizTalk” procurement scenario, which ships with
BizTalk Server 2000, and adds one buyer-side and two supplier-side Web Services. The main
objective of the demonstration was to create a working business scenario using BizTalk Server
2000 and Web Services to automate the process. The demonstration illustrates how a business can
query multiple suppliers for pricing, pass the quote through predefined business logic, and
complete the purchase automatically using Microsoft .NET technologies.
In this demonstration, BizTalk Server 2000 and Visual Studio .NET are used to create a fully
functional procurement process, including multiple supplier quotes. The physical implementation
of this demonstration is illustrated in Figure B-1. Web Services handle the initial communication
and logic before the process enters BizTalk, as illustrated in Figure B-2, which uses XLANG for
the logic. SOAP and XML are the standard data formats for the documents and data transfer is
handled via HTTP Posts. Both ASP and ASP.NET are used to place the posts into the business
message queues (MSMQ).
The Learn BizTalk demo provides an excellent overview of the functionality of BizTalk server.
This demonstration added logic in the XLANG schedules, to handle multiple suppliers, and
added/modified the ports and channels. The Web Services were added to complete the process
and create an actual Microsoft XML Web Service implementation.
Figure B-1: Physical Implementation of Demonstration
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
Figure B-2: Flow of logic and communication in the demonstration
Figure B-3 illustrates the processing of the transactions in the demonstration and the transaction
steps are described in the numbered steps that follow Figure B-3.
168Z-0202A-WWEN
26
Microsoft .NET Web Services Solutions
27
Figure B-3: Flow of transactions in the demonstration
1. A user from the Buyer company accesses an internal Active Server Page (ASP), then
completes and submits a Purchase Request.
2. The ASP performs an HTTP Post to an internal Web Service. This Purchase Request is sent
using a SOAP envelope via HTTP.
3. The Buyer’s Web Service receives the Purchase Request, process it and sends out a Quote
Request using a SOAP envelope via HTTP to the Web Service of each of the two suppliers,
Supplier 1 and Supplier 2.
4. Each supplier’s Web Service processes the Quote Request and sends a “Quote Response,”
again with a SOAP envelope via HTTP to the Buyer’s Web Service.
5. Once the Buyer’s Web Service receives all quotes, the Buyer’s Web Service processes the
quotes and determines which supplier is quoting the lowest cost for the product(s) that the
buyer wants to purchase. The Web Service then creates an XML-based Purchase Order (PO)
Request that includes product, quantity, which supplier to purchase from, and other pertinent
information and places it into an MSMQ Queue.
6. The Buyer’s BizTalk Server “Receive Function” pulls the XML-based PO Request into
BizTalk for processing. BizTalk passes the PO Request to an XLANG schedule for the
business logic to Approve or Disapprove the request and provide BizTalk the answer. If the
PO Request is Disapproved, BizTalk sends an e-mail to the individual responsible for the
request indicating that the PO Request has been Disapproved. If the PO Request is Approved,
BizTalk sends a SOAP envelope “Purchase Order” via HTTP to the supplier determined by
the Web Service. Supplier receives the Purchase Order via an Active Server Page and the
ASP places the PO into an MSMQ Queue.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
28
7. The supplier’s Web Service sends an “Acknowledgement” to the Buyer’s BizTalk Server and
causes the order to be shipped.
8. The supplier’s BizTalk Server pulls the Purchase Order from the MSMQ Queue for
processing. After processing, the supplier’s Web Service posts an “Invoice” to the Buyer’s
Receive ASP. Again, the Posting of the ASP uses a SOAP envelope and HTTP as the
transport.
9. The Buyer’s Web Service processes the Invoice, sends it to Finance, which then sends a
“Payment” to the supplier.
These steps are illustrated, in terms of logical process flow, in Figure B-4.
Logical Process Flow
User Input
Requested Data
User
Interface
Biztalk Server
Receive PO
Request Pass to
XLANG
Schedule
MSMQ
MessagePO
Request
End
Internal Web Site
Accept User
Input - HTTP Post
to Internal Web
Service
Invoice
from
Supplier
Biztalk Server
Internal Web Service
Approve/
Disapprove
Request
Create XML PO
Request from
Best Quote Send to MSMQ
Decline
.ASP Page
End
Biztalk Server
SOAP Requested
Data
Internal Web Service
Process
Requested Data
Send out for
Quotes - HTTP
Post to Supplier
Web Service
Biztalk Server
Determine
Best Quote
Supplier Biztalk Server
Internal Web Service
Process PO
through Biztalk
Server - HTTP
Post Invoice to
Northwind's .asp
page
XML - PO
to Supplier
Supplier Web Service
Produce Quotes
and Return Them
- HTTP Response
to Northwind
Internal Web
Service
XML Invoice
Send PO to
Company - HTTP
Post to .asp page
Gather Quotes
from Both
Suppliers
SOAP Requested
Part and
Quantity
.ASP Page
SOAP Quote
Information
Receive .asp
sends Request to
MSMQ
Figure B-4: Logical Process Flow of transaction in demonstration.
168Z-0202A-WWEN
Write File to
Invoice Directory
Determine
Company to Send
PO
MSMQ
Message PO
Microsoft .NET Web Services Solutions
29
Sample Web Service Processing Flow
Figure B-5 illustrates a simple example of the demonstration layout that can be used to
demonstrate Web Service processing flow.
Figure B-5: Basic Demonstration Layout illustrating Web Service Process Flow
The steps in this demonstration Web Service processing are as follows:
10. The client application HTTP posts a SOAP Request call to the sample Web Service
containing the desired transaction name and the required parameters. The client application
waits for the service response.
11. The sample Web Service initiates a connection to the database and queries the hardware unit
price table for the desired hardware price quote.
12. The sample Web Service receives a response from database
13. The sample Web Service processes the database response and returns the SOAP response to
the client application via the synchronous HTTP connection.
These steps are shown graphically in Figure B-6.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
30
Sample Web Service Processing Diagram
Receiving Product Name
from Client Application
Find the Unit Price from the
Compaq Hardware Price
Database
Product Name match
database Record?
Yes
No
Return Hardware Unit Price
to the Client Application
Return Not Found Event
End
Figure B-6: Web Service Processing Flow in Example
Sample Web Service Processing Input Interface
Request Format
Parameters
Parameter Type
SOAP via HTTP POST
Computer Production Name
String
Sample Web Service Processing Output Interface
Response Format
Parameters
Parameter Type
SOAP via HTTP
Response
Computer Hardware Unit Price
Float (Single)
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
Files and Code Samples of Sample Process Flow
Sample Web Service WSDL file
<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:s0="http://tempuri.org/"
targetNamespace="http://tempuri.org/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http://tempuri.org/">
<s:element name="QuoteUnitPrice">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="ProductName"
nillable="true" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="QuoteUnitPriceResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="QuoteUnitPriceResult"
type="s:float" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="float" type="s:float" />
</s:schema>
</types>
<message name="QuoteUnitPriceSoapIn">
<part name="parameters" element="s0:QuoteUnitPrice" />
</message>
<message name="QuoteUnitPriceSoapOut">
<part name="parameters" element="s0:QuoteUnitPriceResponse" />
</message>
<message name="QuoteUnitPriceHttpGetIn">
<part name="ProductName" type="s:string" />
</message>
<message name="QuoteUnitPriceHttpGetOut">
<part name="Body" element="s0:float" />
</message>
<message name="QuoteUnitPriceHttpPostIn">
<part name="ProductName" type="s:string" />
</message>
<message name="QuoteUnitPriceHttpPostOut">
<part name="Body" element="s0:float" />
</message>
<portType name="cpqQuoteSoap">
<operation name="QuoteUnitPrice">
<input message="s0:QuoteUnitPriceSoapIn" />
<output message="s0:QuoteUnitPriceSoapOut" />
</operation>
</portType>
168Z-0202A-WWEN
31
Microsoft .NET Web Services Solutions
<portType name="cpqQuoteHttpGet">
<operation name="QuoteUnitPrice">
<input message="s0:QuoteUnitPriceHttpGetIn" />
<output message="s0:QuoteUnitPriceHttpGetOut" />
</operation>
</portType>
<portType name="cpqQuoteHttpPost">
<operation name="QuoteUnitPrice">
<input message="s0:QuoteUnitPriceHttpPostIn" />
<output message="s0:QuoteUnitPriceHttpPostOut" />
</operation>
</portType>
<binding name="cpqQuoteSoap" type="s0:cpqQuoteSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document" />
<operation name="QuoteUnitPrice">
<soap:operation soapAction="http://tempuri.org/QuoteUnitPrice"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>
<binding name="cpqQuoteHttpGet" type="s0:cpqQuoteHttpGet">
<http:binding verb="GET" />
<operation name="QuoteUnitPrice">
<http:operation location="/QuoteUnitPrice" />
<input>
<http:urlEncoded />
</input>
<output>
<mime:mimeXml part="Body" />
</output>
</operation>
</binding>
<binding name="cpqQuoteHttpPost" type="s0:cpqQuoteHttpPost">
<http:binding verb="POST" />
<operation name="QuoteUnitPrice">
<http:operation location="/QuoteUnitPrice" />
<input>
<mime:content type="application/x-www-form-urlencoded" />
</input>
<output>
<mime:mimeXml part="Body" />
</output>
</operation>
</binding>
<service name="cpqQuote">
<port name="cpqQuoteSoap" binding="s0:cpqQuoteSoap">
<soap:address location="http://localhost/BogusCompaq/cpqQuote.asmx" />
</port>
<port name="cpqQuoteHttpGet" binding="s0:cpqQuoteHttpGet">
<http:address location="http://localhost/BogusCompaq/cpqQuote.asmx" />
</port>
<port name="cpqQuoteHttpPost" binding="s0:cpqQuoteHttpPost">
<http:address location="http://localhost/BogusCompaq/cpqQuote.asmx" />
</port>
</service>
</definitions>
168Z-0202A-WWEN
32
Microsoft .NET Web Services Solutions
33
Sample SOAP Request
POST /BogusCompaq/cpqQuote.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://tempuri.org/QuoteUnitPrice"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/en
velope/">
<soap:Body>
<QuoteUnitPrice xmlns="http://tempuri.org/">
<ProductName>string</ProductName>
</QuoteUnitPrice>
</soap:Body>
</soap:Envelope>
Sample SOAP Response
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/en
velope/">
<soap:Body>
<QuoteUnitPriceResponse xmlns="http://tempuri.org/">
<QuoteUnitPriceResult>float</QuoteUnitPriceResult>
</QuoteUnitPriceResponse>
</soap:Body>
</soap:Envelope>
Sample Web Services Source Code
<WebMethod()> Public Function QuoteUnitPrice(ByVal ProductName As String) As
Single
Return GetPrice(ProductName)
End Function
Private
Dim
Dim
Dim
Dim
Dim
Dim
Function GetPrice(ByVal ProductName As String) As Single
cpqConnection As SqlConnection
cpqCommand As SqlCommand
cpqReader As SqlDataReader
cpqSQL As String
ConnectString As String
cpqResult As Single
cpqResult = -1
ConnectString = "server=localhost;uid=sa;pwd=;database=BogusCompaq"
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
cpqSQL = "SELECT * FROM cpqProduct WHERE (cpqProductName='" +
ProductName + "')"
cpqConnection = New SqlConnection(ConnectString)
cpqConnection.Open()
cpqCommand = New SqlCommand(cpqSQL, cpqConnection)
cpqReader = cpqCommand.ExecuteReader()
While (cpqReader.Read)
cpqResult = cpqReader("cpqUnitPrice")
End While
Return cpqResult
End Function
168Z-0202A-WWEN
34
Microsoft .NET Web Services Solutions
APPENDIX C - System Software
System Software for Enterprise Deployments
The following subsections provide useful links, arranged by DISA layer.
Web Servers

Microsoft Windows 2000 Server products. See
http://www.microsoft.com/windows2000/server/default.asp and
http://www.compaq.com/ActiveAnswers/ for further information on Windows 2000.

Microsoft Windows 2000 Service Pack 2. Windows 2000 Service Pack 2 is available at
http://www.microsoft.com/windows2000/downloads/servicepacks/sp2/default.asp.

Compaq Support Paq. See http://www.compaq.com/support/ for further information on
Compaq SoftPaq support software. The Compaq Support Paq is a collection of Compaq
SoftPaqs that provides support software for Compaq ProLiant server deployments.

Microsoft SQL Server 2000, Enterprise Edition, Client Utilities only. See
http://www.microsoft.com/sql/default.asp for further information.

Microsoft MDAC (most current version). See http://www.microsoft.com/data/ for further
information.
Application Servers

Microsoft Windows 2000 Advanced Server. See
http://www.microsoft.com/windows2000/server/default.asp and
http://www.compaq.com/ActiveAnswers/ for further information on Windows 2000 Server
and Advanced Server.

Microsoft Windows 2000 Service Pack 2. Windows 2000 Service Pack 2 is available at
http://www.microsoft.com/windows2000/downloads/servicepacks/sp2/default.asp.

Compaq Support Paq. See http://www.compaq.com/support/ for further information on
Compaq SoftPaq support software. The Compaq Support Paq is a collection of Compaq
SoftPaqs that provides support software for Compaq ProLiant server deployments.

Microsoft SQL Server 2000, Enterprise Edition, Client Utilities only. See
http://www.microsoft.com/sql/default.asp for further information.

Microsoft MDAC (most current version). See http://www.microsoft.com/data/ for further
information.

Microsoft Visio 2000, Standard Edition. See http://www.microsoft.com/office/visio/ for
further information.

Microsoft BizTalk Server 2000, Enterprise Edition. See http://www.microsoft.com/biztalk/
and http://www.compaq.com/ActiveAnswers/ for further information.

Microsoft BizTalk Server 2000 Service Pack 1. This is available at
http://www.microsoft.com/biztalk/downloads/updates/2000/SP1.asp.
168Z-0202A-WWEN
35
Microsoft .NET Web Services Solutions
Data Resources Server
MSMQ Cluster

Microsoft Windows 2000 Advanced Server. See
http://www.microsoft.com/windows2000/server/default.asp and
http://www.compaq.com/ActiveAnswers/ for further information on Windows 2000 Server
and Advanced Server.

MSMQ must be installed from the Windows 2000 Advanced Server installation media. See
http://www.microsoft.com/msmq/.

Microsoft Windows 2000 Service Pack 2. Windows 2000 Service Pack 2 is available at
http://www.microsoft.com/windows2000/downloads/servicepacks/sp2/default.asp.

Compaq Support Paq. See http://www.compaq.com/support/ for further information on
Compaq SoftPaq support software. The Compaq Support Paq is a collection of Compaq
SoftPaqs that provides support software for Compaq ProLiant server deployments.
Database Cluster

Microsoft Windows 2000 Advanced Server. See
http://www.microsoft.com/windows2000/server/default.asp and
http://www.compaq.com/ActiveAnswers/ for further information on Windows 2000 Server
and Advanced Server.

Microsoft Windows 2000 Service Pack 2. Windows 2000 Service Pack 2 is available at
http://www.microsoft.com/windows2000/downloads/servicepacks/sp2/default.asp.

Compaq Support Paq. See http://www.compaq.com/support/ for further information on
Compaq SoftPaq support software. The Compaq Support Paq is a collection of Compaq
SoftPaqs that provides support software for Compaq ProLiant server deployments.

Microsoft SQL Server 2000, Enterprise Edition, Database engine. See
http://www.microsoft.com/sql/default.asp for further information.

Microsoft MDAC (most current version). See http://www.microsoft.com/data/ for further
information.
168Z-0202A-WWEN
36
Microsoft .NET Web Services Solutions
37
APPENDIX D – References
The following are recommendations helpful for the person interested in implementing Web
Services. Summaries of articles, where they are provided below, are identified in quotation marks
and are taken directly from the referenced article or website. Authors of articles are included
below only when identified by the publishing website. Connect to each Web page using the
provided links for more information on the sources of this information.
A Platform for Web Services
Mary Kirtland - January 2001
“Summary: This article presents an overview on the Web Services model for building
applications. It includes a discussion on the definition of Web Services; the generic architecture
of a Web Service and how it relates to Microsoft Windows DNA and .NET; platform
requirements; and some of the tools and technologies provided by Microsoft to implement and
deploy Web Services.”
Web Services Essentials
“Summary: This document provides an overview of individual articles on Web Services.”
HOW TO: Use Data in Web Services
“Summary: This article shows how Datasets, an XML-based way to represent disconnected data,
can be returned from a Web service method. By exposing Datasets through a service, you can
limit the database connections that your data server is experiencing.”
HOW TO: Write a Simple Web Service
“Summary: This article describes how to write a simple Web service, called MathService, that
exposes methods for adding, subtracting, dividing, and multiplying two numbers.”
Designing the Contract
By Scott Seely
C#: A Message Queuing Application
By Carl Nolan
“Summary: This article outlines a Windows service solution designed to process several message
queues, focusing on the application of the Microsoft .NET Framework and C#.”
Message Queuing: A Scalable, Highly Available Load-Balancing Solution
By Christopher Baldwin, Carl Nolan
Exposing Existing Code as a Web Service Using the .NET Framework
Building Distributed Applications with .NET
By Steve Kirk and Priya Dhawan
“Summary: This article covers data transformations made to expose existing Microsoft Visual
Basic 6.0 code as a Web Service using ASP.NET. It applies to Beta 2 of the Microsoft .NET SDK
and Microsoft Visual Studio .NET.”
Introducing the UDDI Software Development Kit
December 2000
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
38
“Summary: This paper introduces the Microsoft UDDI SDK for interacting with the UDDI
Business Registry.”
.NET Framework Essentials
“.NET Framework Essentials is a concise and technical overview of the new Microsoft .NET
Framework. Covered here are all of the most important topics: from the underlying Common
Language Run-Time (CLR) to its specialized packages for ASP.NET, Web Forms, Windows
Forms, XML and data access (ADO.NET). The authors survey each of the major .NET
languages, including VB.NET, C# and Managed C++.” [Source: O'Reilly & Associates]
.NET Framework SDK
Building Client Interfaces for .NET Web Services
“Learn how to create clients to consume them and learn about the importance of proxy objects
and how to create a Web browser, Windows console, and Wireless Access Protocol (WAP)
clients using Microsoft Visual Studio .NET.” [Source: internet.com]
Applying .NET to Web Services
“O'Reilly writer Brian Jepson introduces and discusses the .NET Framework in this Web
Techniques article. Microsoft's .NET represents a fresh approach to Web development and
provides a rapid application development (RAD) approach to creating Web services.” [Source:
O'Reilly and Associates]
Monitoring in .NET Distributed Application Design
“Summary: Windows Management Instrumentation (WMI) is the preferred monitoring
technology on the Windows platform. This article provides an intro to WMI and discusses the
monitoring process in the context of .NET applications.”
Accessing Message Queues
“Summary: This article describes how to use System.Messaging classes in the Microsoft .NET
Framework to read and write to MSMQ queues. The information discussed in this article applies
to Beta 2 of the .NET Framework and Microsoft Visual Studio .NET.”
C#: A Message Queuing Service Application
“Summary: This article outlines a Windows service solution designed to process several message
queues, focusing on the application of the Microsoft .NET Framework and C#.”
A Sneak Peek at New Services from Cold Rooster Consulting
ColdStorage Sample Overview
“The ColdStorage sample was created by the MSDN Architectural Samples Team as an
educational tool. The main goal of the sample is to show how a company might develop both a
set of XML Web services to store data as well as a rich-client application that would consume the
Web services.”
ColdStorage Service Design Overview
“Summary: This article describes the application architecture of the XML Web services included
in the ColdStorage sample service.”
ColdStorage Sample Development Overview
“Summary: This article provides an overview of the development of the components included
with the ColdStorage sample, including two Web services and a rich client application.”
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
39
Microsoft XLANG
“Automation of business processes based on Web services requires a notation for the
specification of message exchange behavior among participating Web services. This document
specifies such a notation. We call it XLANG. XLANG is expected to serve as the basis for
automated protocol engines that can track the state of process instances and help enforce protocol
correctness in message flows.”
Web Services Resources
Web Services Primer
“A review of the emerging XML-based Web services platform, examining the core components
of SOAP, WSDL and UDDI.” [XML.com]
MSDN Web Services (http://msdn.microsoft.com/webservices/)
.NET 247 (http://www.dotnet247.com)
WebServices.org
“The vendor-neutral Web services portal - SOAP,UDDI,.NET,ONE,ebXML...”
Web Services Architect (http://www.webservicesarchitect.com/)
WSDL / SOAP Web Services Search Engine:SalCentral (http://www.salcentral.com/)
“The world's largest brokerage for schemas, reviews and quality assurance information on Web
Services. Provides a Web Services search engine.”
XMethods (http://www.xmethods.com/)
Xmethods is a site dedicated to promoting the development, deployment, and use of Web
Services, offers (amongst other things) a directory of Web Services and a discussion forum.
XMethods provides examples of SOAP-based Web services, as well as XML information,
tutorials and tools.
XMLBus.com (http://www.xmlbus.com/)
XMLBus.com is a resource for people who are interested in Web Services and want to learn more
about Web Services technology. XMLBus.com provides online tools to Browse UDDI and to
dynamically test Web Services running on XMLBus.com or elsewhere on the Internet.
developer.* - http://www.developerdotstar.com/index.htm
DevX – http://www.devx.com/ - multi-technology site including items licensed from Fawcette
Publishing
O'Reilly Network .NET DevCenter: http://www.oreillynet.com/dotnet/
O'Reilly Network Web Services DevCenter: http://www.oreillynet.com/webservices/
Web Services Journal (http://www.sys-con.com/webservices/)
.NET Hosting - http://www.brinkster.com/
Flamenco Networks – Web Services Network - http://www.flamenconetworks.com/
IBM Webservices Developer Works (http://www.ibm.com/developer/webservices/)
IBM Web Services Toolkit
IBM Webservices Development Kit
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
40
UDDI
Microsoft UDDI (http://uddi.microsoft.com/)
Microsoft's UDDI directory, with information about UDDI (and registering for UDDI).
Microsoft UDDI Directory (http://uddi.microsoft.com/visualstudio)
Query the UDDI Business Registry to find companies and production Web Services.
Test Microsoft UDDI Directory (http://test.uddi.microsoft.com/visualstudio)
Locate test Web Services to use during development.
Microsoft UDDI SDK (http://www.microsoft.com/downloads/release.asp?ReleaseID=30880)
“The SDK includes both a .NET class library and a Visual Studio 6.0 library that optimize
interaction with UDDI. It also includes the UDDI Developer Edition, a light-weight UDDI
registry built on the .NET Framework. Now developers can build and test solutions that interact
with a UDDI registry hosted locally.”
Microsoft UDDI Technical Overview
(http://uddi.microsoft.com/developer/tech_white_paper.doc)
“Universal Discovery Description and Integration is a specification for distributed Web-based
information registries of Web Services…. This paper describes the capabilities that these
registries add to the World Wide Web.”
Using WSDL in a UDDI Registry 1.05
“The Web Services Description Language (WSDL) is a general purpose XML language for
describing the interface, protocol bindings and the deployment details of network services.
WSDL complements the UDDI standard by providing a uniform way of describing the abstract
interface and protocol bindings of arbitrary network services. The purpose of this document is to
clarify the relationship between the two, describe how WSDL can be used to help create UDDI
business service descriptions.”
SOAP
SOAP 1.1 Specification
World Wide Web Consortium note describing and specifying the SOAP 1.1 protocol.
SOAP and .NET
O'Reilly Java author Jim Farley continues his commentary on all things .NET by looking at
what's cool and not so cool about SOAP.
Microsoft SOAP Toolkit 2.0 SP2
A Busy Developer's Guide to SOAP 1.1 (http://www.soapware.org/bdg)
By Dave Winer, Jake Savin, UserLand Software, 4/2/01.
XML Today - http://www.xmltoday.com/
XSLT / XML / C# (http://www.dotnet247.com/247reference/articles/0/57.aspx)
“In this article the author shows how to apply XSLT to data coming from a database in XML
format.”
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
41
WSDL
WSDL 1.0 (http://www-4.ibm.com/software/developer/library/w-wsdl.html)
Web Services Description Language version 1.0 specification from the IBM DeveloperWorks
site.
WSDL 1.1 (http://www.w3.org/TR/wsdl)
Web Services Description Language
Web Services Description Language (WSDL) Explained
“It has been argued that SOAP does not really need an interface description language to go with
it. If SOAP is a standard for communicating pure content, then it needs a language for describing
that content. SOAP messages do carry type information, and so SOAP allows for dynamic
determination of type. But I cannot call a function correctly unless I know its name and the
number of parameters and the types of each. Without WSDL, I can determine the calling syntax
from documentation that must be provided, or by examining wire messages. Either way, a human
will have to be involved, and so the process is prone to error. With WSDL, I can automate the
generation of proxies for Web services in a truly language- and platform-independent way.”
Web Services Description Language (WSDL) Explained
“Using WSDL, users can automate the generation of proxies for Web services in a truly
language- and platform-independent way.”
Open Source .NET
.NETUnit
.NETUnit is an implementation of Kent Beck and Erich Gamma's XUnit testing framework
(http://www.xprogramming.com/software.htm).
CSUnit
A .NET regression testing framework inspired by JUnit (www.junit.org).
Dot GNU (.GNU)
The DotGNU Project is really a meta-project that will consist of between ten and twenty
subprojects. The main components of DotGNU are the DotGNU Platform and the DotGNU
Virtual Identities system. DotGNU will be a complete replacement for the .NET strategy - it will
not be a Free Software implementation of .NET.
.Net OpenSource
A collection of application building blocks built on top of .NET.
DotNetPCF
A compound file implementation for .NET.
Java.NET
Halcyon Software's Java.NET project lets developers either migrate their ASP or Visual Basic
code to JSP or Java, respectively, or to deploy applications on Java-based infrastructures.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
42
Mono
Ximian's Mono project is an effort to create a free software (sometimes called open source)
implementation of the .NET Development Framework. It will include code and tools that will
enable the .NET Framework (i.e, ASP, ADO, FCL, etc.) to work with Linux and other OS.
NAnt
“NAnt is a .NET based build tool. In theory it is kind of like make without make's wrinkles. In
practice it's a lot like Ant.” (http://jakarta.apache.org/ant/).”
Nareau Project
Nareau developers do not see the need to create an entire new framework, as is being done by
both Mono and DotGNU. Instead, Nareau plans to make use of the many tools and protocols that
already exist. Thus, the project will be built on top of Web services components like: Server
software: Apache, parts of Zope, Jabber, Jakarta Client software: Mozilla, Komodo Protocols:
SOAP, and Kerberos.
NUnit
NUnit is a .NET port of Kent Beck and Erich Gamma's JUnit (www.junit.org). NUnit is a
framework for writing repeatable tests in any .NET language.
OpenSMTP.NET
An SMTP component written in C#.
Perl.NET
“Perl for .NET Research is the result of a research project, creating a native code compiler for
Perl to the Microsoft .NET Framework. The status of this compiler is experimental; it also
supports just a subset of the language.”
Portable.NET
A portable .NET implementation. It will include tools, compilers, and runtime support. For
portability, the runtime will use an interpreter instead of a JIT.
Python.NET
“Python for .NET Research is currently an exploratory implementation of the Python language
for the .NET Framework. The archive includes general documentation on the project itself,
documentation and complete source code.”
Sharp Egg
An IRC bot written in C#.
SharpDevelop
A lightweight IDE for C#, ASP.NET, ADO.NET, XML, and HTML. It includes a class browser
and syntax highlighting.
X Marks the DOT
A collection of XML-related projects written in C#.
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
43
APPENDIX E - Glossary
XML
An initiative from the W3C defining an "extremely simple" dialect of SGML suitable for use on the
World-Wide Web.
http://www.w3.org/TR/REC-xml.html
SGML
Standard Generalized Markup Language (SGML). A generic markup language for representing
documents. SGML is an International Standard that describes the relationship between a
document's content and its structure. SGML allows document-based information to be shared and
re-used across applications and computer platforms in an open, vendor-neutral format. SGML is
sometimes compared to SQL, in that it enables companies to structure information in documents in
an open fashion, so that it can be accessed or re-used by any SGML-aware application across
multiple platforms.
http://www-tei.uic.edu/orgs/tei/sgml/teip3sg/index.html
XSL
XSL is a language for expressing style sheets. An XSL style sheet is, like CSS, a file that describes
how to display an XML document of a given type. XSL shares the functionality of and is compatible
with CSS2 (although it uses a different syntax).
The Extensible Stylesheet Language (XSL)
CSS
“Cascading Style Sheets (CSS) is a simple mechanism for adding style (e.g. fonts, colors, spacing)
to Web documents.”
Cascading Style Sheets
ebXML
Electronic Business Extensible Markup Language (ebXML) is an initiative to provide an XML-based
open technical framework to enable XML to be utilized in a consistent and uniform manner for the
exchange of electronic business (eb) data in application-to-application, application-to-human, and
human-to-application environments — thus creating a single global electronic market.
http://www.ebxml.org/specdrafts/ebXML_TA_v1.0.4.pdf
SOAP - Simple
Object Access
Protocol
Simple Object Access Protocol (SOAP) is a lightweight protocol for exchange of information in a
decentralized, distributed environment. It is an XML based protocol that consists of four parts: an
envelope that defines a framework for describing what is in a message and how to process it, a set
of encoding rules for expressing instances of application-defined data types, a convention for
representing remote procedure calls and responses, and a binding convention for exchanging
messages using an underlying protocol.
DCOM
Short for Distributed Component Object Model, an extension of the Component Object Model
(COM) to support objects distributed across a network.
http://www.microsoft.com/Com/resources/comdocs.asp
HTTP
Short for HyperText Transfer Protocol, the underlying protocol used by the World Wide Web. HTTP
defines how messages are formatted and transmitted, and what actions Web servers and browsers
should take in response to various commands.
UDDI
Universal Description, Discovery and Integration (UDDI) creates a platform-independent, open
framework for describing services, discovering businesses, and integrating business services using
the Internet, as well as an operational registry that is available today.
www.uddi.org
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnuddi/html/progguide.asp
Internet
Inter-ORB
Protocol (IIOP)
Internet Inter-ORB Protocol, a protocol developed by the Object Management Groupto implement
CORBA solutions over the World Wide Web. IIOP enables browsers and servers to exchange
integers, arrays, and more complex objects, unlike HTTP, which only supports transmission of text.
RPC
Remote Procedure Call is a protocol that allows a program running on one host to cause code to
be executed on another host without the programmer needing to explicitly code for this. RPC is an
easy and popular paradigm for implementing the client-server model of distributed computing. An
RPC is initiated by the caller (client) sending a request message to a remote system (the server) to
execute a certain procedure using arguments supplied. A result message is returned to the caller.
There are many variations and subtleties in various implementations, resulting in a variety of
different (incompatible) RPC protocols.
http://www.ja.net/documents/NetworkNews/Issue44/RPC.html
168Z-0202A-WWEN
Microsoft .NET Web Services Solutions
44
WSDL
Web Services Description Language WSDL is an XML format for describing network services as a
set of endpoints operating on messages containing either document-oriented or procedure-oriented
information. The operations and messages are described abstractly, and then bound to a concrete
network protocol and message format to define an endpoint. Related concrete endpoints are
combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints
and their messages regardless of what message formats or network protocols are used to
communicate; however, the only bindings described in this document describe how to use WSDL in
conjunction with SOAP 1.1, HTTP GET/POST, and MIME.
CXML
(Commerce XML) is a set of document type definitions (DTD) for the XML specification. cXML
works as a meta-language that defines necessary information about a product. It will be used to
standardize the exchange of catalog content and to define request/response processes for secure
electronic transactions over the Internet. The processes include purchase orders, change orders,
acknowledgments, status updates, ship notifications and payment transactions.
http://www.cxml.org/home/
ADO+
“ADO+ is the . . .set of data access services for the .NET Framework. ADO+ is a natural evolution
of ADO, built around n-tier development and architected with XML at its core.”
Welcome to the MSDN Library
168Z-0202A-WWEN