Most data-centric applications access a database directly using a client-server (2-tier) model (see figure 1). Connecting directly to the database provides sufficient performance when the number of clients is limited and those clients can access the database server from the local network. However, when the number of clients within the application increases or the clients require access to the data from outside the local network, a problem surfaces in finding a better method of connecting to the data without rewriting the application.

Figure 1: Basic client-server architecture.


The StrataFrame Enterprise Server provides that method of connection to the data that can be easily implemented in an existing StrataFrame application without code changes, provides remote access to the database through HTTP, and increases the scalability of the application by reducing the load on the database server.

The Enterprise Server is a web site hosted within Microsoft® IIS that can be consumed as a data source by a StrataFrame application (see figure 2). Clients connect to the Enterprise Server using HTTP and the Enterprise Server proxies their database requests to the database server. The Enterprise Server allows clients to access the data within the database from a remote network through the use of the HTTP protocol, and uses encryption and compression to improve the security and performance to remote clients.

Figure 2: 3-tier architecture with the Enterprise Server.

Connection Pooling

The Enterprise Server (or Enterprise Servers in a server farm) provide a centralized location to pool connections to the database server. One of the larger drains on database server resources is connection maintenance. Even with .NET connection pooling, if clients are allowed to connect directly to the database, each client will open several connections and every connection requires significant resources on the database server to maintain (see figure 3).

Figure 3: Connections when connection pooling is only enabled within each client.


When the Enterprise Server is incorporated, it becomes the only "client" of the database server (the only computer that opens connections to the database) (see figure 4). This allows the ES to pool the connections from all of the client computers and greatly reduces the needed database server resources. The database server can spend more of its resources running queries and serving data rather than maintaining client connections.

Figure 4: Connections when clients connect to the enterprise server and connection pooling is centralized.


This functionality is the largest contributor to the increased application scalability that is gained from using the Enterprise Server. Additional Enterprise Servers can be added to handle client connections without greatly increasing the number of connections to the database.

Encryption

The Enterprise Server uses the symmetric 3DES encryption algorithm to encrypt all data that is transferred between the client computers and the Enterprise Server. 3DES is a universally accepted method for encrypting mission-critical data and is used commonly by secure VPN connections.

Compression

The Enterprise Server can optionally compress all data sent between the Enterprise Server and the client computers. Compression can reduce the amount of traffic between the client computers and the Enterprise Server by as much as 80%. The CPU resource cost of compressing the data is marginal, and when a client connects to the Enterprise Server using a low-bandwidth/high-latency connection the performance is greatly improved by compressing the communications.

Interchangeable

A StrataFrame application uses a transparent data source class for accessing data. The same methodology is used for the Enterprise Server; an Enterprise Server specific data source replaces the SQL Server (or other database) specific data source within the client application (see figure 5). These data sources are transparent to the upper levels of the application, and can be hot-swapped at runtime.

Figure 5: The SQL data source is replaced with an Enterprise data source to allow the client to connect to the Enterprise Server.


This functionality allows an application to be written for use with both the Enterprise Server and direct database connections. When the application is run from the local network, directly connecting to the database may be more efficient; however, when the application is run from a remote network or over the Internet, it can use the Enterprise Server to access the same database.

In fact, when testing the Enterprise Server, no new unit tests were developed; the same test used to test SQL Server connectivity were used to test the Enterprise Server connectivity by simply changing the data source.

Server farm support

The Enterprise Server can be deployed in both single-server and multi-server environments. A multi-server environment increases the scalability of an application by distributing the load on the Enterprise Server across multiple computers. Any method of load balancing between the Enterprise Servers can be used such as Microsoft® Network Load Balancing (NLB) or a hardware round-robin request distribution system.

Full transaction support

Transactions are fully functional when using an Enterprise Server to provide access to the database, even when using several Enterprise Servers in a multi-server environment. Each of the Enterprise Servers in a farm is aware of the other servers. A transaction is maintained by a single Enterprise Server, and if an Enterprise Server receives a transaction request for a transaction on another Enterprise Server, it transparently forwards the request to the proper server for processing (see figures 6-8).

Figure 6: The client sends a Transaction Begin request to the Enterprise Servers which is sent to ES #2 by the load balancer.


Figure 7: The client sends a Save Record on Transaction request to the Enterprise Servers which is sent to ES #1 by the load balancer. ES #1 does not own the transaction, so the request is forwarded to ES #2 for the record to be saved on the transaction.


Figure 8: The client sends a Transaction Commit request to the Enterprise Servers which is sent to ES #3 by the load balancer. ES #3 does not own the transaction, so the request is forwarded to ES #2 to commit the transaction.

Small client-side code change (1-6 lines)

Any existing StrataFrame application can enjoy the use of the Enterprise Server by simply changing the data source (1-6 lines of code) within the client application.

Install provided for Enterprise Server web site

A separate installation can be downloaded to install the Enterprise Server web site within IIS. The installation allows the Enterprise Server to be quickly and efficiently deployed and optimally configured on the server computer.

Existing applications can be easily adapted to use the ES

Since the Enterprise Server’s client-side data source is interchangeable with all other StrataFrame data sources, an existing application written to connect directly to the database server can be adapted to use the Enterprise Server within minutes using the 1-6 lines of code required to change the data source.

The Enterprise Server does not use .NET serialization, .NET remoting, or web services. These 3 technologies are designed to be highly configurable, flexible, and interoperable; however, the flexibility gained by using one or more of these technologies comes with a significant performance penalty over using a custom solution. Developing the Enterprise Server would have been easier if we had used one or more of these technologies, but the increased development time was worth the performance gain in the end.

ES vs. .NET Serialization

By designing the Enterprise Server to work solely with a StrataFrame application, we were able to streamline the network communications. Where a serialized .NET object will contain a significant amount of meta-data used by the deserializer to reconstruct the object graph, the Enterprise Server's descriptor objects contain a 1-byte identifier that is used to instruct the remote endpoint how to reconstruct the object from the network stream. By not using .NET serialization, the required network traffic can be reduced by as much as 40%.

ES vs. .NET Remoting

The Enterprise Server uses a completely disconnected model for data access. After a client requests data from the server and that data is retrieved and returned, the connection between the client and server can be disconnected with no adverse effects. When using .NET remoting, the remoted object exists on the server application and an HTTP handle is used by the client to access the remote object. This requires a persistent connection between the server application and the client application since any and every access to a method or property of the remoted object requires a separate HTTP call from the client to the server.

Using .NET remoting over limited bandwidth or unstable network connections can cause an application to become unstable; if the connection drops, all remoted objects are lost. By not using .NET remoting, the Enterprise Server gains a great deal of stability when working with clients that have limited bandwidth or unstable network connectivity since a persistent connection is not required.

ES vs. Web Services

Web services are designed to be highly interoperable so they can be consumed by numerous disparate systems. As with .NET serialization, every web service request and response object contains a great deal of meta-data, generally in the format of SOAP formatted XML tags. These tags can more than double the size of both the request and the response objects. With the Enterprise Server, this additional XML is not necessary since both endpoints know how to encode and decode the requests and responses.

HTTP vs. HTTPS (SSL)

The Enterprise Server is designed to work with the HTTP protocol. While the connection between the Enterprise Server and the client-side data source can be configured to use HTTPS, it runs more efficiently and just as securely on HTTP.

The Enterprise Server uses the symmetric 3DES encryption algorithm to encrypt all traffic between itself and the client-side data source. Symmetric encryption algorithms have much better encryption performance than asymmetric algorithms such as SSL, which is why symmetric algorithms such as 3DES and AES are used by VPNs. The Enterprise Server gains more throughput by using 3DES/HTTP over SSL/HTTPS.

Symmetric algorithms require a pre-shared key that must be configured manually on both sides of the connection. This increases security by creating a "password" system that is needed to access the Enterprise Server. Each data source handled by the Enterprise Server can have its own encryption key.

Smart clients requiring remote access

In this age of mobile computing, quite often, systems will be designed to be used from both local and remote networks. Using the Enterprise Server, a StrataFrame application installed on a laptop can access data when it is connected to the local network and access the same data from a remote network through the Internet without requiring a recompile but rather a simple configuration change.

The Enterprise Server allows remote access to data using the HTTP protocol. It also provides excellent security for the data while increasing the performance for remotely connected clients. The Enterprise Server can be installed on a remotely accessible web server and exposed to the Internet rather than requiring that your database server be exposed to the Internet (see figure 9).

Figure 9: Clients within the office directly connect to the database server while clients outside of the office connect to the database over the Internet through the Enterprise Server.

Web servers requiring middle tier

The Enterprise Server can be used to provide a secure gateway to the database server for front-end web servers. All database access by the web servers would be routed through the Enterprise Server rather than directly to the database server. Access to the database server could then be restricted to only the Enterprise Server to increase security (see figure 10).

Figure 10: Both web servers connect to the database through the Enterprise Server. Only the Enterprise Server is allowed to communicate with the database through the firewall.

Increasing application scalability

The Enterprise Server can be deployed in a multi-server environment to increase the scalability of an application with a significant number of clients. The hardware resources needed by the database server would be greatly reduced as the number of database connections would be reduced to only the number needed by the Enterprise Servers (see figure 11).

Figure 11: A very large number of clients can use the same database server by allowing the Enterprise Server farm to reduce the load on the database server.