📄 ch2.htm
字号:
<html>
<head>
<title>Chapter 2 -- Introduction to Windows Open Services Architecture (WOSA)</title>
<meta NAME="GENERATOR" CONTENT="Microsoft FrontPage 3.0">
</head>
<body TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<!-- Spidersoft WebZIP Ad Banner Insert -->
<!-- End of Spidersoft WebZIP Ad Banner Insert-->
<h1><font COLOR="#FF0000">Chapter 2</font></h1>
<h1><b><font SIZE="5" COLOR="#FF0000">Introduction to Windows Open Services Architecture
(WOSA)</font></b> </h1>
<hr WIDTH="100%">
<h3 ALIGN="CENTER"><font SIZE="+2" COLOR="#000000">CONTENTS<a NAME="CONTENTS"></a> </font></h3>
<ul>
<li><a HREF="#WhatIsWOSA">What Is WOSA?</a> </li>
<li><a HREF="#TheWOSAModel">The WOSA Model</a> <ul>
<li><a HREF="#TheClientAPIMakesRequests">The Client API Makes Requests</a> </li>
<li><a HREF="#TheServerSPIRespondstoRequests">The Server SPI Responds to Requests</a> </li>
<li><a HREF="#TheInterfaceDLLTalkstoBoththeAPI">The Interface DLL Talks to Both the API and
SPI</a> </li>
</ul>
</li>
<li><a HREF="#WOSAServices">WOSA Services</a> <ul>
<li><a HREF="#CommonApplicationServices">Common Application Services</a> </li>
<li><a HREF="#CommunicationServices">Communication Services</a> </li>
<li><a HREF="#VerticalMarketServices">Vertical Market Services</a> </li>
</ul>
</li>
<li><a HREF="#BenefitsofWOSA">Benefits of WOSA</a> <ul>
<li><a HREF="#IsolatedDevelopment">Isolated Development</a> </li>
<li><a HREF="#MultivendorSupport">Multivendor Support</a> </li>
<li><a HREF="#UpgradeProtection">Upgrade Protection</a> </li>
<li><a HREF="#LeveragingWOSAinYourOwnApplications">Leveraging WOSA in Your Own Applications</a>
</li>
</ul>
</li>
<li><a HREF="#Summary">Summary</a> </li>
</ul>
<hr>
<p>Before we jump into the details of the three API sets covered in this book, it is a
good idea to spend some time reviewing the overall architecture upon which these APIs are
built. Although these API sets are only slightly related in their function, they are all
closely related in their construction and implementation. It is the construction and
implementation of the APIs that is the topic of this chapter. </p>
<p>All of the API sets covered in this book are part of the Windows Open Services
Architecture (WOSA). This chapter offers a brief overview of the WOSA model and describes
how it works and the benefits of the WOSA model for developers. Once you understand the
general notions behind the creation and deployment of API services via the WOSA model, you
will also have a good understanding of how to build well-designed end-user applications
that use WOSA-based API services. The WOSA model APIs offer clear benefits to developers
who understand the model. Those who fail to grasp the basic theories behind WOSA may end
up using the APIs incorrectly, thus ruining their chances of taking advantage of the real
benefits of the WOSA model. </p>
<h2><a NAME="WhatIsWOSA"><font SIZE="5" COLOR="#FF0000">What Is WOSA?</font></a> </h2>
<p>The Windows Open Services Architecture was developed by Microsoft to "...provide a
single, open-ended interface to enterprise computing environments." The concept of
WOSA is to design a way to access extended services from the Windows operating system that
require having only a minimum amount of information about the services. For example, the
MAPI (Message API) model is designed to allow programmers to develop applications that use
the message services without having to understand the complexities of the hardware and
software routines that implement messaging on various Windows platforms. The same is true
for the Speech (SAPI) and Telephony (TAPI) services we will discuss in this book. </p>
<p>The WOSA model goes beyond the idea of exposing services in a uniform way across
Windows operating systems. WOSA is also designed to work in a mixed operating system
environment. For example, the Microsoft Rpc (Remote Procedure Call) interface is a WOSA
service that is designed to work with the Open Software Foundation's DCE (Distributed
Computing Environment) Rpc model. The design of Microsoft Rpc allows programmers to design
software that will safely interface with any product that uses the DCE model, regardless
of the operating system with which the software must interact. </p>
<p>In order to attain this flexibility, the WOSA model defines two distinct interfaces-the
Client API and the Server SPI. These interfaces are linked by a single interface module
that can talk to both API and SPI applications. As a result, all client applications need
to do is conform to the API rules and then to the universal interface. All server
applications need to do is conform to the SPI rules and then to the universal interface.
No matter what changes are made to the client or server applications, both software
modules (client and server) will be compatible as long as they both continue to conform to
the API/SPI model and use the universal interface. </p>
<p>The next two sections of this chapter outline the WOSA model in detail and give several
examples of WOSA services currently available. </p>
<h2><a NAME="TheWOSAModel"><font SIZE="5" COLOR="#FF0000">The WOSA Model</font></a></h2>
<p>The WOSA model consists of three distinct pieces. Each of these pieces plays an
important, and independent, role in providing programming services to your applications.
The three WOSA components are
<ul>
<li><font COLOR="#000000">The Client API-the application programming interface used by the
program requesting the service.</font> </li>
<li><font COLOR="#000000">The Server SPI-the service provider interface used by the program
that provides the extended service (for example, e-mail, telephony, speech services, and
so on).</font> </li>
<li><font COLOR="#000000">The API/SPI Interface-the single module that links the API and SPI
calls. This is usually implemented as a separate DLL in the Windows environment.</font> </li>
</ul>
<p>Figure 2.1 shows the relationship between the three WOSA components. </p>
<p><a HREF="f2-1.gif"><b>Figure 2.1 : </b><i>The three components of the WOSA model.</i></a>
</p>
<p>Each of the components has an important job to do. Even though they perform their tasks
independently, the components work together to complete the service interface. This is the
key to the success of the WOSA model-distinct, independent roles that together provide the
whole interface. </p>
<h3><a NAME="TheClientAPIMakesRequests">The Client API Makes Requests</a> </h3>
<p>The Client API is the interface for the application requesting the service. API sets
are usually implemented at the Windows desktop. The Message API (MAPI) is a good example
of a WOSA client API. Each client API defines a stable set of routines for accessing
services from the back-end service provider. For example, the operations of logging into
an e-mail server, creating an e-mail message, addressing it, and sending it to another
e-mail client are all defined in the MAPI set. These services are requested by the client.
The actual services are provided by the server-side application. </p>
<p>The key point is that the client application interface allows programs to <i>request</i>
services from the server-side service provider but does not allow the client software to
access the underlying services directly. In fact, the request is not even sent directly to
the server-side application. It is sent to the DLL interface that sits between the API and
SPI (see Figure 2.2). </p>
<p><a HREF="f2-2.gif"><b>Figure 2.2 : </b><i>Client APIs talk directly to the DLL
interface</a>.</i> </p>
<p>This isolates API calls from the SPI and limits the possibility that future changes to
one or the other component will adversely affect the interface. </p>
<h3><a NAME="TheServerSPIRespondstoRequests">The Server SPI Responds to Requests</a></h3>
<p>The Server SPI (Service Provider Interface) accepts requests for services and acts upon
those requests. The SPI is not designed to interface directly with a client application.
Most SPI programs are implemented on network servers or as independent services running on
desktop pcs. Users rarely interact with these service providers, except through the client
API requests. </p>
<p>A good example of an SPI implementation is the Open Database Connectivity (ODBC)
interface. Even though programmers use API calls (or some other method of requesting ODBC
services) in their programs, these calls merely request services from an external program.
ODBC calls to Microsoft's SQL Server, for example, are simply requests to SQL Server to
perform certain database operations and to return the results to the client application.
When making an ODBC request to SQL Server, the client actually performs very few (if any)
database operations. It is SQL Server that performs the real database work. </p>
<p>As mentioned earlier, service providers rarely display interfaces directly to client
applications. Their job is to respond to requests. These requests do not even come
directly from the client program. In the WOSA model, all requests come directly from the
interface DLL. The SPI talks only to the interface DLL. Any information that the SPI needs
to supply as a part of the response to the request is sent directly to the interface DLL.
It is the DLL's job to send the information on to the client that made the initial
request. </p>
<p>Another important point should be highlighted here. The service provider portion of the
WOSA model allows for multiple clients to request services (see Figure 2.3). </p>
<p><a HREF="f2-3.gif"><b>Figure 2.3 : </b><i>SPIs must handle requests from multiple
clients.</i></a> </p>
<p>The DLL interface tells the SPI which client is making the request. It is the SPI's
responsibility to keep the various clients straight. SPIs must have the ability to handle
multiple requests from the same client and from multiple clients. </p>
<h2><a NAME="TheInterfaceDLLTalkstoBoththeAPI"><font SIZE="5" COLOR="#FF0000">The
Interface DLL Talks to Both the API and SPI</font></a></h2>
<p>Since a key design aspect of WOSA is the isolation of the client API and the server
SPI, a single interface between the two components is required. This single interface is
usually implemented as a Windows dynamic link library (DLL) that allows programs to link
to existing services at run-time instead of at compile time. The advantage of using DLLs
is that programs need not know everything about an interface at compile time. Thus,
programmers can upgrade DLL modules without having to recompile the applications that
access the interface. </p>
<p>The primary role of the DLL is to broker the requests of the client API and the
responses of the server SPI. The DLL does not actually perform any real services for the
client and makes no requests to the SPI. </p>
<div align="center"><center>
<table BORDERCOLOR="#000000" BORDER="1" WIDTH="80%">
<tr>
<td><b>Note</b></td>
</tr>
<tr>
<td><blockquote>
<p>Actually, the interface DLL may request basic information from the SPI at startup about
the underlying SPI services, their availability, and other information that may be needed
to support requests from clients.</p>
</blockquote>
</td>
</tr>
</table>
</center></div>
<p>The interface DLL is the only application in the Windows environment that actually
"speaks" both API and SPI. It is the DLL's job to act as translator between the
client and server applications. </p>
<p>In the past (before WOSA), these DLLs were written as translators from the client API
directly to a specific back-end product. In other words, each DLL interface understood how
to talk to only one back-end version of the service. For example, early implementations of
the MAPI interface involved different DLLs for each type of MAPI service provider. If a
program needed to talk to a Microsoft MAPI service provider, the <tt><font FACE="Courier">MAPI.DLL</font></tt>
was used as an interface between the client and server. If, however, the program needed to
talk to another message server [such as Lotus Vendor Independent Messaging (VIM) or the
universal Common Message Calls (CMC) service provider], another DLL had to be used to link
the client request with the back-end provider. </p>
<p>In the WOSA world, interface DLLs can speak to any service provider that understands
the SPI call set. This is an important concept. Now, a single interface DLL can be used
for each distinct service. This single DLL is capable of linking the client application
with any vendor's version of the service provider. This is possible because the service
provider speaks SPI rather than some proprietary interface language (see Figure 2.4). </p>
<p><a HREF="f2-4.gif"><b>Figure 2.4 : </b><i>Interface DLLs can talk to multiple service
providers.</i></a> </p>
<h2><a NAME="WOSAServices"><font SIZE="5" COLOR="#FF0000">WOSA Services</font></a> </h2>
<p>Microsoft has been championing the WOSA model for several years and promotes three
types of WOSA services:
<ul>
<li><font COLOR="#000000">Common Application Services</font> </li>
<li><font COLOR="#000000">Communication Services</font> </li>
<li><font COLOR="#000000">Vertical Market Services</font> </li>
</ul>
<p>Each type has its own purpose and its own core of services. The following sections
describe the WOSA service types and give examples of services currently available for
each. </p>
<h3><a NAME="CommonApplicationServices">Common Application Services</a> </h3>
<p>Common Application Services allow applications to access services provided by more than
one vendor. This implementation of WOSA focuses on providing a uniform interface for all
Windows applications while allowing programmers and/or users to select the vendor that
provides the best service option for the requirement. In this way, Microsoft can encourage
multiple (even competing) vendors to provide their own versions of key service components
for the Windows operating system. </p>
<p>By defining a single set of APIs to access the service, all third-party vendors are
assured equal access to the Windows operating environments. Since the interface is stable,
vendors can concentrate on building service providers that expose the services that
customers request most often. These vendors can also be confident that, as Windows
operating systems change and evolve, the basic model for service access (the WOSA model)
will not change. </p>
<p>The lis </p>
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -