Architecture 

See the Server Component page for instructions on how to install.

The architecture described below is functional, but not currently recommended for multiple locations.  It's too slow.  Instead, see the Multiple Locations page for an overview of current options.  This architecture is, however, useful if you must have increased security at a single location.

This diagram attempts to explain the goals that the 3-Tier Architecture was initially trying to achieve.  This is in contrast to the standard strategy of two tiers: the Windows application, and the database.

Overview

The large arrows represent chatty connections, while the single thin arrow represents the slow connection for which everything else is being optimized. Very few calls will be made across this connection. The goal is to have no more than one call to the server for each 'page' of display on the screen. This single call will always return a single dataset (group of tables) which is as small as possible. Eliminating multiple calls reduces latency (roundtrip time) issues, such as when connecting across a satellite connection. And keeping the result set small helps the program remain responsive even when the connection is slow, such as a dial-up connection.

Open Dental will always be initially installed with the business layer on the client. This will work fine for small offices. But for larger offices, the business layer can also be installed on the server to cut down on network traffic. OpenDentServer.exe will also handle all authentication, isolating the database from regular users, and providing the level of security required by enterprises. Overall, the new business layer will eventually result in enhanced speed (including reduced startup time), security, database integrity, reusability, and scalability.

Although all of the components in the diagram are complete and functional as of version 4.5, there is still a lot of optimization to be done to reduce traffic over the slow connection. So there is currently no performance advantage to be gained by using the server components, although there are advantages from a security standpoint.

OpenDentalServer.exe will probably be able to run on Mono instead of the Microsoft dotNet framework. This will allow it to run on Linux or Windows servers. As a web application is eventually built, the long-term goal is to connect it to the OpenDentServer instead of directly to the database. It would communicate with web services. But until the server program is designed for external interfaces, any web app would most likely be built by connecting directly to the database. This should only be considered a temporary solution, and the goal should always be to use the business layer in the future.

Explanation of the various components in the diagram above

OpenDental.exe:

Data Interface: This is what the main program interacts with for any data needs. The data interface is responsible for deciding where to obtain the data and for catching exceptions thrown by OpenDentBusiness.dll and by the Remoting interface.

Remoting Interface: Only used if the OpenDentServer is being used. Although it is not shown above, there can be multiple clients all connecting to the single OpenDentServer.exe. The server program can also handle multiple clients on each of the workstations. This happens when the user opens multiple copies of Open Dental on one computer or when terminal services are being used.

OpenDentBusiness.dll: All business logic and data access is being moved to this layer. All that will be left in the main program will be user interface logic. Every class that needs direct access to the database for any reason belongs here. This is where all the INSERT, DELETE, SELECT, and UPDATE commands are for each table in the database. This is also where global variables store some of the data that is not changed very often. This includes such things as Providers, Definitions, Operatories, Fees, etc. The business layer also contains the functions that extract the data from these global variables as needed for the main program. For instance, if we need to know the name of an operatory, we would ask the business layer. If this layer does not have a connection to the database, such as on the client of an enterprise computer, then it still functions exactly the same, as a data storage layer. But in that case, the Data Interface is responsible for keeping the global variables updated by using the Remoting Interface. The classes are all organized by database table. So for each table, like patient, there would be one Data Interface class (Patients), and one Business class (PatientB). The Patient class, which defines the actual columns in the table is not shown in the above diagram. It is also in OpenDentBusiness.dll, so that both the server and the workstations have access to the same definitions.

Remoting Protocol

This section is very technical and is only intended for programmers.

We made the decision to not use dot Net remoting because we feel it's too complicated for other programmers to implement. We wanted something a little bit simpler and lower level. So, instead, commands are sent from the client to the server as DataTransferObjects. See below for more details. The reply from the server is either a DataSet (group of tables), an acknowledgement, or an exception.

Protocol
1. There are two options for transport protocol, either http or tcp. Only tcp is initially implemented, but http is discussed here as well since it will go through firewalls easier.
2. The format at first is XML. Later, we might compress the text messages on tcp connections for speed.

Encryption
1. The current version does not encrypt the data. In the LAN setting for which this version is targeted, encryption is not necessary.
2. Later, encryption will be added as an option. This is especially important if using http because the data must travel over the internet.
3. SSL will be used to encrypt the data. So this would mean using https instead of http, or using an ssl stream over any tcp connection.
4. An SSL connection always requires the server to have an X509 certificate installed. One can be created quite easily. Clients will not be required to supply certificates.
5. The client initiates the SSL authentication and the handshake ensues. If successful, then a channel is established for a certain period of time.

Authentication
1. The client attempts to log in using an Open Dental database/username/password(hash) combination.
2. If login fails, then the connection is closed.
3. If login succeeds, then the client may start sending requests to the server as needed.

Sharing Data Types
1. There is an Open Dental type that corresponds to every table in the database. 'Patient' for example.
2. Each type has fields that correspond to the columns in that table. 'LName' for example.
3. OpenDentBusiness.dll contains the definitions for all of these types.
4. OpenDentBusiness.dll should be on the client as well as on the server, providing a common shared reference.

Client messages
1. Instead of using an RPC, the method and parameters are encapsulated into a DataTransferObject (DTO).
2. There are hundreds of DTO types, one for each method that the business layer is designed to recognize. {the previous statement is outdated. We have switched to just a few reusable DTO types}.
3. The DTO types are all defined in OpenDentBusiness.dll so that everyone has access to the definitions.
4. When ready to send, the DataTransferObject gets serialized to XML for transport.
5. There are two general types of commands: requests for data, and sending data to be inserted or updated to the database. DTOs are used in both cases.
6. Requests for data typically include a few simple parameters and return a complex dataset.
7. Sending data is typically done by creating one or more objects (such as 'patient') and including them as parameters in the DTO.
8. The parameters are allowed to be very complex, sometimes involving an entire hierarchy of objects or an array of objects.
9. So a complex object gets passed to the OpenDentServer as a group, and the server loops through repeated calls to the database to persist the object.

Server responses
1. For queries that expect data, then the server usually replies with a dataset (group of tables).
2. The DataSet might be as small as one table with a single cell, or one empty table.
3. When a command query is used, the return object is typically be a DtoServerAck object, which simply indicates that the command executed successfully.
4. The DtoServerAck object also passes back the insert ID of a new row for an insert command.
5. The server might instead reply with an exception which contains an error message that gets presented to the user.
6. Exceptions are encapsulated into DtoException objects in order to send them back to the client.

Using the DataSet
1. It is up to the client to convert the resulting dataset into whatever objects it needs.
2. Frequently, tables in the dataset do not correspond to the basic types such as 'Patient'. Instead, the dataset is optimized for display purposes. For example, it might include an 'Age' column rather than a 'Birthdate'. Or many columns might be missing.
3. So the client typically displays the dataset tables without much processing, probably just filtering out rows it's not interested in.
4. A complete record, 'Patient' for example, is only sent when the client needs access to a full object, such as for editing.
5. Automated documentation will be added to list out the tables that will be in each returned set as well as the column names and types in each table.

Custom Queries
1. The user might want to assemble their own queries for reporting purposes.
2. Open Dental might also want to create dynamic queries to gather data from the database.
3. There is a DTO designed specifically to pass this type of query to the database and return a dataset with a single table.
4. There is only one parameter in the DTO, the query itself.
5. To avoid "injection attacks", all queries coming through this particular DTO use a separate connection to the database.
6. This connection has very limited privileges, just SELECT and CREATE TEMPORARY TABLES, and only for the current database.
7. So Open Dental does not have to inspect the SQL or try to parse it for allowable syntax. MySQL handles the security limits.