The Performance Tracking (PT) Admin application and the BackOffice® Developer's Guide (BDG) Scenario 3 document address the following objectives:
The first three goals are addressed throughout the document. The fourth is addressed in Measuring Application Performance at the end of the Implementation section. BDG Scenario 4 will build on the performance baseline measurements we obtained by testing the PT Admin application, and will discuss how the team used test results to improve the application's code.
Note The PT application tracks the performance of people in a structured learning environment such as a corporate training center or a school. It is not an application or tool that measures software performance.
BDG Scenario 3 addresses the increasing importance of XML in enterprise development by introducing some basic techniques for using XML in applications. The major trend in XML development is to use it for business-to-business communication, providing a common data format that can be understood by heterogeneous platforms. The PT application focuses on ways to convert XML data to HTML for display. Our target is the Web browser, but the same application infrastructure might easily output XML targeted at an enterprise's mainframe computer where professional certifications are stored in personnel records.
The PT application uses XML to implement localized user interfaces and to move data among the application's tiers. This application uses Extensible Stylesheet Language (XSL) and the XML Document Object Model (XML DOM) to perform server-side operations that generate localized HTML pages that are sent to the browser. For displaying data, the application's HTML pages use the XML Data Source Object (XML DSO) to bind data to HTML tables in the Web browser. A COM object on the business-services tier converts data stored in SQL Server to XML.
In the expanding global economy, enterprises have an increasing need to share data among personnel whose software is configured for different locales. Scenario 3 engages the issues that arise when employees who speak different languages need to view and understand the same data. The PT Admin application was globalized as it was developed and, with XML files that store text for German and Japanese HTML pages, can be localized for those languages when deployed. In addition, a COM object calls Microsoft Win32® National Language Services API (NLSAPI) functions to handle locale-sensitive data. The PT application starts in the right direction toward handling the complexities of globalizing and localizing software, but falls short of a truly globalized and localized application. Lessons Learned details the further enhancements the PT application requires to meet the standards for a globalized and localized application.
Scenario 3 aims to provide reusable and extensible code that can be used as-is or adapted to your software projects. In addition, we provide the source code not only for text-based code files such as ASP pages and JavaScript files, but also for the compiled COM objects that ship in application DLLs. Scenario 3 features COM components designed for reusability. These components include:
In addition to these components, the PT application's JavaScript files were written as generically as possible to perform data validation and other client-side tasks. Finally, for the first time, the BDG includes a tool, the HTML Data Refinery, which was used during application development to facilitate the generation of XML files from the HTML in which they were designed.
Discovering where a Windows DNA application consumes resources most intensively presents more of a challenge than traditional profiling tools can handle. Traditionally, tools have focused on evaluating server loads; with Windows DNA, distributed processing demands tools that can discover resource-intensive processes anywhere. The ultimate goal is to isolate and quantify the consumption of system resources, wherever it takes place, which permits better-targeted performance tuning. But to measure performance comprehensively, tools must simulate the Web browser more effectively than they have in the past.
Starting in Scenario 3, the BackOffice Developer's Guide begins to investigate how our Windows DNA application performs. Two tools, produced by different vendors, measured the PT application's baseline performance. These tools provided similar ways to apply a load on all the tiers on which a given application runs. In future scenarios, the BDG will attempt to identify how technologies perform across all tiers of an application, and how to develop applications that improve the balance of resource loading across those tiers.