The Open Data Services API defines a small, powerful group of events within Open Data Services. Each event is initiated by a request from a server or a client in the SQL Server environment. Using the Open Data Services API, you supply a well-defined routine, called an event handler, for each event type. An Open Data Services server application, then, consists primarily of a set of event handlers that respond to events triggered by incoming requests. In a sense, the ODS Library "runs" the application by calling its event handlers at appropriate times. This style of programming is similar to that used in writing an application for a graphical user interface (GUI) such as the Microsoft Windows operating system. For example, Windows-based applications respond to events such as mouse clicks or key presses. Open Data Services server applications respond to events such as user login requests. In both cases, the application is responsible for taking appropriate actions when an event occurs.
Open Data Services server applications will generally be concerned with three major events:
Open Data Services also generates events based on certain client activities and application activities, allowing an Open Data Services server application to respond to changes to the status of the client connection or to changes to the status of the Open Data Services server application.
Each event causes Open Data Services to issue a call to the corresponding event handler, if one is provided. When writing code for event handlers, think of events as arriving one at a time, each complete with information that identifies the client and tells what the client is requesting.
You can write code for each Open Data Services event handler as if it deals with a single event in isolation, without worrying about blocking other clients by taking too long with a particular request. However, your event-handler code does need to protect global resources. For example, if your application uses a counter that applies to the server as a whole, you should ensure that the counter cannot be modified simultaneously by two separate threads.
In practice, client requests can arrive simultaneously. To deal with simultaneous client requests, the ODS Library allocates a separate area in memory and creates a separate SRV_PROC structure to contain connection information for each new client connection.
In an application servicing many clients, multiple instances of a single event handler can execute in response to multiple client requests through the use of separate processing threads. This multithreaded operation enables Open Data Services server applications to maintain a high level of performance and availability. It also enables Open Data Services server applications to transparently use multiple processors under Windows NT, since the operating system can schedule any thread on any available processor. Developing a server application that handles multiple clients is simple because Open Data Services itself handles all the complexity.
One of the sample applications provided with Open Data Services illustrates event handlers for all event types. The gateway sample application implements a pass-through gateway from one SQL Server to another database server (in this case, another SQL Server). The sample application implements a language event handler that issues a DB-Library dbsqlexec call against the back-end SQL Server, passing on the same command that the client sent to the gateway. Many potential Open Data Services server applications involve simple modifications of this sample gateway.