2.2 API and SPI Summary

Sections 5 through 7 of this document present the interfaces that allow a financial application to communicate in a standard fashion with financial services and devices. The functions are at a sufficiently high level to allow for seamless redirection to other parts of the underlying operating system. A printer, for example, might rely on a set of services provided by the operating system, but in order to handle the unique characteristics of a financial printer and application, the service provider would preprocess the command, then redirect the derived commands to the operating system's printing services. In other implementations, the printer might be supported entirely by WOSA/XFS service mechanisms, and not use the operating system printing services in any way.

The API is structured as sets of:

· Basic functions, such as StartUp/CleanUp, Open/Close, Lock/Unlock, and Execute, that are common to all the WOSA Extensions for Financial Services device/service classes,

· Administration functions, such as device initialization, reset, suspend or resume, used for managing devices and services, and

· Specific commands, used to request information about a service/device, and to initiate device/service-specific functions; these are sent to devices and services as parameters of the GetInfo and Execute basic functions. These service-specific commands are specified in a set of separate specifications, one for each service class.

To the maximum extent possible, the syntax of specific commands that are used with multiple device/service classes is kept consistent across all devices. A primary objective is to standardize function codes and structures for the widest possible variety of devices.

The SPI is kept as similar as possible to the API. Some commands are processed exclusively by the XFS Manager, and so are not in the SPI, and there are minor differences in the specific parameters passed at the two interface levels.

A typical scenario showing the usage of the APIs is shown below. This example illustrates the functions used to print a form.

· StartUp (connects the application to the XFS Manager, including version negotiation)

· Open (establishes a session between the application and the service provider)

· Register (specifies the messages that the application should receive from the service provider)

· Lock (obtains exclusive access to the service by the application)

• multiple Execute functions, passing one or more specific commands:

  ú Print_Form

  ú etc.

· Unlock (releases exclusive access to the service by the application)

· Deregister (specifies that the application should no longer receive messages from the service provider)

· Close (ends the session between the application and the service provider)

· CleanUp (disconnects the application from the XFS Manager)

Note that within a session (defined by Open and Close), an application may at any time change the classes of messages it wishes to receive from the service provider (using Register), and may either Lock the service only for specified periods (typically for each transaction), or for the entire session. Also, note that several of the commands are optional, depending on how the device is being managed and shared (i.e., Lock/Unlock, Register/Deregister).