闲话SOA服务化之–接口和协议
在系统SOA化之后，不可避免的就遇到接口的问题，在Java环境使用XFire。常遇到：接口不匹配，服务依赖者不能动态切合等问题。
后来不知如何，就说起了银行的系统：多平台，多语言，物理分布，有购买的产品，有多开发商开发的产品，业务负责，存在协议（多是核心金融业务）、接口调用等多种方式。很是佩服之。随就接口方式和协议方式进行了一些比较。
【术语：
- 协议 — 协议包含了数据格式，同时规定了行为等方面的内容，例如邮件协议，RPC协议。
- 格式 — 对信息的编码。例如：XML格式。
- 接口方式 — 指程序接口调用实现业务交换的方式。例如：java API调用。
- 协议方式 — 通过某种报文（信息是满足格式的）实现业务交换的方式。例如：收邮件，发邮件。
】
| 比较点 | 基于接口 | 基于协议 |
| 开发人员编程期的易用性 | 容易理解
使用方便 可以直接编程 |
较难理解
使用较麻烦 不能直接编程 |
| 架构从单系统到多系统变迁的过程 | 平滑迁移 | 修改协议相关的代码 |
| 支持工具的方便、稳定性 | 有现成的工具，如xfire
稳定性很好 不需要考虑序列化问题 与Spring整合的非常好，程序员不需要关注序列化，传输，安全等问题 外界维护工具 |
可以使用xml binding1等工具1
需要考虑序列化问题 缺少一个类似这样的完整工具，让程序员爽 需要自己维护工具 |
| 自我校验 | 基于接口校验，例如 验证 工具自动支持 很容易自动方式检测不匹配性 编译时检查 |
基于协议校验，例如 schema验证 缺少工具自动支持 运行时检查 |
| 方法名称变更 | 需要变更，甚至重新发布系统（可以通过配置文件来避免重新发布） | 不需要变化
通常协议内部包含着业务指令号； |
| 方法参数变化（增加，减少） | 需要变更，重新发布系统 | 没有方法参数概念 |
| 方法参数类型变化（具体值得内涵没有变化，例如 123，从int变为string) |
可能会失败 | 没有方法参数概念 |
| 参数是对象类型，对象属性变化（增加，减少） | 增加不会失败，是否变化，依赖业务需求。如果业务上兼容该协议，那么也不需要变化；否则需要重新发布系统
这也是风险点（但可评估） 减少没有测试 |
没有对象参数概念 |
| 协议变化（增加，减少协议项）
（与） |
没有协议概念 | 可能会失败，依赖业务需求。
如果是技术上的一个协议项变化，那么可以不变化，也不会失败 如果业务上兼容该协议，那么也不需要变化；否则需要重新发布系统 这也是风险点（但可评估） |
| 增加方法 | 可能在自检查的时候系统级别失败
业务级别会失败 |
相当于增加了一个业务指令
系统级别不会失败 业务级别会失败 |
| 存在同名方法（参数类型不同，但相似）如（ int和double |
会失败 | 没有该概念 |
| 工作流类、 JS类产品与业务结合的时候 |
需要引入多个接口
或使用动态 |
直接操作协议 |
| 一个业务的多个操作时的表示，例如：增，删，修改，查 | 通常是多个方法来表示不同业务 | 一个协议 +指令就可以解决 缺点：需要细心，别用错了指令（测试阶段可以解决） |
| 运行期稳定性问题 | 测试和系统检查可以确保运行起稳定性 | 需要很细心的测试和部分系统检查来确保运行期稳定性 |
| 接口变动太随意 | 由于容易，且是基于操作的，所以每个程序员都可以自由使用 | 由于复杂，而且是基于业务的，需要清晰、仔细的定义，反而因祸得福 |
| 管理方面 | SOA的相关支持工具，比如服务仓库，能够使用一种元语言完整地定义服务的契约，再根据这些元定义生成 一系列东西 |
缺少这方面的支持
需要自己开发相关工具 但产品经理可以通过业务层的管理来管理协议，从而约束开发 |
| 版本问题 | 解决较为麻烦 | 解决较为容易 |
| 与路由概念配合 | 较为麻烦 | 由于基于协议，与路由结合起来反而容易 |
| 投入成本 | 低 | 高 |
| 学习成本 | 低 | 较高 |
| 从实施工程的角度看 | 组织的软件成熟能力度要求低，项目管理要求中.开发人员人员水平偏低，更需要强约束的框架或者实现方式。 | 组织的软件成熟能力度高，项目管理要求中高 |
【说明：】虽然SOAP也定义了文档格式，但在实际使用中，使用者很少。毕竟，文档格式方式的WS走到是协议思路。
【闲话杂聊】
最近看到REST方式，它非常流行，很多网站的OpenAPI都基于它来搞，我们也准备尝试之。看了深入浅出REST一文，初步了解了一下它的资源概念，还是有些不知所措；又看到Building Web Services the REST Way一文，其中一句话“REST - An Architectural Style, Not a Standard”，指出了本质，原来我们可以在它的框架下使用接口方式，也可以使用协议方式。
结合它的目标是描述资源—互联网资源，我们就会发现，互联网界的大部分内容都是用协议来描述的，例如：HTTP协议，HTML协议等。 再看看google的RESTful API Specification，虽然是API，也基本是用半个协议的方式进行描述（它的JS标准部分，完全是接口的方式，毕竟这个时候不存在整合的需求。Facebook的API，也基本上接口方式，输入参数按照HTTP提交方式，输出部分到部分定义了格式。）
在开放互联网界使用的Rest + 格式方式 ==？协议吗【注：我看到axis在搞 Rest （序列化部分用XML格式），这东西和非Rest 的WS有哪些本质区别？】在企业内部是否依然也有很强的生命力？— 留给实践来检验吧。
【后感】
接口：内存调用 –〉RPC调用 –〉IDL系列（COM+,corba,RMI等）-〉SOAP系列 ，这一条发展线路基本是程序员主导。从抽象的角度看，程序员是不关心业务的，因此尽可能的让集成方法远离业务层，从系统层面解决之。
协议：EDI，ebXML系列，信用卡数据交换协议，国人搞得cebXML等等，这条线路基本是业务专家主导。从抽象的角度看，业务专家不关心系统如何实现，它更关注业务的标准化。
接口和协议看似两个简单的概念，但它们代表了两种系统整合思想，两种架构思路。他们有时候是对立的，有时候又是糅合的，很有些哲学的味道，对立统一规律（辩证法）。
