Multi-tier

A multi-tier architecture includes at least 3 distinct layers: client, middle and server. The critical element in this architecture is the middle tier - the middle layer, where business and validation rules, pre-processing functions, remote procedure calls, callback and other actions take place.

The middle tier is where the decisions are made. Without a distinct middle layer (typically identified by an Application Server, Object Request Broker and Server Objects), a product simply is not multi-tier.

CLIENT: The client application contains the logic to both provide the user interface (typically through edit controls, data grids and so on) and to assemble and send requests for data, updates, inserts, etc. to the middle tier. MIDDLE TIER: The middle tier is a pre-staging area where requests are evaluated and actioned and where results are returned to the client. Since the middle tier is a separate layer in multi-tier, the developer can add functions and procedures that take any course. For instance, requests can be evaluated for authenticity and returned if invalid, or they can be re-routed or modified according to user rights. The middle layer can contain logic to access non-database sources, or to provide file directory structure information. It can use functions like our built-in RPC (remote procedure calls) to place processing in the middle layer thus centralizing business rules and removing burden from the database servers. SERVER: The server provides the connectivity to data sources, typically databases. Because of the open architecture, dbOvernet supports virtually all database engines. Where the servers we provide are not enough, developers can quickly develop their own server-side solutions, adding connectivity to any other database engines.

The ServerObject Class

A critical component in the middle tier is the ServerObject class. This is a base class from which developers derive specific classes to carry out specific functions. dbOvernet comes with a dozen or more standard ServerObjects to carry out functions like SQL SELECT, user authentication, file transfer, SQL INSERT,UPDATE,DELETE, thread management, RPC and metadata retrieval.

You can easily and quickly add more.

The class is triggered by a function code sent by the client. The function code and parameters get passed into the middle layer where the Application Server and Object Request Broker components act together to instantiate and execute an instance of the ServerObject class designated by the function code.

To add new functions, you create and register a new ServerObject, assign a function code to it, and simply call the function code from the client. You can also pass parameters from the client at the same time. That's all there is to it.

With ServerObjects, developers can add any code to do any function.

As you can see in the diagram, data connections are just one of many functions that can be executed through the ServerObject class.

With dbOvernet, we provide you with dozens of real-world examples of the middle layer in action. We also provide a complete, open remote procedure model to allow you to enable any business rules, from pre-processing rules like OnBeforePost to post-processing functions like record refresh and autoincrement callback.

Since the dbOvernet architecture is completely open, you never have to wait for us to provide functionality through version releases. In fact, some of our examples, ServerObjects and source code include methods and functions developed by our customers and shared with all dbOvernet developers.