2.1 Architecture

The architecture of the WOSA Extensions for Financial Services (WOSA/XFS) system is shown below.

Figure 2.1 — WOSA Extensions for Financial Services Architecture

The applications communicate with service providers, via the WOSA Extensions for Financial Services Manager, using the API set. Most of these APIs can be invoked either "synchronously" (the Manager causes the application to wait until the API's function is completed) or "asynchronously" (the application regains control immediately, while the function is performed in parallel).

The common deliverable in all implementations of this WOSA Extensions for Financial Services specification is the WOSA Extensions for Financial Services Manager, which maps the specified API to the corresponding SPI, then routes this request to the appropriate service provider. The Manager uses the configuration information to route the API call (made to a "logical service" or a "logical device") to the proper service provider entry point (which is always local, even though the device or service that is the final target may be remote). Note that even though the API calls may be either synchronous or asynchronous, the SPI calls are always asynchronous.

The developers of financial services to be used via XFS and the manufacturers of financial peripherals will be responsible for the development and distribution of service providers for their services and devices. A setup routine for each device or service will also be necessary to define the appropriate configuration information. This information will allow an application to request capability and status information about the devices and services available at any point in time.

The primary functions of the service providers are to:

• Translate generic (e.g., forms-based) service requests to service-specific commands.

• Route the requests to either a local service or device, or to one on a remote system, effectively defining a peer-to-peer interface among service providers.

• Arbitrate access by multiple applications to a single service or device, providing exclusive access when requested.

• Manage the hardware interfaces to services or devices.

• Manage the asynchronous nature of the services and devices in an appropriate manner, always presenting this capability to the XFS Manager and the applications via Windows messages.

The system design supports solution of complex problems, often not addressed by current systems, by providing for maximum flexibility in all its capabilities:

• Multiple service providers, developed by multiple vendors, can coexist in a single system and in a network.

• The service class definition is based on the logical functionalities of the service, with no assumption being made as to the physical configuration. A physical device that includes multiple distinct physical capabilities (referred to as a "compound device" in this specification) is treated as several logical services; the service provider resolves any conflicts. Note also that a logical service may include multiple physical devices (for example, a cash dispenser consisting of a note dispenser and coin dispenser).

• Similarly, a physical device may be shared between two or more users (e.g., tellers), and the physical device synchronization is managed at the service provider level.

• The API definition and associated services provide time-out functionality to allow applications to avoid deadlock of the type that can occur if two applications try to get exclusive access to multiple services at the same time.

• The architecture is designed to provide a framework for future development of network and system monitoring, measurement, and management.

Note that Figure 2.1 is a high level view of the architecture and, in particular, it makes no distinction between service providers and the services they manage. This specification focuses on service providers rather than on services, because the way a service provider communicates with a service is a vendor-specific internal design issue that applications and the XFS Manager are unaware of. In fact, there are many different ways that service providers can make services available to applications. Hence, this specification refers primarily to the service providers, since these are the modules with which the XFS Manager communicates. There are occasional references to 'service' where this is appropriate.

Example

Figure 2.2 below shows a WOSA/XFS system supporting a set of financial peripherals. Note that in this framework the XFS Manager interfaces directly with a set of service providers that interface directly with the physical devices. Thus, the service providers are shown as implementing the service provider, service, and device driver functions, although these are more likely to be two or more separate layers. Many other configurations are possible.

Figure 2.2 — A WOSA/XFS architecture example for a branch office banking system

It should also be noted that one vendor's service providers are not necessarily compatible with another vendor's, as shown in Figure 2.2. If one application has to access the same service class as implemented by different vendors, a service provider is installed for each vendor.