Technical Platform

Introduction and Overview:

The dental payer industry is getting complex. Flexible benefit plans, complex reimbursement arrangements and innovative business relationships demand a software solution that allows your organization to remain competitive. You need the ability to easily obtain valuable information so you can steer your organization in the right direction.

The rapidly changing world of technology is equally complex. There are several characteristics that must be included when designing any technical environment:

• Flexibility
• Resilience
• Security
• Cost Effectiveness
• Manageability

N-tier applications have become the norm for building enterprise software today. To most people, an N-tier application is anything that is divided into discrete logical parts. The most common choice is a three-part breakdown: presentation, business logic, and data—although other possibilities exist. N-tier applications first emerged as a way of solving some problems associated with traditional client/server applications. With the arrival of the Web, this architecture has come to dominate new development.

The Microsoft Windows DNA technology has been a very successful foundation for N-tier applications. The Microsoft .NET Framework also provides a solid platform for building N-tier applications. Yet, the changes .NET brings should cause architects to re-think the instructions they have learned about designing N-tier applications in the Windows DNA world. Even more important, the fundamental support for XML Web services built into the .NET Framework allows building new kinds of applications that go beyond the traditional N-tier approach. Understanding how best to architect applications for .NET requires two variables: first, knowing "what" changes in this new world, and second, "how" to exploit the changes.

Likewise, aQDen was designed using the Microsoft Windows DNA technology and N-tier methodologies. This application architecture gives you the greatest flexibility in the design of your technical infrastructure. In the next section we will be reviewing the technical implementation methodologies of aQDen. In keeping with the N-tier architecture approach, we will be concerned with the following application components:

• Presentation Layer (Client)
• Application Layer
• Communications Layer (Distributed Communications)
• DBMS / Data Storage Layer

Presentation Layer The first layer is the Presentation layer. This defines the client interface to the application. In many cases this is the application itself. In other implementations, this could be a Terminal Server, Citrix or Browser client interface.

Application Layer The second layer is the Application Layer. It is interacted with by the user and communicates to the Communications Layer. This is where the work is defined and completed. The communications between the Application and Com are via ADO transactions.

Communications Layer The third layer is the Communications Layer. This facilitates the interaction between multiple data sources via definable and configurable protocols. In a distributed communications environment, it also allows for the distribution of data and processing objects.

DBMS / Data Storage Layer The fourth layer is the Data Base Management System (DBMS) and Data Storage Layer. This provides a platform to store, manage and manipulate the data. In all existing installation of aQDen this is facilitated by Microsoft Windows SQL Server. However, because the communications with the Communications Layer is via ODBC, this could theoretically be accomplished by any reliable DBMS.

Enhanced Routing System (EHRS) Another important concept of the aQDen architecture is the Enhanced Routing System (ERS). More on this subject will be covered in the next section.

Systems Architecture:

The technical architecture of the aQDen environment is extremely flexible. There are a number of ways this infrastructure can be implemented. In this section you will be shown several methods for implementing this technology and advantages and disadvantages will be discussed.

NOTE: aQDen has been tested and works perfectly with all of the following implementation methods!

Fat Client Implementation:

"Fat Client" is a term used to describe how much of the application is actually installed on the client PC and how much information traverses the network each time a transaction is processed. Figure #1 illustrates the network diagram for a Fat Client implementation.

Figure 1 - Fat Client Implementation

In this configuration the Client PC is installed with the Application and the Communications components of aQDen. The Server is installed with Microsoft SQL server.

Hardware Requirements:

Table 1 - Fat Client PC Configuration

Table 2 - Fat Client SQL Server Configuration

Planning – In the event that the customer chooses to implement the above network to support aQDen, the recommended SQL Server hardware requirements would be as follows:

Table 3 - Fat Client SQL Server Configuration

Not taken into consideration with this configuration are:

• Back Up / Disaster Recovery (DR) and test environments. It is highly recommended that separate test and DR systems be developed with any mission critical application of this nature.
• The network architecture of the environment where aQDen is going to be installed.

Advantages and Disadvantages:

Table 4 - Fat Client Advantages/Disadvantages

Thin Client Implementation:

The term "Thin Client" was coined to indicate an application that moved very little, if any, of the data across the network during a transaction. Figure #2 illustrates the network diagram for a Thin Client implementation.

Figure 2 - Thin Client Implementation

In this configuration the Client PC is installed only with the Terminal Server client software (Presentation Layer). The Application and the Communications Layers are installed on a Terminal Server in the Computer Room. The Microsoft SQL server still manages the DBMS / Data Storage Layer.

The Client initiates a virtual session to the Terminal Server and the application is run from there to access the data. The only network traffic that leaves the Data Center are key strokes, mouse clicks and screen shots. This is a very efficient way to view mass amounts of information without impacting the network.

The true advantages of a thin client environment can not be seen in this network diagram. Not taken into account are the number of PC’s that are installed in the client locations and the distance from the computer room to the remote clients. Also not taken into consideration is the network architecture employed in the client location.

Figure #3 illustrates how the customer network may look operating on a Thin Client Environment.

In this example, the advantages of operating in a Thin Client environment become much more apparent.

- In a Fat Client configuration with presentation, application and communication layers installed on the PC’s, an incredible amount of traffic is generated between the wiring closet and the computer room. This network connection is typically 10 or 100 Megabit speeds or in some cases Gigabit if fiber is in place.

- In a Thin Client configuration, the work is confined to the computer room.

Figure 3 - Sample Customer Implementation

Hardware Requirements:

Table 5 - Thin Client PC Configuration

Table 6 - Thin Client Terminal Server Configuration

Table 7 - Thin Client SQL Server Configuration

Planning – When planning for this type of a network installation there are two main components:

• Terminal Servers – The configuration above is ideal for all Terminal Server installations. Normally, you can expect to accommodate approximately 20 users per server. The Delta Dental of Missouri environment has six Terminal Servers installed. There are 70 users that have been divided evenly across 4 servers, making sure that each department is evenly distributed. Servers 5 and 6 serve as backups.

• SQL Server – Following is the recommended SQL Server hardware:

Table 8 - Thin Client SQL Server Configuration

Not taken into consideration with this configuration are:

• Back Up / Disaster Recovery (DR) and test environments. It is highly recommended that separate test and DR systems be developed with any mission critical application of this nature.

Advantages and Disadvantages:

Table 9 - Thin Client Advantages/Disadvantages

Implementation Options:

There are several implementation options that can improve the overall system performance or operating characteristics.

Backup Server:

Though listed here as an "option," backup servers are a necessary part of all production environments. Microsoft SQL Server (as well as most other systems) provides the user with multiple methods for replicating data, in a near real-time fashion, to other servers. The trickier part of the equation is retrieving the data without impacting the operational availability of the production data server.

Network Diagram – The network implementation of this is little more than installing an additional instance of Microsoft SQL Server on another server in your network. Figure #4 illustrates this implementation.

Figure 4 - Backup Server Configuration

Again, one of the most important keys to success with this implementation is true 24 x 7 x 365 availability of the data. This has to be true for IVR and WEB systems at the very least. Following is a discussion on how this was accomplished within the Delta Dental of Missouri environment.

Figure #5 illustrates the data flow for the backup of production data. This system accomplishes two objectives:

• Maintain 24 x 7 x 365 access to the production data set
• Make sure the data is backed up and ready for recovery in the shortest amount of time.

Figure 5 - Data Backup Flow Diagram

1. Production Database – This is the primary repository for the production data. This is where all clients and auxiliary systems (IVR, WEB, etc) deposit and retrieve data from.

2. Backup of Production Data – On a nightly basis, SQL scripts are executed via the internal batch scheduler that create backup copies of the production data and initialize the transaction logs. This entire process is done without taking the database off-line and completed in less than one hour.

3. Copy of Production Backup – Once the backup of the production database is completed, other scripts are kicked off that perform a simple copy of the BKP files from the production server to the backup server.

4. Restore of Production Backup Copy – Upon completion of the copy of the file, the file is restored to the backup server. When completed, the backup system will be a complete copy of the production system.

5. Transaction Logs from Production Server – These are the logs that contain all the transactions that occurred on the database since they were last initialized. These logs are transferred to the backup server on an hourly basis. In the event of an emergency, these transactions could be applied to the Backup Server and no more than one hour of data will be lost.

6. Send Production Backup file to Tape – At the same time the Backup server is restoring the files in step 4 (above), the production BKP files are being backed up to tape. These tapes are then transferred off-site everyday for added protection.

Hardware Requirements:

While the drive space must be about the same between the production and backup servers, the rest of the configuration does not. The following table highlights the requirements of a backup server installed in the customer environment.

Table 10 - Backup SQL Server Configuration

Test and Development Systems:

In addition to providing a backup environment for disaster recovery purposes, Delta Dental of Missouri has taken this one step further to provide a complete Test environment. This Test system is used for release testing, aQDen development and demonstrations. The Test environment is updated in exactly the same way the Backup server is updated except it is restored from the Backup server and no log files are maintained. Figure #6 outlines the Test Environment Configuration.

Figure 6 - Test Environment Configuration

There are two significant advantages to this methodology:

• We test our ability to restore the production data on a daily basis
• We maintain accurate data in our test environment that closely represents production. The hardware requirements of the Test environment are roughly the same as the Backup server.

Advantages and Disadvantages:

Table 11 – Backup Server Advantages/Disadvantages

Clustered Servers:

The implementation of Microsoft clustering is a strategic decision that must be made based on business requirements. Clustering refers to linking individual servers physically and programmatically, and coordinating communication between them to perform common tasks. Should any one server stop functioning, a process called "failover" automatically shifts its workload to another server to provide continuous service. In addition to "failover", some forms of clustering also employ "load balancing", which enables the computational workload to be distributed across a network of linked computers.

Combined with advanced symmetrical multiprocessing (SMP) and large memory support in both Windows 2000 Advanced Server and Datacenter Server operating systems, Windows clustering technologies enable organizations to ensure the availability of critical applications while being able to scale those applications both up and out to meet increased demand.

Figure #7 illustrates the cluster server network configuration.

Figure 7 - Cluster Server Configuration

SAN Solutions:

Another technology that adds a significant amount of flexibility and redundancy is Storage Area Networks (SAN). SAN’s provide large amounts of shared drive space in a highly redundant and safe environment. From a Disaster Recovery perspective, most SAN systems also offer the ability to replicate the stored data over long distances to other SAN systems.

Figure 8 - San Configuration