从某种意义上说，我们现在做的系统是在刚开始看来是苦不堪言的：一个总页面数量不超过两位数的web项目需要跟超过10个外部系统进行集成，集成的协议包括WebService In/Out(安全与非安全的)、FTP、Email、XML/XSD/XSL等等。然而5个月后第一个版本准备发布的时候，我们发现居然解决了大部分的集成问题（我们对此有准备并且，有最好的组员！）。在与第三方集成的过程中，与WebService、XSD等标准协议的集成相对比较容易，而与那些封闭协议则苦不堪言，耗费大量时间并且整个过程毫无乐趣可言。

例如，需要将PDF通过FTP发布到一个第三方网站。由于PDF不具备自描述特性，传输PDF的同时还需要传一个文本文件来描述这个PDF文件，例如作者是谁，出版时间等等。为了阐述这个文本文件的写法, 第三方系统提供了少则十多页，多则数个DOC文档、PPT演示等让我们学习如何使用这些API。研究和学习使用这种“土制”API充满了挫折感：再丰富的文档也不能涵盖开发的各个方面，通过自身系统的领域模型产生出这样的一个个文本文件的过程并不有趣——想象一下手写webservice文件的过程，更何况这些土制API完全没有规则可言，几乎类似于汇编。这些不是最严重的，更严重的是，对于开发者而言，这些知识——如果他们是知识的话——毫无价值。无论是这些API的维护方还是使用方，一旦转到其他的项目，这些耗费精力学习和掌握的东西立刻价值为零。

相对而言，采用WebService方式的要好的多。一个好的WebService接口明确定义了输入和输出类型。在简单的了解各个属性的业务含义后，开发阶段只需要跟WebService的WSDL交互，开发和测试都很容易。在支持开放标准的IDE帮助下，土制标准带来的无谓时间和精力损耗降到最低，利用开放标准带来的系统之间的耦合也随之降低。其他的，如XSD，也同样具备描述系统接口契约的能力，使用方也能够充分使用工具支持，来完成业务功能。

以前无数次听说开放标准会使系统造价更经济。现在看起来确实如此。观察我前一个项目，一个Outlook插件，运行在Outlook进程中的WPF Rich Client程序。微软乱糟糟的技术在Outlook中得到了集大成。由于对通信内部状态的未知，我们不得不写了很多的Hack方法来绕过各种限制，得到的恶果是严重的性能问题我们不得不推迟上线。痛定思痛，在下一个项目中坚决采用了Web技术，而通过iCalendar协议与Outlook交互。这种方式下，系统之间通过开放标准来隔离彼此的变化，两边的编程模型清晰而简单，没有无谓的猜测。

当然，很多时候我们不得不使用土制协议，如我们，使用的协议是使用了20多年的，要修改绝非一朝一夕的事情。对协议进行直接使用是很愚蠢的，采用接口隔离是一般的做法；另外，为QA提供一个对应的假的实现对于开发阶段的测试也会相当有帮助。

一些想法：

  • 把应用往小而专的考虑比大的好。如果不能，说明分析不够。

  • 一旦两个系统之间发生了两个以上的同类型交互，一定要警惕——如果他们不能合并到一起通过一个统一的API来交互，那么一定是你的分析出了问题。

  • REST很好，但在古板的企业系统中，WebService、XSD带来的强类型的好处，甚至比Rest更好。

  • 如果在你的系统中使用了非标准的协议，例如，我们的项目中使用了Buffalo, 那么请确保这个协议的使用范围被限制在某一个层次之内。Buffalo只是用在Service层与Web层之间的传输，在API的封装下几乎可以被忽略。良好的Service、Web分层结构使得Buffalo不那么重要，虽然实现上他确实很重要。

  • 说服你的客户采用标准协议。如果不能，继续说服，直到说服为止。否则，惨的不仅仅是你自己，还包含客户。与非标准技术斗争很麻烦却一点挑战性也没有，对于程序员职业生涯而言更是毫无价值；而且在浪费客户的钱。

  • 一旦项目被要求做微软系列产品的插件，在没有决定之前，尝试说服客户不要这么做；如果不能，那么做的越少越好；如果还不能（比如被要求在Outlook meeting面板画个新窗口之类），趁早想退路。