3.7 Configuration Information

The XFS Manager uses its configuration information to define the relationships among the applications and the service providers. In particular, this information defines the mapping between the logical service interface presented at the API (via logical service name) and the appropriate service provider entry points.

The configuration information also includes specific information about logical services and service providers, some of which is common to all solution providers; it may also include information about physical services, if any are present on the system, and vendor-specific information. The location of the information is transparent to both applications and service providers; they always store and retrieve it using the configuration functions provided by the XFS Manager, as described in Section 7, for portability across Windows platforms.

It is the responsibility of solution providers, and the developers of each service provider, to implement the appropriate setup and management utilities, to create and manage the configuration information about the XFS subsystem configuration and its service providers, using the configuration functions.

These functions are used by service providers and applications to write and retrieve the configuration information for a WOSA/XFS subsystem, which is stored in a hierarchical structure called the XFS configuration registry. The structure and the functions are based on the Win32 Registry architecture and API functions, and are implemented in Windows NT and future versions of Windows using the Registry and the associated functions. For Win32s-based implementations on Windows 3.1 and Windows for Workgroups, a subset of the functionality described here will be available; the SDK will define this subset.

Each node in the configuration registry is called a key, each having a name and (optionally) values. All values consist of a name and data pair, both null-terminated character strings. The structure is as follows:

(1) The top level is the root node for the WOSA/XFS subsystem. Its key name is WOSA/XFS_ROOT (it is a subkey of HKEY_CLASSES_ROOT in the Win32 Registry).

(2) The second level contains at least three keys: XFS_MANAGER, LOGICAL_SERVICES, and SERVICE_PROVIDERS. Other keys (e.g., PHYSICAL_SERVICES) may be defined and used as required.

(3) Below the XFS_MANAGER key there are values and/or keys for information that the XFS Manager creates and uses.

(4) Below the LOGICAL_SERVICES key there is a key for each logical service defined for the system on which the registry resides; the key names are the logical service names (the lpszLogicalName parameter of the WFSOpen, WFSAsyncOpen and WFPOpen functions). Since there is only one registry per workstation, this enforces the requirement that logical service names are unique within at least the workstation.

(5) Below the SERVICE_PROVIDERS key there is a key for each service provider defined for the system.

The configuration functions provide the capabilities to create, enumerate, open and delete keys, and to set, query and delete values within each key. Vendor-provided configuration utility programs set up the registry structure and its contents, using these functions. The third level contains the values and keys that define how the XFS subsystem, services and providers are configured. These are used by the XFS Manager, applications and service providers. Note that vendor-specific information may be added to any key in this structure, using optional values.

The figure below illustrates the structure of the configuration registry:

The XFS Manager key has the following optional values:

TraceFile the name of the file containing trace data. If this value is not set in the configuration, trace data is written to the default file path\name C:\XFSTRACE.LOG.
ShareFilename the name of the memory mapped file used by the memory management functions of the XFS Manager.
ShareFilesize the size of the memory mapped file used by the memory management functions of the XFS Manager.

Some additional values could be also defined in the WOSA/XFS SDK release notes. Please refer to the related document for more information.

Every logical service key has three mandatory values:

class the service class of the logical service; (see the Service Class Definition Document for the standard values)
type the service type of the logical service; the standard values for service type
are defined in the WOSA/XFS software development kit SDK
provider the name of the service provider that provides the logical service
(the key name of the corresponding service provider key)

A service provider key also has three mandatory values:

dllname the name of the file containing the service provider DLL
vendor_name the name of the supplier of this service provider
version the version number of this service provider

An example of the content of the configuration information for an actual system is shown below. See Section 7 for the definitions of the configuration functions.

WOSA/XFS Registry Root

Second Level Keys

Third Level Keys (or values)

Values

WOSA/XFS_ROOT

XFS_MANAGER

TraceFile=<path-name>\<trace-file- name>

ShareFilename=<path-name>\ <share-file-name>

ShareFilesize=<file size in bytes>

LOGICAL_SERVICES

Passbook1

class=PTR

type=PASSBOOK

provider=Passbook_Receipt

operator_station=1

input_paper_source=upper

< other optional values >

Receipt1

class=PTR

type=RECEIPT

provider=Passbook_Receipt

< optional values >

Journal1

class=PTR

type=JOURNAL

provider=Journal

< optional values >

ATSafe1

class=CDM

type=ATSAFE

provider=Cash_Dispenser

< optional values >

< other srvcs >

SERVICE_PROVIDERS

Cash_Dispenser

dllname=CASHDISP.DLL

vendor_name=Big Bank , Inc.

version=3.50

< optional values >

Passbook_Receipt

dllname=RPPRNTR.DLL

vendor_name=Code “R Us, Ltd.

version=1.30

< optional values >

Journal

dllname=JOURNAL.DLL

vendor_name=Nobugs Systems

version=2.01

< optional values >

< other prvdrs >

< other keys >