SOA与基于CDIF的API的联动

几千年来，巴别塔的故事一直是人类面对的一个核心的困境。为了交流和沟通我们人类创造出语言，但沟通与交流仍然存在障碍……相同语言之间的沟通依语境的不同，尚且存在巨大的鸿沟，不同语言之间更是让人坐困愁城。

在物质文明高度发达、人工智能都已触手可及的今天，程序员一样在面对这样的困境。我们的先辈基于那时的技术条件，基于那时的业务需求，映射性地逐步发展出FORTRAN/COBOL这样命令式的程序设计、C/PASCAL这样过程式的程序设计，到C++/JAVA这样的面向对象的程序设计，再到今天WebService这样面向服务的程序设计。于是各式各样的异构性层出不穷无所不在，硬件（CPU和指令集、硬件结构、驱动程序）、操作系统（不同操作系统的API和开发环境）、数据库（不同的存储及访问格式）都不尽相同，高级语言更是依赖于特定的编译器和操作系统API编程，它们彼此互不兼容，需要开发和运行环境的支撑。这样的异构性使得各种不同软硬件之间在不同平台不能互联互通，再加上网络协议和通信机制的不同，系统之间还不能有效地相互集成，如同不同族群之间互相比划着沟通。很难协同组织去面对挑战。

虽然语言不同，但人类需要表达的内核是相似相通的，同理，各种应用系统之间的许多基础功能和结构是有相似性的，它们提供的服务和功能是相似的。如果每次开发都从零开始，就像每次造一款汽车都去重新发明一次轮子，那无疑是可笑的。

于是，屏蔽各种异构性，实现某种标准的互操作，以实现复用（而不用每次都去发明轮子），通过松耦合，通过将具体的业务抽象，通过服务的表达和业务过程的原子化去架构规划整个业务流程，这个架构就是SOA。

——SOA就是这样的一个范式，用于组织和利用可能处于不同所有权范围控制下的分布式系统。

打一个形象的比喻，一个企业的最终服务就像是要安排各国大厨准备一桌顶级的菜肴，需要日本的生鱼片、清酒，法国的鹅肝、生蚝，德国的啤酒、肘子，中国的爆炒、佛跳墙，在这种情况下，你并不用再去学习各种语言和大厨们交流，只需要自己编排好上菜的顺序，在他们制作好的菜肴照片下写好交付时间，交给大厨，互相点头确认，按点去取菜,有统一的侍者规范上菜, 以保证最佳用户体验。每个大厨后面自成体系，团队内部用各自的语言交流，如同API后面的那个应用。而你编排的上菜顺序，就是流程驱动,服务员取菜就好比是API调用。

实际上，中国古代的四大发明中的印刷术，就是SOA思想应用的典范。没有印刷术之前，书籍需要手工抄写，因此效率低下，质量也不稳定，无法保证一致性。有了印刷术，出版效率和内容一致性提高了数量级！最初的印刷是刻板，这就是“复用”，如同软件通过组件的封装，达到重复和在不同场合使用的“复用”效果。但是，刻板印刷就是一个紧耦合，一块刻板只能印某一本书的某一页，其中具体的“字”无法复用，就如同软件技术中微软VB开发的com+组件就只能在windows环境中使用，无法与JAVA开发的EJB组件进行复用和编排，因为他们与开发环境和运行环境是紧耦合的，要在UNIX环境下使用，必须重新开发，相当于换书就得换版。而后的活字印刷就彻底解决了这个问题，文字和版面之间是松耦合，通过排版来实现一本书的印刷版面…….这又是数量级的跃升——如同我们可以封装服务，形成一个个API，通过服务编排的API联动来实现业务流程。

现在流行的所谓微服务，就是单个的活字，通过SOA串联成为文章（服务）。讲到这里，就必须提到schema。松耦合的活字印刷要想做好，每个字之间都需要遵循一定规范，比如字体，字符的大小，都要遵循一定的模式和契约。如同我们可以封装服务，形成一个个API，服务的共享通过API模式和契约(schema and contract)来协调，通过服务编排的API联动来实现业务流程。

schema就像是活字印刷里每个字，都应该有的固定规范，比如字体、大小、线条宽度等等，没有这个规范，有的字大、有的字小，印出来乱七八糟，而这恰恰是目前微服务领域的现状：基于XML的很多微服务根本没有schema！它们仅仅是山寨SOA。

综上所述，SOA是把复杂的业务系统切分成一块块小的独立系统，每个系统都叫一个服务，对外提供一组独立的API，然后通过API联动组织起完整的业务来。在每家企业发展的初期，通常一个或几个数据库表格就完成了业务，像大多数小企业那样。但当企业的业务系统复杂性膨胀到一定规模后，就必须考虑如何将各个子系统按照彼此独立的服务切分开来，不然以后会乱成一团麻，根本就无法管理。

这种联动，按照业务流程的要求是可以一步步串起来，提供无限的复杂度。这是企业内部的情况。那么，在外部呢？现在各种云服务厂商也有着无数的API，每一个都可以看成一个独立的服务。但如果把这些独立的服务也串起来呢，那就可以创造出一个个全新的应用。比如：有三个独立的单位，第一个单位是地方卫生系统，他的数据库保存的是该地某个人的医疗保险记录；第二个单位是某个医院，他的数据库中保存的是某个人在该医院所有的就诊记录；第三个单位是保险公司，他的数据库里保存的是某个人的参保记录。本来他们的系统互不相干，通过SOA的API联动，就可以很方便地根据一定条件从上述几个子系统中分别获取数据后，组织起一个完整的新业务流程。比如，如果某人以前参加过社保医疗保险，并且去年就诊次数不多于5次，同时前三年没有在保险公司购买过任何医疗保险，那么就可以给这个人提供50万的医疗保险，不然就少一点或者拒接保险申请，等等。

……可见，API联动的想象空间是无限的，但前提是开放！

因为每一个API就如同一个单独的音符，你稍微联动一下，它就能形成一个曲调；

如果你是一个大师，你就能写成一个恢弘的交响乐章；

如果你......进入CDIF......