The LA Fox Developer Newsletter

November 2000

".NET" (Con’t from page 3)

company might assemble an online store using the Microsoft

Passport service to authenticate users, a third-party personal-

ization service to adapt Web pages to each user’s preferences,

a credit-card processing service, a sales tax service, package-

tracking services from each shipping company, an in-house

catalog service that connects to the company’s internal inven-

tory management applications, and a bit of custom code to

make sure that their store stands out from the crowd. Figure 1

shows a model that illustrates how Web Services can be linked

to create distributed Web applications.

Figure 1 Web Services Application. Model

Unlike current component technologies, however, Web Services

do not use object model-specific protocols such as DCOM,

RMI, or IIOP that require specific, homogeneous infrastructures

on both the client and service machines. While implementations

tightly coupled to specific component technolog ies are perfectly

acceptable in a controlled environment, they become impracti-

cal on the Web. As the set of participants in an integrated

business process changes, and as technology changes over

time, it becomes very difficult to guarantee a single, unified

infrastructure among all participants. Web Services take a

different approach; they communicate using ubiquitous Web

protocols and data formats such as HTTP and XML. Any

system supporting these Web standards will be able to support

Web Services.

Furthermore, a Web Service contract describes the services

provided in terms of the messages the Web Service accepts

and generates rather than how the service is implemented. By

focusing solely on messages, the Web Services model is

completely language, platform, and object model-agnostic. A

Web Service can be implemented using the full feature set of

any programming language, object model, and platform. A Web

Service can be consumed by applications implemented in any

language for any platform. As long as the contract that explains

the service’s capabilities and the message sequences and

protocols it expects is honored, the implementations of Web

Services and Web Service consumers can vary independently

without affecting the application at the other end of the conver-

sation.

The minimum infrastructure required by the Web Services model

is purposefully low to help ensure that Web Services can be

implemented on and accessed from any platform using any

technology and programming language. The key to Web Service

interoperability is reliance solely on Web standards. However,

simply agreeing that Web Services should be accessed through

standard Web protocols is not sufficient to make it easy for

applications to use Web Services.

Web Services become easy to use when a Web Service and

Web Service consumer rely on standard ways to represent data

and commands, to represent Web Service contracts, and to

figure out the capabilities a Web Service provides.

XML is the obvious choice for defining a standard yet extensible

language to represent commands and typed data. While rules

for representing commands and typed data using other tech-

niques (such as encoding as a query string) could be defined,

XML is specifically designed as a standard metahanguage for

describing data. The Simple Object Access Protocol (SOAP) is

an industry standard for using XML to represent data and

commands in an extensible way. A Web Service can choose to

use SOAP to specify its message formats. You can learn more

about SOAP and the SOAP Toolkit for Visual Studios 6.0 from

Rob Caron’s article in the August 2000 issue of MSDN Maga-

zine (see “Develop a Web Service: Up and Running with the

SOAP Toolkit for Visual Studio”).

XML is also the enabling technology for the Web Service

contracts. The Service Contract Language (SCL) is an XML

grammar for documenting Web Service contracts. Since SCL is

XML-based, contracts are easy for both developers and devel-

oper tools to create and interpret. A draft of the SCL specifica-

tion should be available shortly. (Note that the SOAP Toolkit for

Visual Studio 6.0 currently supports an earlier version of SCL,

known as SDL.)

The Disco specification will describe a standard way for service

providers to publish Web Service contracts and the correspond-

ing mechanism that lets developers or developer tools discover

contract documents. A draft of the Disco specification should be

available by the time you read this.

Standards like SOAP, SCL, and Disco help developers since

they do not need to understand and implement different ways to

access each Web Service that they use. Even better, well-

tested, high-performance infrastructure supporting these stan-

dards can be supplied by development platforms, greatly

simplifying the entire development process.

The Microsoft .NET Framework

The goal of the Microsoft .NET Framework is to make it easy to

build Web applications and Web Services. Figure 2 shows the

Microsoft .NET Framework architecture. Built on top of operat-

ing system services is a common language runtime that

manages the needs of running code written in any modern

(Con’t, page 5)

Page 4