The purpose of every database system is to gather, retain, and distribute information about something tangible. The server presides over persistent data managed by other DBMSs and over its own metadata. The collection of data and metadata managed by a server constitutes a database. Application programs manipulate the database by issuing stored procedure calls and database requests expressed in the SQL language.
iWay Software is a client/server system. In this system, a client process establishes a session and submits database requests to an independent server process. For every request it receives, the server produces a response, either a diagnostic message or a stream of tabular results.
The data reference model consists of two major components: an application program, which issues method calls, and a DBMS, which responds to the method calls.
The DBMS consists of a database processor and persistent data. The client/server aspect of the model is embedded within the database processor, which itself contains a client and a server component. The client and server components communicate by means of a protocol designed to convey SQL requests in one direction and result sets in the other direction.
The client side of the database processor is the only system component that interacts directly with application programs. At this level, communication is accomplished by means of method calls. The DBMS interface (API) fields method calls and invokes a Client Services module to carry them out. The API ensures that every method call it receives makes sense. That is, it imposes a set of usage rules on the application program. It passes valid requests to the Client Services module. The Client Services module satisfies some requests locally and passes others to the server for action. Whenever the Client Services module communicates with a server, it does so through a database protocol handler. This is known as the EDAP Protocol (or EDAP). The EDA Protocol runs on both the client and the server sites as a communications layer
On the server side of the client/server link, where all database manipulation takes place, the system breaks down into two major sub-components: the EDAP Server module and an SQL Services module. The EDAP Server component extracts requests from the incoming stream and encodes outgoing results. The SQL Services module executes SQL requests and stored procedure calls.
The following figure, the Data Reference Model, depicts the combined data reference model.
The data reference model reveals only those aspects of the system that actually affect program development. It is the developer's responsibility to supply the application program component of the model. The API insulates the application program from the implementation details of the database processor. To create a viable application program, the developer must master the API call-level interface. However, the API encapsulates only part of the data reference model-while it provides the visible means for conveying request strings to servers, it remains neutral regarding what the strings actually contain. In principle, the call-level interface can pass any string to the server. Its function is not to analyze requests, but to convey them to the SQL Services module.
The SQL Services module is a database engine designed to process statements expressed in dynamic SQL. Like most SQL engines, it accepts well-formed SQL statements, and nothing else. When invoked, the engine parses an SQL string, produces a plan for carrying out the request, and generates a self-descriptive result stream. Result sets are the basic building blocks of result streams. For example, an isolated SQL query produces exactly one result set, whereas stored procedure calls and multi-statement requests generate any number of result sets.
To summarize, the application program-with the help of the API, the Client Services module, the EDAP Client, and the EDAP Server-conveys well-formed requests to the SQL Services module. The SQL Services module processes the requests it receives and returns self-descriptive result streams to the client. On the client side, the application program, again with the help of the API, scans result streams one result set at a time and individual result sets one row at a time. The logic required to develop an application program in this environment is straightforward, and the initialization steps are generally the same from one application to the next. The methods required to initiate requests and to process result sets can be utilized across multiple applications.
Note: A protocol is a set of rules governing the exchange of information between two autonomous processes. EDAP is an internal standard defined in terms of a state machine and a set of actions that the EDAP Client and Server perform cooperatively when a state transition takes place. EDAP is an internal reference model standard that has no direct bearing on application development but is outwardly noticeable as the ODIN communication protocol and the configuration file (odin.cfg).
The protocol is also sometimes known by the term EDACS3, which is a variable used to specify a specific odin.cfg file rather than using the default.
| iWay Software |