3
|
|
3 |
|
|
The LA Fox Developer Newsletter
|
|
December 2000
|
|
Getting Ready for “.NET”...Part 2
(SUMMARY: Web Services are building blocks for constructing distributed Web-based applications in a platform, object model, and multilanguage manner. Web Services are based on open Internet standards, such as HTTP and XML, and form the basis of Microsoft’s vision of the programmable Web. This article defines Web Services and the key enabling technologies that ensure services can be aggregated into applications. It then describes Microsoft’s new Microsoft. NET Framework and its support for creating and consuming Web Services. This is the concluding part of an article begun last month in
The Developer.]
Win Forms Application Model
Conceptually, on top of the services framework sit two application models: the Windows® application model and the Web application model. Although I’ve focused on the Microsoft .NET Framework as a way to develop Web Services and Web applications, the framework can also be used to develop more traditional Windows-based applications (of course, these applications can use Web Services, too).
Developers writing client applications for Windows can use the
Win
Forms application model to take advantage of all the rich user interface features of Windows, including existing ActiveX controls and new features of Windows 2000, such as transparent, layered, and floating windows. Either a traditional Windows or Web appearance can be selected. Developers will find the Win Forms programming model and design-time support very intuitive, given its similarities to existing Windows-based forms packages.
Win Forms also takes advantage of the Microsoft .NET Framework runtime to reduce total cost of ownership for Windows- based client applications. The framework security model can safely execute applications and components on client machines provided they are written using the
Win
Forms model or used from a
Win
Forms application. If implemented or used in this way, the cute game someone got off the Internet won’t corrupt configuration information and data, or automatically send e-mail to everyone in the user’s address book.
The Microsoft .NET Framework assembly model simplifies application deployment and versioning. Applications
can
be configured to use the versions of shared components they were built and tested with, rather than using whatever component versions happen to be installed on the client machine, improving application reliability and eliminating one of the major causes of application support calls: incompatible versions of user interface
|
controls and other shared components.
A Model for Web Applications
Web applications built on the Microsoft NET Framework share a common application model. In this model, a Web application is a set of URLs rooted at some base URL. Thus it encompasses both Web applications that generate pages for display in a browser and Web Services. In this section, I’ll detail the Web application programming model called Active Server Pages+ (ASP+), which is illustrated in Figure 5.
Figure 5 ASP+ Web Application Model
As you might guess from the name, ASP+ evolves from Active Server Pages. ASP+ takes advantage of the common language runtime and services framework to provide a reliable, robust, scalable hosting environment for Web applications. ASP+ also benefits from the common language runtime assembly model to simplify application deployment. In addition, it provides services to simplify application development (such as state management services) and higher-level programming models (such as ASP+ Web Forms and ASP+ Web Services).
At the core of ASP+ is the HTTP runtime, a high-performance runtime for processing HTTP requests that is based on a low- level architecture similar to the ISAPI architecture provided by Microsoft Internet Information Services (IIS). The HTTP runtime, as you saw in Figure 5, is managed code that runs within an unmanaged host process, such as lIS on server machines or Microsoft Internet Explorer on client machines. The HTTP runtime is responsible for processing all incoming HTTP requests, resolving the URL of each request to an application, and
|
|
Page 3
|
|
|
3 |
|