SOA

来源:百度文库 编辑:神马文学网 时间:2024/04/28 00:12:37
每次给客户做工作流培训,都要接触不同的行业,但我每次都被问了一个同样的问题: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管理领域的一些思想。