TechNet Home Page   All Products  |   Support  |   Search  |   microsoft.com Home  
Microsoft
  TechNet Home  |   TechNet CD Online  |   Events  |   International  |

Search TechNet
Advanced Search

 Features

 Hot Topics
Year 2000
Euro
Intranet
Commerce

 Technical Information

 Community

 IT Scenarios

 Managing IT

 TechNet CD-Rom

Microsoft Year 2000 Readiness Disclosure & Resource Center
Building Year-2000 Compliant Applications with Visual Studio and Windows DNA
3. Distributed InterNet Applications Architecture

The Windows Distributed interNet Applications (DNA) architecture, introduced by Microsoft in September 1997, represents a comprehensive new framework for integrating client/server and internet software solutions on the Windows platform. The goal of the DNA architecture is to integrate the development model for applications so that they can harness the power and advanced processing capabilities of today's PCs, yet still take advantage of the flexibility and ease of deployment of the Web.

Windows DNA is based on the premise of the integration and interoperability of software components. DNA combines "component based" software development with a "service based" operating system. One of the ways Microsoft accomplishes the goals of DNA is by tightly integrating the core application infrastructure into the operating system. By building functions like transaction processing, message queuing, security and directory services into the operating system, Microsoft has freed the developer from spending a significant amount of project resources creating the application infrastructure. In addition, since these services are provided by the operating system, all levels of the application - the user interface, business services, data services - can use them as needed. This means that a developer writing a web-based front-end and another creating server-side business components both have access to the underlying infrastructure.

Component-based software is assembled from independent pieces that interrelate to perform a specific function. Components written to the Windows DNA architecture have well-defined COM interfaces that make them extendable and subscribe to or utilize services provided by the operating system which makes them compatible. For example, a developer writing a component that needs to implement asynchronous messaging can use the interface published by the operating system and know that it will be compatible with any other messaging-enabled component written to that interface.

Windows DNA applications are fundamentally different from most of today's corporate applications. That's because Windows DNA lets developers take advantage of Internet, LAN-based, and client/server computing -- enabling the applications they create to do more at a lower cost.

Overview of the Sample Application

For the remainder of this paper, we'll look at a sample application that is built upon the Windows DNA architecture. The application was designed to highlight the proper development techniques for handling dates when using Microsoft Windows DNA-based development tools. Since code snippets from the application will be used throughout the next sections, you may want to open the sample application for reference. The application can be opened using Visual Studio to open the workspace Y2k.dsw from the folder that you selected at installation time. The technologies used include Visual Basic Scripting Edition® (VBScript), JavaScript, Active Server Pages, Microsoft Transaction Server (MTS), ActiveX® Data Objects and the HTML subset of DHTML. The development tools used include Visual InterDev web development system, Visual J++ development system for Java, Visual Basic and Visual C++® development systems from Microsoft Visual Studio®, as well as Microsoft SQL Server. There is an alternate client portion written as a Microsoft Excel 97 worksheet. Don't worry if you do not have all of the Developer Studio development tools installed on your system. As long as you're not going to recompile the application, you won't need all of the tools.

Requirements for running the sample application

Running the sample application is not necessary in order to follow this paper, but may help you to understand the context of some of the code snippets. If you wish to run the application, make sure you are running Windows NT® Server 4.0 Service Pack 3 or later, with Windows NT Option Pack installed, along with SQL Server 6.5 with Service Pack 2 or later. The application needs to create a table in the "pubs" database. If you do not plan on running the sample application, you can elect not to create the table. The COM components (written in Visual Basic and Visual C++) can be imported into MTS by importing the package file Y2kPackage installed in the folder Y2K\MTS. This step is optional; the application will still function correctly outside of MTS.

The application tracks the accounts receivable of a fictional company. The user enters transactions for one of three customers, and then views an accounts receivable aging report. The report summarizes the dollar amount outstanding for the time periods 0-30 days, 31-60 days, 61-90 days, etc. The application is very simple in its design, and is not meant to illustrate a solution to any particular business problem. Nor is it meant to be an example of an ideal architecture using Windows DNA. Rather, it is intended to be used as a mechanism for understanding the underlying techniques used when handling date-related data, including date validation, date formatting, and data arithmetic.

The application addresses all of the pieces of a relatively complex Windows DNA "helix". There are two client portions to the application: a web-based version that uses a Visual J++ applet as the main user interface for data entry; and an Excel 97 worksheet version that interfaces directly with the business component. Notice how in each scenario below a date passes from component-to-component.

For the Excel-based client:

  1. The user enters values directly into cells in an Excel worksheet.
  2. The worksheet uses VISUAL BASIC macros to perform the client-side data validation.
  3. The data is then passed to a VISUAL BASIC component running in an MTS process on the server.
  4. The VISUAL BASIC component validates the data, partially through the use of a C++ COM component also hosted in MTS.
  5. If the data is validated, the VISUAL BASIC component uses ADO (via the OLEDB provider for ODBC) to store the data in the "pubs" database on SQL Server.

For the web-based Java client:

  1. Javascript on the web page queries the applet for values entered by the user and passes them to the web server for processing via an HTTP Post.
  2. ASP code on the server receives the data.
  3. ASP passes the data to a VISUAL BASIC component running in an MTS process on the server.
  4. The VISUAL BASIC component validates the data, partially through the use of a C++ COM component also hosted in MTS.
  5. If the data is validated, the VISUAL BASIC component uses ADO (via the OLEDB provider for ODBC) to store the data in the "pubs" database on SQL Server.

The following diagram outlines the structure of the sample application.


Figure 1   The sample application architecture.   (If your browser does not support inline frames, click here to view Figure 1 in a separate page.)

The application consists of the following:

File(s) Description Location
Y2k.dsw Visual Studio workspace Y2K
Y2kApplet.dsp Visual J++ project for Java applet. Y2K\JavaApplet
Y2K.xls Excel 97 worksheet user interface Y2K\Excel
Y2kSample.dsp Visual C++ project for C++ COM component Y2K\C_helper
Y2kWeb.dsp Web project – ASP pages and Web files Y2K
Y2k.VBP VISUAL BASIC Project for VISUAL BASIC component Y2K\VB
Y2kPackage.pak MTS Package Y2K\MTS
Y2k.dat Database definition file Y2K\data

Development Philosophy

It is helpful to establish an overall "Year 2000 compliance" philosophy when setting out to develop an application. A philosophy can then be integrated into the application's design strategy, or the company's development strategy as a whole. The philosophy for achieving Year 2000 compliance is fairly straight forward:

  • Always use the development tools' date data types or otherwise insure no loss of precision.
  • Always use the development tools' data math/comparison operators, or develop operators that insure no loss of precision (including exception handling, such as leap years).
  • Make sure the development tool and environment itself do not have Year 2000 issues (e.g. check out http://www.microsoft.com/y2k for Microsoft's compliance). Be sure to consider all of the tools being used throughout the system, including things like report writers, third party add-ons and controls, etc. Also be sure to consider the underlying infrastructure, such as the data access drivers and network protocols.

The sample application subscribes to and illustrates this philosophy

<< 1 2 3 4 5 6 7 8 >>


Send This To a Friend Download This Article


 

Thursday, March 11, 1999
© 1998 Microsoft Corporation. All rights reserved. Terms of use.

This site is being designated as a Year 2000 Readiness Disclosure and the information contained herein is provided pursuant to the terms hereof and the Year 2000 Information and Readiness Disclosure Act.