Porting CCAIR to Microsoft Dot-NET

Copyright Material Contra Costa County Health Services / Information Systems Division

Paper No. IRC Abstract # 3750

Siu Wing Tong
IS Supervisor / Rebecca Carr
Programmer/Analyst
Abstract
With the advent of better and faster development tools and widespread acceptance of the internet, Contra Costa County Health Services (CCHS) re-wrote the Contra Costa Automated Immunization Registry (CCAIR) 2.x using Microsoft’s latest development platform, dot-NET, and renamed the application to eCCAIR 4.0. The purpose of this paper is to describe our experiences using this new technology and the benefits that we have derived by doing so.

Introduction

CCAIR evolution to the current eCCAIR 4.0

CCAIR 2.x, developed from 1995 to 2000, was originally built using Microsoft development tools (Visual Basic 4.0, 5.0 and 6.0) and has been running on various Windows operating system versions. The web-enabled version, CCAIR 3.0, developed from 1999 to 2001, was built using Active Server Pages (ASP) for internet browsers. A copy of CCAIR 3.0 was turned over to the California Department of Health Services in 2001 for use throughout the state and their further development into CAIR. In December of 2001, the client/server version of CCAIR was re-written using the latest Microsoft dot-NET development tools. The dot-NET version of CCAIR was re-versioned as eCCAIR 4.0. eCCAIR 4.0 is web-enabled and at the same time retains a dual client/server Windows front-end.

CCHS requirements

CCHS requirements that led to the decision of porting CCAIR to dot-Net include:
  • CCAIR was written in previous versions of ASP which were difficult to maintain and expand because both the user interface (UI) and the business logic were mingled into the same source files resulting in large program files that were slow to execute and tedious and error-prone to debug
  • CCHS wanted to leverage new development tools to provide existing functionality for both the intranet and internet environments that would address easy and jointly Windows-based and browser-based development to take advantage of code re-usability
  • CCHS needed a shorter development cycle and wanted faster execution of the end product; the development environment needed to facilitate easier and less error-prone maintenance of the application and enable simplified delivery methods
  • CCHS needed a development environment that would ensure scalability and expandability for new features to support strategies aligned with the growth, connect and protect standards of excellence. Specifically, eCCAIR would need to include a set of enhancements that were planned over the past several years and to be included in the next version of CCAIR. In addition, the core architecture needed to be modified so that some of the essential functions (e.g., the next vaccination due date algorithm) could be made available to other applications and processes via components and web services.

Dot-NET Features Influencing the Decision

CCHS chose Microsoft’s new dot-NET’s software development platform to build Windows and internet based immunization registry solutions that are supported by databases, webs servers and are accessible to other external systems. Compelling dot-NET features that influenced this decision include:
  • ASP improvements - ASP.NET runs on a Microsoft IIS-hosted infrastructure and is a successor to the older ASP technology used to build earlier versions of CCAIR. ASP.NET produces compiled code (rather than interpreted code as in the older ASP) resulting in much faster execution. ASP.NET also separates the UI design and the code behind it into separate program files for easier maintenance.
/
  • Browser-independent HTML - Much of the logic and code used to build the UI for a browser-based dot-NET application resides and runs on a web server rather than the local machine. The browser-based graphical user interface (GUI) is dynamically built by the ASP.NET application that transmits Hypertext Markup Language (HTML) to the browser. Even though the server-side code depends on the dot-NET Framework to build the GUI, it produces browser-independent HTML. Therefore, the browser client can theoretically be any internet browser tool (such as Internet Explorer or Netscape), running on many other platforms.
  • Reduced deployment complexity - The dot-NET development environment enables new versions of the Windows-style applications to be introduced with no impact to the users. Dot-NET Windows-style applications compiled with dot-NET run on top of the dot-NET Framework. Dot-NET Framework’s runtime environment needs to be installed only once on the user’s workstation. Installation can be performed as part of the initial installation or as separate task. Once installed, distributing new dot-NET applications and/or updating with new modules simply becomes a matter of copying files on client machines and requires no registration of Dynamic Link Libraries (DLLs) (i.e., avoids “DLL-HELL”). Applications can also be run remotely using “No-Touch Deployment” which runs on top of the internet browser’s infrastructure. Accessing applications in a shared network location via a web page or Uniform Resource Identifier (URL) eliminates the need to install the Windows-style rich client application on individual machines.
  • Wide range of device interaction - Dot-NET provides the ability for users to interact with a range of devices (phones, table devices, pocket PCs, voice, workstations).

Our Experiences

Getting started; compatibility across development platforms and tools
We decided to port CCAIR 2.x to dot-NET after the Immunization Registry Conference (IRC) in Little Rock, Arkansas in 2001. The development effort started in December 2001 with the availability of a beta version of the dot-NET tools. We switched to the released version of dot-NET when it became available in February 2002. The Developers’ workstations were equipped with both Visual Studio Dot-NET and the older Visual Basic 6.0 tools. These tools co-existed very well without conflicts.

Project team composition, work breakdown structure and method

Our team to port CCAIR 2.x to eCCAIR 4.0 consisted of eight developers spending one fourth of their time for approximately eight months. We were required to carry over all of the functionality that was already built into CCAIR 2.x, an application that has been field tested, verified for years and that has become an essential and reliable tool. Each developer was responsible for specific modules. Some developers focused on GUI elements. Another developed a component that provided data access functionality that was used by both the browser-based eCCAIR 4.0 and Windows Forms-based eCCAIR 4.0. Using the existing version as a guide and the new Visual Studio.Net compiler, an entire new set of program codes was written. Both web-based and Windows-based versions were created but both made use of many shared data components.
Quicker component integration/reduced implementation time
Business and data access functionality was built into components shared by both the browser-based and Windows Forms-based CCAIR. This new approach enhanced the process of component integration so that changes and additions were quickly implemented. Development time was significantly reduced.

Document Name: Dot Net White Paper V 0.6 - 1 -

TONGet al.: Porting CCAIR to Microsoft Dot-NET

Porting execution code not fruitful
The Visual Basic language itself underwent many changes during this evolution into Visual Basic dot-NET, both in syntax and behavior. Our first attempt to port the old existing program code using the automatic converter shipped as part of the development package was not fruitful. Hence, we decided to redo almost all of the code in the new language.
Faster, more streamlined development effort
Our development effort exceeded our expectations in the time that it took to complete the project. We attribute this to the availability of the dot-NET Framework platform. The dot-NET Framework Class Library is a comprehensive set of feature-rich objects requiring less code to be written. For example, any dataset can be expressed as XML with simple method calls. Similarly, XML data can be parsed and loaded with fewer method calls. Visual Studio dot-NET compilers also perform compile-time checking of types that is very useful to avoid runtime errors. The new environment also features a very advanced debugger that includes features like “intelli sense” that displays syntax errors in real time.
Faster process execution
One of the most important results that we realized was that processes executed faster. For example, a transaction that involves pulling a patient record and the associated shot history was reduced considerably. Using analog voice modems over public phone lines, this transaction was reduced from 22 seconds in our previous version (CCAIR 2.x) to 6 seconds in our new eCCAIR 4.0.
Easier integration with other tools; availability of application to web services and components
We also switched to a new database connectivity technology, ADO.NET that uses newer objects such as datasets. This object supports persistence of data as standard XML. This enables us to share our data via platform independent XML and makes our objects easier to integrate into other tools. For example, our functions and data within CCAIR can be made available via web services or components.
Simplified delivery and deployment
We confirmed that the browser-based version of new CCAIR could be run without requiring an installation of the dot-NET Framework on the user’s workstation. All 32-bit Windows operating systems including Windows 95 are supported if browser-based applications are run. However, Microsoft Internet Explorer 5.01 or later is still preferred. We were especially pleased with not having to register components on workstations because it reduced the complexity of deployment and simplified our support efforts. On the other hand, the Windows-style version of the new CCAIR requires dot-NET Framework to run; therefore, Windows 98 or higher is required (Windows 95 is no longer supported). Another practical aspect is that the new binary images that need to be distributed are much smaller. Having smaller binary images provides the opportunity to run the applications over the network since the bandwidth of the network can support the delivery of these smaller modules as needed or demanded by users.

Conclusion

CCHS confirmed during their dot-NET conversion of CCAIR that the new platform would greatly improve the development environment by facilitating faster, easier, less error-prone maintenance of the application; easier integration of components; reduced implementation time; faster web pages (ASP) due to pre-compilation; simplified deployment; improved data access via XML and web services; support for mobile devices; and new alternatives of speech and pen-based inputs. We will continue to port more of our existing in-house developed software currently written in older Visual Basic 6.0 to the dot-NET environment. Our developers may not want to go back to using the old tools. /

Acknowledgment

The authors would like to acknowledge the project team participants for their efforts importing CCAIR to dot-NET: Ates Temeltas, Shirley Sianghio, Patrick Casilao, Bhumil Shah and Carol Fitzgerald. Special thanks go to Bhumil, Shirley and Patrick for their assistance in reviewing this paper prior to its distribution at the 2003 Immunization Registry Conference.

References

SiuWing Tong, Shirley Sianghio and Patrick Casilao’s “IRC Abstract # 3750 Porting of CCAIR to Microsoft dot-NET, One Year Later”, presented at the National Immunization Registry Conference, Atlanta, Ga, 2003.
SiuWing Tong, PhD, CCHS IS Supervisor, was responsible for developing the initial CCAIR. Under Dr. Tong’s leadership, CCAIR development was aligned with developments in software and systems development strategies and in particular Microsoft’s new architectural paradigm over the last several years. The dot-NET tools were announced to address the new realities of internet and intranets as these concepts firmly take place in daily transactions of every day business needs. Dr. Tong was interested in using the new technologies for a number of reasons including the ability to provide faster executing applications, ability to develop solutions with both Windows forms-based applications and browser-based applications, ability to better respond to requests for new functionalities, provide easy scalability, maintainability and to provide faster and more streamlined delivery methods. As a result, Dr. Tong initiated the project to port CCAIR to Microsoft dot-NET, oversaw the development and provided technical assistance when needed.
Rebecca Carr, Programmer Analyst, prepared this paper based on the work performed by the project team. Mrs. Carr has several years experience working as a systems analyst in the United States, Canada and the Middle East. She is currently preparing the analysis and design specifications for an OB Prenatal application for the Contra Costa Health Services OBGYN department.

- 1 -