2.3.1 Windows Telephony is a WOSA Component
Windows Open Service Architecture (WOSA) provides a single-level interface for connecting front-end applications with back-end services. Application developers and users needn't worry about conversing with numerous services, each with its own protocols and interfaces, because making these connections is the business of the operating system, not of individual applications. WOSA provides an extensible framework in which Windows-based applications can seamlessly access information and resources in a distributed environment. WOSA accomplishes this feat by making a common set of APIs available to all applications.
The front-end application and back-end service needn't speak each other's language in order to communicate as long as they both know how to talk to the WOSA interface. As a result, WOSA allows application developers and vendors of back-end services to mix and match applications and services to build solutions that shield programmers and users from the underlying complexity of the system.
WOSA defines an abstraction layer to heterogeneous computing resources through the WOSA set of APIs. Because this set of APIs is extensible, new services and their corresponding APIs can be added as needed. Applications written to the WOSA APIs have access not only to all the various computing environments supported today, but also to all additional environments as they become available. Moreover, applications don't have to be modified in any way to enjoy this support.
Each service recognized by WOSA also has a set of interfaces that service-provider vendors use to take advantage of the seamless interoperability that WOSA provides. In order to provide transparent access for applications, each implementation of a particular WOSA service simply needs to support the functions defined by its service-provider interface.
WOSA uses a Windows dynamic-link library (DLL) that allows software components to be linked at runtime. In this way, applications are able to connect to services dynamically. An application needs to know only the definition of the interface, not its implementation.
Telephony services under Windows follow the WOSA model. This means that there exist a Telephony API, which is the application programmers access to telephony services, a Telephony SPI (Service Provider Interface) which is implemented by telephony service vendors, and a Telephony Dynamic Link Library (the TAPI DDL) which, in the future, will be a part of the Windows operating system. The Telephony API is the subject of this document. The Telephony SPI is described in this document.
Applications are presented with a uniform set of devices accessed uniformly via the API without needing to know which service provider actually ends up controlling which device. Similarly, service providers just execute requests on behalf of the Windows Telephony DLL; they are unaware that these requests are the result of multiple applications using the API. The SPI definition reflects this single user model at the service provider level. All this multiplexing/demultiplexing of requests and replies is confined to the Telephony DLL.
In an environment with multiple PCs on a local area network, it is possible to develop applications and/or service providers that are distributed in nature. With a distributed service provider, a service provider instance on one client PC is able to communicate with its peers on other client PCs, providing potentially a more powerful model as it can combine knowledge about multiple client PCs that may be involved with the same call.