让时髦走开--论语音应用的结构

因为C/C++和硬件贴近，语音程序（如语音平台）本身通常用C/C++来开发。如果把高级语言看做是硬件和应用之间的胶合层，那么C语言是最薄的胶合层，所以几乎所有的语音板卡接口都是用C语言的API来发布的。

早些年Java流行，很多人便试图用Java来写语音系统，很多公司甚至出现Java的语音系统开发框架。
现在C#流行，便看到很多人在论坛上询问有没有C#的接口。
在我看来，C#和Java因为都还要透过虚拟机，操作硬件接口并不是那么直接，而且如果单机的线路容量很高，便存在一个运行效率的问题。
以C#为例，技术人员之所以试图采用C#来开发，无非是下面几个原因：
1.C#时髦，代表最先进的技术；
2.我最擅长C#，而C/C++太难，我不会；
3.我的应用是B/S结构的，C#开发B/S结构最为简便，用C#写好的语音程序更容易被Web程序调用。

其实，时髦的东西天天在变化，C#当然是个漂亮的语言，但好语言要用得其所，就像手机也能上网，电脑也能上网，如果要快速下载大量图片，手机就不如电脑了。用C#做Web开发当然很好，很方便，但用C#做操作语音卡硬件的应用，却反而是用到了C#的短处。
至于“我最擅长C#，而C/C++太难，我不会”，不会可以学习。如前面所说，和硬件打交道C是最直接的语言，学好C/C++，才能在通信领域畅行无阻。其实，有门槛的技能才更有价值，汽车司机和飞机机长哪个薪水高？花点时间学好C/C++语言还是值得的。

剩下的结构问题，也是我这篇小文章要讨论的核心问题。
广泛考查一下目前的大多数应用，无论是C/S结构还是B/S结构，其实都是围绕着数据库这个核心来构建的。
如下图：

          业   务   数   据   库
          /        |            /
Web管理界面   客户使用界面   语音系统 ...

我们设计一个应用，也总是从数据库开始，考虑建哪些表，需要哪些字段、主键、外键、索引，如何设计他们之间的关系等等。
应用程序不过是从不同方向操纵这些表而已。
从上图也可以看出，语音系统是和其它应用程序平行的一个独立程序，他也同样操纵数据库，举外呼通知为例，语音系统从数据库中取出外呼的任务，一个电话号码队列，分配给通道进行呼叫后将结果写入数据库。
其它应用程序则可以在Web上添加要呼叫的电话号码，并实时地查看呼叫的结果。添加号码，web程序不过是往呼叫队列的表里面插入记录，查看呼叫结果也不过是将表中的呼叫状态或相关字段显示出来而已。

如果从通讯的角度来看，应用程序之间不直接进行通讯，而是通过业务数据库这个中间层来进行通讯。
这样做的好处是设计清晰，每个部件（程序）都可以重写或替换，而且任何操作都可以在数据库中留下记录，便于追踪调试。
即使没有语音应用，两个Web程序之间其实也是用数据库来进行通讯的。比如管理员的页面，他可以查询到所有员工在web页面上的工作，其实管理员查的是数据库。

怀疑主义者会问，用数据库来进行通讯，效率不是太低了吗？更有些完美主义者，试图把语音程序写成Web Service，供其它的应用程序来进行调用。
就目前的数据库发展技术，数据库是最成熟和稳定的。就外呼应用而言，怀疑主义者无非是觉得语音程序去轮询数据库，效率太低。其实，语音程序并不需要时时刻刻去轮询，5秒钟去轮询一次，一次即可以取出多条记录来进行处理。现代的数据库，不要说5秒钟，就是0.5秒间隔的轮询，对性能也没有任何影响。
我也是完美主义者，但将语音程序做成Web Service并不那么完美。语音程序是多路并发的，很多线路在同时运行，而且在运行的时候并不方便被其它多个应用程序所打扰。考虑多个应用程序可能会调用这些WebService，而且试图执行不同的任务，这设计并不容易。更何况很多应用并不是外部发起，如IVR，是用户拨打电话进来，根据按键去操作不同的数据。

从以数据库应用为中心，语音系统是个独立的程序的角度，我们的着力点便是：如何让语音程序更稳定，更高效。
从这个角度，你还会认为一定要用时髦的C#来进行开发吗？

------备注------
关于以数据库为中心，我从Bachman在1973年的图灵奖演讲中得到启发，虽然我没有看过Bachman的演讲全文，仅仅是从《代码大全(CODE COMPLETE)》一书中看到有关介绍。阅读时颇有灵光一闪的感觉。
请参考该书的第二章，“用隐喻来更充分地理解软件开发”。