Structure of Interface

The NT version of the ZIY started life as a multithreaded, event driven, asynchronous program with a graphical user interface (GUI). This event driven design has worked very well. It also matches well the event driven design of the ZY. Consequently, the client/server version of the ZIY is also an asynchronous event driven program, and the RPC interface reflects this. The ZIY RPC interface (thereafter referred to as the request server) is used to place action requests to the ZIY. The ZIY then performs the action and calls an RPC callback server on the ZIY client upon completion of the action requested (See Figure 2.1). The ZIY interface therefore really consists of two interfaces, one provided by the ZIY, and one that must be supplied by the client to the ZIY [2]. The ZIY is made aware of this client supplied interface when the client registers itself with the ZIY by using a synchronous RPC call that the ZIY service provides, ZIYREGISTER_CALLBACK. The highlights of this interface are as follows:

• ZIY Client must register a callback server with the ZIY Service. For every function that the ZIY provides through its RPC request server, the ZIY Client must provide an analog in its RPC callback server.
• Calls to the request server return immediately. The request server will place the request in a queue, and will acknowledge the request with data providing the status of the pending request (Success/failure flag, transaction ID of request, time stamp of time request was received, any error messages if the request failed.)
• A new request can be placed as soon as the previous request is acknowledged. Thus many requests can be queued up. The ZIY interface is slated to provide a mechanism to selectively remove any requests from the queue (provided they have not yet been processed.)
• All requests are tagged by a Transaction ID (TID), that will accompany the request as it travels through the system (Not yet fully implemented.)
• The results of the request are returned to the ZIY Client as soon as they are available, through the client's callback server. The time that the request was actually executed will be provided as a time stamp in the result data structure.

Figure 2.1: Organization of Metrology Software