理解SOA

 

     7/80年代，流行的是过程式程序设计。一般要采用自顶向下分析方法做功能分解，这个是最自然最原始的想法，而分解的单位就是function。就比如用学生报到交学费为例：学校有3个部门：教务处负责登记；财务处负责收学费；政务处负责发行李，可能还要收住宿费。
    这里就会有4个function存在。登记();收学费();发行李();收住宿费()。首先要明白的一点就是：这里是按学校的内部规则（软件系统内部功能）来划分的，不是从学生（用户）的角度来考虑。做过C语言的开发应该会知道一点：收学费()这个function和收住宿费()这个function两个名称很有可能都取名为了收费()，在其中一个function是放在.so包中的情况下，C编译器是不一定抱错的。
    8/90年代出现了oo。oo的核心是对象。这里可能就有3个包：教务处/财务处/政务处；政务处这个包可能还会分为好几个对象：检查员对象检查财务处盖章，仓库员对象负责发行李等等。这样就解决了过程式程序设计的问题，而且对学生（软件的用户）来说，是基本按用户的思路来考虑的，这也是“为人民服务”的思路。
    但这样其实是不够的。检查员对象检查财务处盖章，是和另外的财务处包挂钩的。财务处包可能会经常发生变动：今年的特招生要多收3W/year；明年的特困生要可以贷款入学。。。。等等。这样就会对检查员对象检查财务处盖章产生影响：可能上面没有章，但也要让该生入住。
    在这样的情况下，就产生了用service为核心来架构软件系统的思路。service是按实际的企业应用为单位来划分的。 比如 政务处手续就可以定为一个这样的service: 检查员对象检查财务处盖章-->收住宿费-->发行李。service实际上是一个流程，而其中的一个流程单元有可能要和另外的service产生关系。SOA这样来划分系统的作用，就是减少服务和服务之间的耦合。
    现在的政府机关提倡的”一站式服务“在SOA架构下变成了很大的可能。学生到“学校报道处”交了学费，填表。然后后面的执行流程自动运转，自动到“教务处负责登记；财务处负责收学费；政务处负责发行李”等不同的service里面去，最后，“学校报道处”通知学生：请你到B-305入住。