An architecture for distributed applications on the Internet: Overview of the Microsoft.Net Framework

Journal of SMET Education : Innovations and Research, Jan-Jun 2003 by Barnett, Bryan, Kirtland, Mary, Ganapathy, Mythreyee

Introduction

One of today's most pressing computing challenges is application integration: taking different applications running on different operating systems built with different object models using different programming languages and integrating them into robust systems for supporting critical business processes or scientific research programs. Application developers increasingly want and need to reach beyond tightly-coupled client-server environments to access functionality on remote systems that are very different in design and implementation, and which are owned and managed by other organizations.

Because of its ubiquity, the Internet is driving this demand. Creating a viable architecture for Web-based component interaction is one of the foremost challenges of distributed computing today, and is a major objective of Microsoft's .NET Framework. The.NET Framework is a component of Windows that provides a programming model and runtime for XML Web services, Web applications, and smart client applications. The NET Framework is a key part of Microsoft .NET, software that connects information, people, systems and devices. Microsoft's goal is to support creation of a standardsbased architecture for distributed applications on the Internet. To enable easy application development and deployment, .NET provides a specially adapted toolset and runtime environment for creating and running highly distributed applications.

This paper describes the essential components of the new .NET Framework, including the common language runtime, base class libraries, the services framework, and the programming models for building and integrating applications over the Web. We will examine these components in general, but take a special look at .NET as a connected architecture for building and supporting Web-based applications of the kind now commonly called "Web services".

A First Look at XML Web Services

Broadly speaking, an XML Web service is simply a URL-addressable resource that programmatically returns information to clients who want to use it. One important feature of XML Web services is that clients don't need to know how a service is implemented. In this sense XML Web services represent blackbox functionality that can be reused without worrying about how the service is implemented. XML Web services provide well-defined interfaces, sometimes called contracts that describe the services provided. Developers can assemble applications using a combination of remote services, local services, and custom code. For example, a company might assemble an online store using an internal authentication service, a third-party personalization service to adapt Web pages to each user's preferences, a credit-card processing service for billing purposes, a sales tax service to calculate tax on each transaction, 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 XML Web services can be assembled to create fully functional distributed Web applications.

XML Web services are, at their core, simply a component technology for the Internet. Unlike current component technologies, however, XML 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 technologies 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. XML Web services take a different approach; they communicate using ubiquitous Web protocols and data formats such as SOAP and XML. Any system supporting these protocols will be able to support XML Web services.

Furthermore, a XML Web service contract describes the services provided in terms of the messages the XML Web service accepts and generates rather than how the service is implemented. By focusing solely on messages, the XML Web services model is completely language, platform, and object model-agnostic. A XML Web service can be implemented using the full feature set of any programming language, object model, and platform. A XML 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 XML Web services and XML Web service consumers can vary independently without affecting the application at the other end of the conversation.

The minimum infrastructure required by the XML Web services model is purposefully low to help ensure that XML Web services can be implemented on and accessed from any platform using any technology and programming language. The key to XML Web service interoperability is reliant solely on Web standards. However, simply agreeing that XML Web services should be accessed through standard Web protocols is not sufficient to make it easy for applications to use XML Web services. XML Web services become easy to use when an XML Web service and XML Web service consumer can rely on standard ways to represent data and commands, to represent XML Web service contracts, and to figure out the capabilities a XML Web service provides. Under the auspices of the W3C (World Wide Web Consortium) and other standards bodies, Microsoft and other companies have worked to define and support a variety of basic standards for interoperability and discoverability of XML Web services.