我对SOA的理解

 我对SOA的理解

每次给客户做工作流培训，都要接触不同的行业，但我每次都被问了一个同样的问题：HongSoft老师，请问应该怎么理解SOA？这个问题其实和工作流培训关系不大，但现在如火如荼的SOA的推广都和BPEL扯上了关系，而BPEL又和工作流间“说不清，道不明”，所以我还真要说说，我是怎么理解SOA的。

7/80年代，流行的是过程式程序设计。我们一般要采用自顶向下分析方法做功能分解，这个是最自然最原始的想法，而分解的单位就是function。就比如用学生报到交学费为例：学校有3个部门：教务处负责登记；财务处负责收学费；政务处负责发行李，可能还要收住宿费。
这里就会有4个function存在。登记();收学费();发行李();收住宿费()。首先要明白的一点就是：这里是按学校的内部规则（软件系统内部功能）来划分的，不是从学生（用户）的角度来考虑。然后如果你做过比较大型的C语言的开发应该会知道一点：收学费()这个function和
收住宿费()这个function两个名称很有可能都取名为了收费()，在其中一个function是放在.so包中的情况下，C编译器是不一定抱错的。曾经有个这样的问题花了我2天的时间来排查（用到了第3方公司的包）。

8/90年代出现了oo。oo的核心是对象。这里可能就有3个包：教务处/财务处/政务处；政务处这个包可能还会分为好几个对象：检查员对象检查财务处盖章，仓库员对象负责发行李等等。这样就解决了过程式程序设计的问题，而且对学生（软件的用户）来说，是基本按用户的思路来考虑的，这也是老毛同志“为人民服务”的思路。

但这样其实是不够的。检查员对象检查财务处盖章，是和另外的财务处包挂钩的。财务处包可能会经常发生变动：今年的特招生要多收3W/year；明年的特困生要可以贷款入学。。。。等等。这样就会对检查员对象检查财务处盖章产生影响：可能上面没有章，但也要让该生入住。
在这样的情况下，就产生了用service为核心来架构软件系统的思路。service是按实际的企业应用为单位来划分的。 比如 政务处手续就可以定为一个这样的service: 检查员对象检查财务处盖章-->收住宿费-->发行李。service实际上是一个流程，而其中的一个流程单元有可能要和另外的service产生关系。SOA这样来划分系统的作用，就是减少服务和服务之间的耦合。
我们现在的机关单位提倡的”一站式服务“在SOA架构下变成了很大的可能。学生到“学校报道处”交了学费，填表。然后后面的执行流程自动运转，自动到“教务处负责登记；财务处负责收学费；政务处负责发行李”等不同的service里面去，最后，“学校报道处”通知学生：请你到B-305入住。

从上面的技术分析，也可以看到管理领域，特别是BPM管理领域的一些思想。