3.2.1 Service Provider Functionality

The primary functions of WOSA/XFS service providers, working in conjunction with their respective services and/or device drivers, are as follows. Note that how these functions are implemented is left to the service provider developer.

• Route the requests to the device or service, which may be on a remote workstation.
  Service providers may communicate with remote services in a variety of ways, such as NetBIOS, named pipes, RPC (Remote Procedure Calls), Windows Sockets, proprietary network programming interfaces, etc.

• Translate the generic requests to resource specific commands.
  Note that this involves translation not just to service-specific commands, but to the commands native to the resource being used. For example, the commands would not be translated to "Receipt Printer Service" commands, but to "Brand X, Model Y Receipt Printer" commands. For example, a driver may implement device-specific translation tables or processes itself, or utilize standard operating system device interfaces (such as the Windows GDI), if they exist for the particular peripheral.

• Arbitrate access to the resource by multiple applications.
  Note that when a physical device includes multiple peripherals (for example, a receipt and journal printer in a single unit), this may also include arbitration of the sub-devices.

• Manage the interface to the resource.
  When physical devices are being controlled, this includes managing the hardware interface to the device. For example, the service providers may use standard operating system device drivers, vendor-written proprietary device drivers, etc.

• Manage the asynchronous nature of the services in a consistent manner with respect to the applications.
  The asynchronous nature of the SPI must always be presented back to the XFS Manager and the applications in the form of Windows messages, as in other WOSA components such as the Windows Sockets or Windows SNA APIs.

• Error recovery.
  In some kinds of software failures, such as an application crash, the service provider loses connection with the application. In this situation, the service provider is responsible for an “orderly” shutdown of the session with that application. In particular, the service provider generates a system event (see Section 3.11) indicating that the connection was lost, and if any requests from the application were outstanding, it generates a system event for each completion that would normally have generated a completion message to the application.