- Fail-over and Fault Tolerance/Load balancing
- HTTP Tunneling/Port 80 Cloaking transparent fireall pass-through
- dbORulesTable - The dbOvernet Business Rules Table
- Methods - Method population at design and runtime.
- Method Wizard - Middle tier Method Wizard.
- dbODataLink - ActiveX version of our client dataset.
- User access rights - Middle tier control over users.
- Fail-over and Fault Tolerance/Load balancing dbOvernet is first again, with this important feature as an option.
dbOvernet provides a model that ensures secure, centralized log-in and request routing through a designated router to various cluster members, and handles server failure, with optional preemptive allocation, and client-side rerouting to second, third and beyond secondary routers, in the event of failure of the main router. This feature ensures availability, and provides reliability and scalability.
Load balancing
Below, the Distributing (Hub) server is the router. The cluster in this example is comprised of 6 production servers (dbOvernet Application Server executables), but there is no theoretical limit. The cluster members (available production servers) can be located anywhere in the world).
As the router, the Hub server is the entry point for all requests from all clients. You can set one, two or all cluster members active, you can add new servers and take servers offline in real time. All accesses run through pooled threads, so there are no delays.
Fail-over
On login, each client application is provided with a list of available Hub servers running at different addresses (usually on different physical computers). The first of those is usually the Primary Hub server. Any request to the Primary Hub server that fails will result in a secondary request to the next Hub server on the list (one of the Secondary Hub servers).
Typically, only 2 Hub servers are provided, a primary and secondary, but there's no theoretical limit. In practice, the Secondary Hub server(s) are often located on the same physical computers hosting production servers, since they are usually needed temporarily.
The secondary Hub servers also act to take care of temporary overloads of the Primary Hub server, should that occur.
- HTTP tunneling another dbOvernet first. Now applications can operate through a Port 80 restricted firewall to external Application Servers as easily as they can with no firewall in place.
Read more about it - click here.
- dbORulesTable The dbOvernet Business Rules Table - These are middle tier tables that provide the developer with the ability to define record level Constraints, Custom Constraints, Validation rules - anything at all that can be done in a TTable/TQuery. However, since it's placed in the middle tier, it doesn't require client-side updating when you change any of the rules.
The dbORulesTable component is used in conjunction with parameter-based requests sent from client applications using our ServerSQL functionality that produces the SQL (or equivalent) expression or action in the middle tier instead of at the client. Currently, only BDE-based dbO App Servers support the dbORulesTable.
For instance, the middle tier might have a dbORulesTable named "CUSTOMER" with a Validation Rule that ensures CustomerID has some particular pattern, or that it doesn't already exist on the server. Or you might add a Constraint that ensures that ensures the CustomerID pattern-matches the LastName.
Above, the DataModule DM1 resides in the middle tier (as part of the server-side dbO Application Server executable) and holds two dbORulesTables. The Field List for Customers is displayed, and the Field BalanceOwing is selected. The OnValidate event of BalanceOwing is coded as shown.
At runtime, the client sends an update/insert record request to the middle tier in the form of a set of parameters rather than a fully-qualified SQL expression. The middle tier invokes dbOvernet ServerObject, ExecSQL, that extracts the parameters and checks them to see if the current record request is for a table referenced in the DataModule as a dbORulesTable. If it is, the update is processed through that table by placing the appropriate parameters in the applicable fields of the TdbORulesTable, then activating that table. Errors are captured and dispatched to the client.
Anything is possible. When a record is created or modified by the client, it passes through the applicable dbORulesTable where the constraints and rules are applied. Errors are then returned to the client for correction, before the record is approved at the client.
- Methods Method population at design and runtime. This works almost identically to our StoredProc property. Methods are ServerObjects, identified by a method name and given parameters that can be populated at design and runtime.
Above, the MethodProc property has been selected, and a list of available methods has been retrieved from the middle tier and populated in the dialog. STOREFILE has been chosen and its parameters are displayed.
One of the nice features of dbO's method handling is that it is all done through the ExecBuffer component, a sub-component of the TdbOClientDataset that doesn't affect existing recordsets that may be under edit or view in the application.
Code to handle method parameter population and execution is like this:
The above example retrieves the metadata information for the customer table.
- Method Wizard Middle tier Method Wizard. To simplify the task of creating methods, we have designed a Wizard that is called from the New|New Items dialog. The Wizard walks you through the process of naming the method and specifying its parameters, then automatically creates a new unit with all the applicable information completed, including a skeleton of the method's Execute code.
You complete the code to meet your needs and register the method with the applicable dbOvernet Application Server. The method then becomes available to client applications as shown above in the topic, Methods.
- dbODataLink ActiveX version of our client dataset. dbODataLink empowers middle tier/server functionality for any product that uses ActiveX, including tools like Visual Basic, Excel and other Office2000 products, as well as many other development tools and productivity products.
dbODataLink can be used in these environments and others, like VBA, ASP and XML, to deliver distributed solutions controllable through a middle layer. It can be used in virtually any environment as a component to interface data sources to destinations.
- User access rights Middle tier control over users. In addition to log on and user ID validation, dbOvernet provides a complete solution for monitoring and restricting user access based on specific or group IP addresses.
Above are a couple of examples. One completely restricts IP 182.300.15.12 from access. The other limits 165.32.14.12's access to Read Only status.
Global, group and specific restrictions can be easily implemented.