ch33.htm

MAPI__SAPI__TAPI

to perform file transfers and retrievals. In the past almost all file transfers (such as 
daily payment batches, sales figures, and so on) were handled using dedicated 
applications. It sometimes took hours for these specialized transfer routines to perform 
their tasks and, instead of tying up existing systems, this kind of transfer work was 
off-loaded to dedicated machines. </p>

<p>With the maturing of e-mail and the expansion of the Internet, much of this activity is 
moving through electronic mail instead of direct dialup applications. For the most part 
this is good. But there are times when a simple dialup application can be a better 
solution than e-mail. </p>

<p>The advantage of e-mail is the widespread coverage that is so easy using a single 
protocol (MAPI). Also, the MAPI model has fairly good recovery in the cases of 
non-deliverable messages. While it is quite possible that an e-mail message will get 
routed to the wrong address or return to you marked &quot;undeliverable,&quot; it's rare 
to actually <i>lose</i> a message sent via e-mail. Another plus for MAPI services is that 
there is a wealth of utilities and support software for both programmers and users. MAPI 
is the standard and almost any e-mail client supports MAPI services. </p>

<p>The disadvantage of MAPI is that this protocol can be quite limiting in the types and 
lengths of message formats that can be sent. The most reliable data format is an ASCII 
text file. If you plan to send binary data, you'll need to be sure your routing path to 
all points is able to handle the binary format. Also, large files tend to get garbled when 
sent using MAPI protocol. Many public mail servers even truncate messages to reduce 
bottlenecks in the system. This can lead to tedious conversions of binary data into 
multifile messages that must be reassembled and converted back to binary before they are 
usable for the recipient. While utilities exist for this type of arrangement (MIME 
encoders, for example), it's not always the best way to go. </p>

<p>The advantage of using a dedicated Comm API-based application is that you can write 
small, fast, and relatively simple file transfer programs using any one of several 
reliable and well-documented pc file transfer protocols (the X-, Y-, and Z-modem protocols 
are good examples). By writing small, dedicated applications, you can focus on the things 
you need and leave out all the &quot;headroom&quot; required by MAPI e-mail systems. </p>

<p>One of the biggest headaches when using dedicated programs is file transfer scheduling. 
Usually both systems must be up and running at the exact same moment. This is often 
handled by establishing a fixed file transfer schedule. Each machine is expected to be 
available at a certain time of the day, week, or month to receive or send data files. 
Anyone who has nursed a system like this knows how troublesome this kind of scheduling can 
be. Unless the calls are timed correctly, sites that receive a lot of calls will send out 
frustrating busy signals. Also, if a receiving site goes down (due to power failure, for 
example) the whole system can grind to a halt in short order. As long as there are not a 
lot of sites involved in this kind of arrangement, dedicated binary transfers can often be 
faster and more reliable than ASCII text e-mail messaging. </p>

<p>So, to sum it up, if your application needs to distribute information to a wide number 
of locations on demand, mostly in ASCII text format, then e-mail and Internet/Intranet 
distribution is probably the best method. If you need to send binary data to just a few 
sites on a regular schedule (daily, weekly, and so on), then you should consider building 
a dedicated dialing application that uses the Comm API (or OCX) instead of MAPI services. </p>

<h2><a NAME="AssistedTAPIversusFullTAPI"><b><font SIZE="5" COLOR="#FF0000">Assisted TAPI 
versus Full TAPI</font></b></a></h2>

<p>As TAPI systems become more commonplace, it is more likely that creative minds will 
come up with a reason to use the new extensions for as yet undreamed-of applications. 
While the benefits of Full TAPI services are clear, most applications-especially 
client-side applications-do not need full use of the TAPI extension. For the most part, 
server systems tend to work with inbound calls and client systems usually handle outbound 
calling. If you are building a TAPI application, you need to determine if you are building 
a client- or a server-side application. </p>

<p>Of course, just what constitutes a server is hard to define. With the introduction of 
Win95 to the market, lots of end users have all the tools they need to act as a server in 
telephony or any other Windows extension service. But, despite changes in the operating 
systems, the rule still holds-clients place calls, servers answer them. </p>

<p>If you are designing a system for sales force automation, you may be able to provide 
solid support for key features using only Assisted (outbound) telephony services. In fact, 
some telemarketing shops do not want their employees handling any inbound calls at all. 
Keep in mind that you can still build serious &quot;power-dialer&quot; applications using 
only Assisted TAPI services. You can create applications that read phone number databases, 
automatically place calls, and present telemarketing staff with dialog boxes that contain 
customer-specific information without using Full TAPI services. </p>

<p>Another major advantage of using Assisted TAPI to meet your telephony needs is that 
almost any data modem is capable of successfully placing outbound calls. You will rarely 
need to purchase specialized hardware in order to allow users to call out using their 
workstations. </p>

<p>On the flip side, if you are in charge of building customer service center applications 
that can accept and route incoming calls based on ANI (Automatic Number Identification), 
caller ID, or other values such as an account number entered at the telephone keypad, 
you'll need the Full TAPI service model to reach your goals. If you decide you need to 
accept digits and other call-progress information from incoming calls, you should also 
consider using a third-party TAPI development tool. These are relatively inexpensive and 
usually provide excellent support and documentation. A good TAPI tool can make telephony 
programming relatively painless. </p>

<p>Of course, with the added capabilities comes the requirement for increased hardware 
features. TAPI applications that handle inbound calls will need to use at least a 
high-grade voice-data modem. If you are building an application that will get heavy use or 
one that uses multiple lines, you need to replace your modem with a telephony card. While 
these cost more, they mean a huge increase in capacity for your Windows TAPI applications. 
</p>

<p>So, again, if you are building client-side applications that will be used primarily for 
placing outbound calls, it is quite possible that you can solve your problems using 
Assisted TAPI services. If, however, you are building applications that will act as 
telephony server devices-answering and routing incoming calls-you'll need to use Full TAPI 
and you will probably need a full-featured telephony card, too. </p>

<h2><a NAME="WhentoUsetheSpeechAPI"><b><font SIZE="5" COLOR="#FF0000">When to Use the 
Speech API</font></b></a></h2>

<p>Knowing when to use SAPI services can be a bit tricky, too. While speech systems for 
computers have been around for some time, the Microsoft SAPI model is still a newcomer. 
For the most part, SAPI works best as a text-to-speech engine instead of as a speech 
recognition system. Even as a TTS tool, the SAPI system has its limits. </p>

<p>Reading extensive amounts of text using SAPI's TTS engine can quickly tire the average 
user. This is because the computer-generated voice lacks the human prosody (speech 
patterns) to which users are accustomed. If you have material that is relatively stable 
(for example, directions to your office), it is a better idea to use a recorded WAV format 
file than to have SAPI &quot;read&quot; the text to users. </p>

<p>Another consideration is the amount of processing power needed for SAPI services. The 
SAPI system requires more memory and processor time than the other two services covered in 
this book-and for good reason. The amount of calculation needed to convert ASCII text into 
recognizable human speech is quite large. Converting speech into models that can be 
compared to registered voice menus is even more resource intensive. If you expect most (or 
even some) of your users to have less than 16MB of memory on their workstations, you'll 
have a hard time successfully deploying SAPI services within your applications. </p>

<p>Finally, the accuracy of SAPI speech recognition (SR) is highly variable. The current 
state of technology is only able to reliably handle single words or short phrases. SR 
systems are best used as an addition to keyboard or mouse controls within an application. 
It's frustrating to have to repeat the same phrase over and over again (getting ever 
louder each time) in an attempt to get your workstation to perform some simple task that 
could have been accomplished with a few clicks of the mouse or keyboard. </p>

<p>For the near term, save your users aggravation (and embarrassment) by providing speech 
recognition as an option in your programs, not a sole source of input. This will give 
users time to get used to the idea of talking to inanimate objects without feeling silly, 
and it will give the technology a bit more time to mature and improve its performance. </p>

<h2><a NAME="Summary"><b><font SIZE="5" COLOR="#FF0000">Summary</font></b></a> </h2>

<p>In this chapter you learned some of the advantages and disadvantages of deploying 
software that uses the MAPI, SAPI, and TAPI extension services for Windows operating 
systems. The general points discussed included: 

<ul>
  <li><i>The Rule of Complexity</i>-Where possible, try to limit the number and depth of 
    service extensions used in a single application. With added services comes added 
    complexity-both for the user and the programmer. </li>
  <li><i>Native APIs versus High-Level Tools</i>-Consider the pros and cons of using native 
    API calls vs. employing high-level third-party add-on tools to provide access to extension 
    services. The Native API calls may be faster, but they will also require more coding and 
    maintenance for you and your staff. Building applications with third-party tools can be 
    more efficient as long as that tool is used correctly and it is well supported and 
    documented by its authors. </li>
  <li><i>Standalone versus Extensions and Add-Ins</i>-When adding new extensions to your 
    applications consider the advantages of building simple standalone versions of the target 
    application instead of adding features to existing applications. There are times when a 
    standalone solution is most efficient. However, if you need to deploy MAPI, SAPI, or TAPI 
    services to a large number of people who already have products they know and use often, it 
    may be simpler to distribute add-ins or extensions instead of attempting to replace 
    well-established user tools. </li>
  <li><i>MAPI versus Comm API</i>-As a general rule, if your application needs to distribute 
    information to a wide number of locations on demand, mostly in ASCII text format, your 
    best bet is to use MAPI services. If, however, you need to send binary data to just a few 
    sites on a regular schedule (daily, weekly, and so on) then you should consider building 
    smaller, more focused, dedicated dialing applications that use the Comm API (or OCX). </li>
  <li><i>Assisted TAPI versus Full TAPI</i>-Client-side applications usually need only 
    outbound calling services. It is quite possible that you can meet client-side design goals 
    using Assisted TAPI services and simple data/fax modems. If, however, you are building 
    applications that will act as telephony server devices-answering and routing incoming 
    calls-you'll need to use Full TAPI and you will probably need a full-featured telephony 
    card, too. </li>
  <li><i>Using the Speech API</i>-Current speech technology is more consistent when delivering 
    TTS (text to speech) services than SR (speech recognition) services. The SAPI system 
    requires a hefty pool of memory (no less than 16MB is recommended on the workstation). 
    Also, SR services are not always accurate. It is best to offer SAPI services as an 
    additional service rather than as the primary service at this time. As the technology 
    matures and users become more accustomed to hearing TTS output and speaking in a manner 
    easily understood by SAPI systems, you can increase the use of speech services in your 
    applications. </li>
</ul>

<p>Now that you've got a handle on the ups and downs of mixing extension services, it's 
time to work through some sample applications that do just that. In the next three 
chapters you'll build applications that mix MAPI, SAPI, and/or TAPI services within the 
same application in order to fulfill a design goal. </p>

<hr WIDTH="100%">

<p align="center"><a HREF="ch32.htm"><img SRC="pc.gif" BORDER="0" HEIGHT="88" WIDTH="140"></a><a
HREF="#CONTENTS"><img SRC="cc.gif" BORDER="0" HEIGHT="88" WIDTH="140"></a><a
HREF="index.htm"><img SRC="hb.gif" BORDER="0" HEIGHT="88" WIDTH="140"></a> <a
HREF="ch34.htm"><img SRC="nc.gif" BORDER="0" HEIGHT="88" WIDTH="140"></a></p>

<hr WIDTH="100%">
<layer src="http://www.spidersoft.com/ads/bwz468_60.htm" visibility="hidden" id="a1" width="600" onload="moveToAbsolute(ad1.pageX,ad1.pageY); a1.clip.height=60;visibility='show';">
</layer>
</body>
</html>