Server Operating System
White Paper© 1996 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft, MS-DOS, Visual Basic, Visual C++, Windows, and Windows NT are registered trademarks and ActiveX, BackOffice, the BackOffice logo, and Visual J++ are trademarks of Microsoft Corporation.
Other product or company names mentioned herein may be the trademarks of their respctive owners.
Microsoft Corporation · One Microsoft Way · Redmond, WA 98052-6399 · USA
1196 Part no. 098-67846
This White Paper—part of a series of DCOM related White Papers—introduces several real-world solutions that apply DCOM to facilitate development and deployment of distributed applications.
The scenario described in this paper will show how DCOM can eliminate the need for a custom communication infrastructure and how easy it is to include the connectivity provided by the Internet in the design of a distributed application.
A company sells airtime for commercials on behalf of a couple of local radio stations. It is a fast moving and aggressive business, where airtime slots are sold, often at the last minute, over the phone. Customers constantly ring up requesting information about free slots, and during peak office hours, some twenty or so customers need to be handled at once. As unsold slots do not bring in any revenue, timely access to information is vital.
The current system used by the company is comprised of a simple program for the Microsoft® MS-DOS® operating system, which is running on the workstations, used by the sales consultants, and displays the status of all the slots for each radio station. Once a slot has been booked all the workstations need to be updated. All of the actual air time information is stored in a single database held on a small UNIX server.
One of the original challenges when designing the system was to devise a mechanism to handle updates from the UNIX server out to all of the client workstations. A special protocol was developed, which ran over TCP/IP that handled the two-way communication needed to keep the information on the workstation screens up to date.
Though the system met most of the original design requirements, it proved to have some limitations:
At the same time, the company was also looking for ways in which it could get the latest air time slot information out to its customer, that would not tie up their sales consultants on the phones, thereby freeing them up to generate more sales leads.
Once the company started looking at its requirement, it came up with a couple of obvious conclusions:
At this point, it would have been easy to simply rewrite the front-end application in a Windows-based tool, such as the Visual Basic® programming system or Visual C++® development system, and recreate the existing system.
However, it was the impetus to solve the problem of publishing air time slot information to its main customer base, thus freeing up time for the sales consultants, that lead to the company investigating the use of the Internet. By making this information available over the Internet, many of the existing inquiries could be satisfied by allowing users to view this information using an Internet browser. The information could come directly from the database, so it would always be up to date. Obviously, sensitive information, such as the owners of the booked slots, would not be available over the Internet.
The decision to use the Internet heavily influenced the application and system architecture the company used, particularly as it wished to avoid creating one system for the sales consultants, and one for the customers.
The chance to re-engineer the system lead to a few other opportunities.
The new application would support COM Automation, so that simple Microsoft Visual Basic for Applications (VBA) scripts could be used to extract information from the system, as well as drive the system to a limited extent. Some scenarios that would prove valuable included:
To support the Internet, as well as help lower system administration costs, it was decided to install a Windows NT® Server to host the new database, Microsoft SQL Server™, and Microsoft Internet Information Server.
ActiveX™ Controls that used DCOM formed the basis of the new architecture. The airtime slot information for a particular day could be viewed using an “airtime” ActiveX Control developed by the company. The control could be hosted in the Visual Basic applications developed for use internally within the company, or Microsoft Internet Explorer for customers accessing the company’s Web page to view air time information.
The “airtime” control used DCOM to communicate to a server-side component located on the Web server, which had access to the SQL Server database where the airtime information resided. By using the distributed nature of DCOM to communicate between the client and server component, the company did not need to develop any of its own communication code.
By using a DCOM ActiveX Control on the client side, the control could receive updates from the server-side component, allowing the information to be updated in real time, in response to changes in airtime sales. Without the
ActiveX technology, the HTML page would have had to be regenerated and retransmitted periodically, which would have absorbed more bandwidth, and not produced real-time results.
The company was also able to reduce development costs by using the same ActiveX Control in the internal applications that were used to fulfill the various work scenarios that it had identified. This was possible as the control exposed access to all of its functionality through COM automation.
With the success of the new system, and the increased use of the Web-based facilities, the company is considering ways in which it can enhance the range of services it offers to satisfy existing customers, and attract new customers.
One of projects under development is to use the Microsoft ActiveX Server Framework to create more dynamic HTML pages that can be customized for existing customers to provide additional information, such as discount offers and purchase incentive ideas.
The company is also looking to host commercial sponsorship messages on its Web site as a way of funding extra investment in its system. The ActiveX Server Framework provides an easy way to display different sponsorship messages and images on the Web pages that are constantly changing.
The company is also looking at taking booking requests directly over the Internet.
This fictitious scenario shows some of the benefits of migration from a simple two-tier client server to a distributed component system.
A parcel delivery service company has depots around the country. The existing system has a Windows NT Server in each depot, with a number of PC workstations, typically anywhere between five and fifty.
A private wide area network connects all of the depots. Major depots are using higher-speed lines and smaller depots connect with lower-speed lines to these main depots.
Some of the databases were held at the depots, and were running Microsoft Access, while others were held centrally, and ran Microsoft Access and
SQL Server.
The problems with the system included:
In addition, a customer call center was being planned, with a “toll free” number that customers could call to find out if their parcel has been delivered.
Against a background of a limited budget, and a backlog of user requests for new applications and bug fixes, the development team decided on a medium-term consolidation and migration plan to a new architecture.
In order to get application development under control, programs would adopt a more consistent approach to accessing and updating information. Using some object-oriented analysis techniques, the functionality provided by the existing system was broken down into a number of components, each with well-defined interfaces. These would be used by all applications to access and update all of the data in the databases.
At the same time, breaking down the system functionally into components helped increase system performance. Previously, all application code had to be loaded into memory on each workstation. By using the distributed capabilities of DCOM, it was possible to share common components across a number of workstations, and have these components run on a separate machine. Putting in a higher-specification machine, where required, into a number of the branches was far more economical than upgrading all existing machines.
Deciding how the common components were to be distributed across the wide area network for optimal performance was a non-trivial task, and one that would change in response to both organizational changes over a period of time, and the dynamic network and computer loading characteristics which would vary on a day-to-day basis.
Some form of dynamic distribution scheme was obviously required, but one that could be implemented without creating a whole new infrastructure. In the end a simple object broker was used, which would take requests to create objects, and either connect to existing objects, or create new ones on specific machines. The algorithm used was a simple one that took into account some basic network topology information, to ensure that clients connected to copies of objects that were running nearby, and checked machine loading to evenly distribute work between the possible servers.
Within this framework, there was also the challenge to minimize the administration requirements. Each depot was configured as a DNS domain, and each workstation was configured to use the same class broker, which would be mapped onto a central server in each branch. This would use simple text files to map the object requests to specific machines, which could be maintained and updated centrally. In the case of the central database components, the DNS was used to automatically translate the machine name into one of three servers located at the head office.
A company has many different existing information systems on many different platforms. The primary repository is housed on an IBM mainframe; the business transaction systems are in CICS, and data is maintained in DB2. The mainframe hosts all of the data relating to inventory and accounting and all client access is through character-based terminal emulation. The larger remote offices are primarily connected over frame-relay (fractional-T1, and so on) to the main office and the smaller offices are connected over 9600-bps satellite links. The inventory management and accounting applications utilize OLTP but most execute in batch mode. Several UNIX machines are used to communicate to the mainframe. The UNIX applications are used primarily to incorporate business rules with their sales and marketing applications. These applications communicate through gateways and submit CICS transactions to the mainframe.
The small remote sites are connected through satellite links to the UNIX machines located in the larger offices. The larger offices are in turn connected to the mainframe through the WAN/LAN or leased lines. Currently, the business applications located in the remote offices use RS-232 (serial TCP/IP) over satellite links to communicate to the UNIX machines. Some newer offices use WinSock for direct connection to the UNIX machines. In the main office environment the client machines use DCE-RPC for UNIX communications. The user base varies from a couple of people in the remote satellite offices to a few hundred people in branch offices and thousands of people in the main office. The client machines are running a mixture of Windows 3.1, Windows 95, and Windows NT. Some engineering departments are running UNIX workstations.
One of the most notable points to make is that currently the same application must be written differently depending upon the client’s geographical location relative to the main office due to the differences in transport. The developers use different development tools and languages: C, C++, shell scripts, Microsoft Visual Basic, and assembly in limited scenarios.
From an architectural perspective this environment inherently creates the following problems:
This high-level diagram outlines the existing architecture. Client machines are connected to the main offices by a wide variety of protocols and physical architectures.
The objectives are clear and concise with respect to the current environment and future company direction.
Clearly, application performance has always been a metric in the application development arena. Companies are continuously trying to develop applications faster and, at the same time, for less relative cost.
From a business perspective and for mission-critical applications, tolerances in respect to downtime should be zero. For example, the company has two divisions: Sales and Marketing. The Sales department directly interfaces with customers through an order entry system. Unequivocally, the profit of the company would be affected dramatically if orders could not be accepted due to system outages. The Marketing department may be less affected by a system outage and may only be prevented from creating brochures or printing marketing documents. With this in mind:
Maintenance of an application constitutes a large percentage of its lifetime. Mistakes in the development cycle with respect to one application can be extremely costly depending upon at what point in the development cycle the mistake is recognized and corrected; with respect to multiple, coordinating applications, the monetary cost of one mistake can be exponentially higher.
From an upper management perspective the concepts of payout versus payback are extremely important. Historically, investments in technology have offered a high degree of payback; the use of that particular technology outlived the investment associated with it. With respect to today’s technological pace, payback becomes a necessity. With this in mind, the costs associated with application development and maintenance cycles must be significantly reduced.
As the utilization of intercompany communication and electronic commerce increases the need for security at the network and application level also increases. This direct correlation has contributed to the increase in complexity of today’s business applications and their development cycles.
The following solution outlines a framework that will be used throughout the company for designing and deploying new applications. The following basic assumptions form the essence of this framework:
The logical component architecture chosen for this scenario clearly separates application presentation from business processes. The diagram further illustrates the componentization of business and associated services. With respect to browser clients operating over HTTP, an ActiveX Control will be developed to facilitate communication to the different business components.
The physical diagram depicts some of the fundamental concepts involved in integrating DCOM with existing legacy systems. From the client computer’s perspective, the application instantiates a DCOM object; for 16-bit clients, this class instantiation and eventual method invocation occurs over remote automation (RA) and for 32-bit clients this same process happens by using DCOM.
From the perspective of the client application, the process of class instantiation and method invocation over RA versus DCOM is no different. Essentially, all client processes call CoCreateInstance(Ex) to activate an instance of a specific business component. The business component then calls CoCreateInstance(Ex) on the Transport Controller interface (ITransportController).
The Transport Controller object is implemented as a free-threaded COM component, thus addressing concerns centered on scalability. One of the properties of the ITransportController interface defines the type of transport protocol to be utilized for a particular client; RS-232, WinSock, HTTP, ODBC, or DCE-RPC. The Transport Controller then uses the associated Transport Driver (ITransportDriver) to communicate with the appropriate vendor supplied API, which is implemented in a dynamic-link library (DLL), for connection to the data source.
Notice the first phase additionally suggests the development of intranet and Internet enabled applications as the COM architecture totally embraces the Internet/intranet paradigm. As a result of the application being devolved into a component-based design, the details of the user interface (UI) have been devolved from the application and business logic, and so both thin Internet, and thicker, more traditional UI clients can be supported. Both HTML-only and ActiveX-enabled Internet clients will be accommodated via a flexible ActiveX Server design. For HTML-only clients, the UI will be generated on the server using HTML-specific UI components. For ActiveX-enabled clients, part of the UI logic will be established on the client, providing a richer experience to the user.
Since DCOM is enabled to work over lightweight protocols, such as HTTP, and can also work natively over firewalls, client-side components can seamlessly integrate into the architecture.
The following access paths will be supported:
The inventory and sales information will be replicated in Microsoft SQL Server to each of the different regions.
Intranet functionality will be used for marketing and company policy distribution. The company is looking to automate some aspects of their daily operations in the areas of forecasting, sales strategy, and capacity planning. These applications will also use Microsoft SQL Server as their central repository.
As DCOM becomes available on UNIX platforms, the Transport Controller objects will be incrementally eliminated, and the middle-tier business components will communicate to UNIX directly over DCOM. Additionally, COM components will be developed to “wrap” the legacy UNIX applications. This migration strategy does not necessitate the need to rewrite any client applications, since the client applications only speak to the business components.
As DCOM becomes available on mainframes, part of the mainframe applications will be changed to interface directly to DCOM clients, which will provide added flexibility.
For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/backoffice or the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).