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 personalization 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 inventory 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 impractical 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 techniques (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 Magazine (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 developer tools to create and interpret. A draft of the SCL specification 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 corresponding 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 standards 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 operating system services is a common language runtime that manages the needs of running code written in any modern

(Con’t, page 5)

Page 4