从单体系统到SOA,从关注点分离到模块化设计,这些系统设计方法主要考虑的是对系统的分解,体现出了极致的还原主义方法论。应当说这样的方法论在对柔性的提高上起到了非常有效的作用。在同样的规模下,如今的SOA系统远比以前的单体系统和EAI系统易于实现,并且易于更改,因此也拥有更高的柔性。

简单回顾一下我们之前的讨论内容。从单体系统到EAI系统应用了关注点分离的设计思想。单从关注点分离的角度来看,SOA系统和EAI系统没有太大的区别。如果我们不介意繁杂的中间件管理的话,EAI系统也可以分解出非常多的组件。但实际上,爆炸式增长的中间件数量使这种设想无法实现,正是如此才催生了模块化的设计思想。从这个角度来看,SOA系统的设计是关注点分离和模块化两种设计思想叠加之后的结果。把单体系统、EAI系统和SOA系统并列在一起进行比较,它们在各自的技术条件和应用环境(包括组织的内外部需求和人们在当时的认知水平等)下所采取的设计决策集中地体现在对系统组件的粒度(granularity)的把握上。所谓粒度,又叫颗粒度,通常用来描述一个物体或者系统由何种大小程度的片段或者颗粒所组成。换句话说,粒度可以用来描述一个系统可以分解成多大的组件,或者若干小的实体可以构成更大的实体的程度。前者常用于表述设计者对系统进行分解的程度(一个系统最小的组成单位是什么),或者观察者所在的位置(我们是在集团层面还是在部门层面讨论某个问题)。而后者通常表述一个实体如何由比其更小的实体所构成(我们如何使用许多小零件组装某个部件)。

粒度并不是一个可以很容易量化的性质,所谓粒度的粗细、大小都是相对而言的。例如,我们在描述一个银行的营业大厅的服务功能的时候,将其表述为处理客户请求,那么这是一个粗粒度的描述;如果我们将其表述为开设账户、存取款、修改客户信息、注销账户等,那么这是一个细粒度的描述。当然,我们还可以做出更粗或者更细的描述,这体现的是对粒度的大小的控制。粒度的控制与系统边界划分这个概念的最大不同在于,后者是对系统范围的描述,而前者是对系统分解的描述。作者主张将系统边界和粒度看做是系统论领域中的两个平行的概念:二者不以对方的存在为前提,可以单独地进行操作。

在SOA系统中,对粒度的控制是非常重要的设计决策。决定SOA系统中Web服务的粒度大小意味着设计者认为将什么内容封装成Web服务更为合适。细粒度的服务封装了相对较少的功能,与此同时该服务提供的外部接口也相对简单,与服务请求方进行交换的数据也较少。然而,在业务流程的实现上,可能要调用许多个细粒度的服务,通过多次的服务请求交互。与之相对的粗粒度的服务则是在一个Web服务中封装了更多的业务功能和处理能力,这样可以减少业务流程中服务请求的次数,但相应也会带来服务内部的复杂性,交互大量的数据,因此在进行变更的时候需要更多的工作量。这并不能说粒度一定越细越好,或者越粗越好。一个良好的SOA架构设计,应当在服务的粒度设计上取得一种平衡:决定大小合适的粒度。至于怎样的大小才算合适,这往往取决于该业务所需要的柔性、重用性、将来变更的可能性、服务实现和变更的成本、维护的成本和时间的需要等因素。决定粒度大小的设计决策,往往反映了设计者对以上因素的判断和考虑,在不同的倾向下,会做出区别相当大的设计方案。

为了讨论对粒度的控制所带来的不同影响,我们使用一个简化的业务流程片段进行举例。这个例子来自荷兰移民和外事方面的相关法规,完整的法规是非常错综复杂的体系,本案例提供的是其中非常小的一个片段。但是该片段记录了在进行行政审批的流程中的关键业务逻辑,并且是可以通过计算机自动执行的部分^[37]。该部分法规在实际实施中的整个业务流程也是相当复杂的,涉及的单位包括移民局、领事馆和市政厅,但我们要讨论的内容只涉及在移民局进行行政审批的这个部分。该内容的简单陈述如下:荷兰对于满足以下条件的高等技术人才在荷工作提供工作居留许可:①30岁以下的申请人,年收入需达到34130欧元;②30岁及以上的申请人,年收入需达到46541欧元。作者在中荷两地的研究生教学当中经常使用这个例子,因为它背景简单,容易理解,而与此同时在实现该业务逻辑的时候却能折射出不同的设计风格,并反映设计者对粒度的考虑。

虽然该业务逻辑的文字描述只有短短的一句话,但是在进行流程和Web服务设计的时候需要考虑的内容却远不止这一点。在进行设计决策之前,设计者需要考虑包括但不限于以下事项:

·进行该行政审批需要什么信息?

·什么功能需要封装在服务当中?

·什么功能之间需要分开封装(或者什么功能可以合并封装)?

·什么服务可以被其他流程重用?

·什么样的粒度合适该流程的设计?

·服务以及流程的实现和维护是否方便?

我们来逐个探讨以上提出的问题。首先,行政审批所需要的信息至少要满足法规条文所提出的两点要求,即申请人的年龄和年收入。然而在法规的实施过程中,光是满足这些信息需求是不够的。法律法规提出的只是“做什么”　(what),而不是“怎么做”(how),这跟我们之前讨论关注点分离的时候提到的业务逻辑非常相似。在不会产生不良影响和风险的情况下,法律法规不去过多地涉及“怎么做”,可以为法规的执行提供充分的流程设计的空间。否则,一旦规定了“怎么做”,行政单位就必须严格按照法规指定的流程去进行,且在法规变更之前,该流程不得变更,但现实情况往往复杂多变,这样未必能很好地实施该法规。从法律法规到计算机应用中的业务流程的设计和实施的工作被称为法律工程学(legal engineering),是一门集法律、知识工程和软件工程于一身的交叉学科研究领域^[38]。在进行行政流程的实现当中,流程的设计者为了实现一个实际可用的流程,往往需要在不改变法律法规原意和法律精神的基础上,根据实际操作的需要,额外添加一些必要的信息。在我们的例子里,一个不可或缺的信息便是申请人的身份证明。确定申请人的主体虽然没有在该法规片段中提到,但是可以想象,如果没有申请人的身份证明,整个申请和审批的流程也无法正常进行。至于采用何种身份证明,法律法规并无特别说明,这需要流程的设计者根据实际情况和常识进行补充,通常可以采用身份证、居留许可证和护照等正规的证明材料。为了不涉及过多的细节,我们在这里假设申请人可以提供某个ID来作为自己的身份证明。

其次,设计者要考虑什么功能可以封装成服务。为了满足行政审批的要求,我们需要获得申请人的年龄和年收入信息,这是行政决策的准备工作。当所有信息都齐全后,还需要进行审批的决策判断。也就是说,该流程中需要两类功能:一种是信息获取的功能,一种是决策的功能。在技术和数据条件不具备的情况下,这些信息的获取可能是由人工完成的,比如阅读身份证件上的出生日期,以及使用由雇主开具的收入证明等。而在技术和数据条件允许的情况下,这些功能也可以由计算机来完成,比如读取身份数据库中的出生日期,以及调用税务系统中个人缴税记录里面的年收入信息等。

讨论进行到这里,读者可能会有一个印象:当技术和数据条件允许的时候,需要对信息获取的功能进行封装,而条件不允许的时候不作为SOA系统中的一个Web服务来设计。这种想法自然具有一定的合理性,但是作者主张将所有需要的功能都封装成服务,不管这些功能是由计算机完成的还是由人工完成的。SOA系统具有很好的跨平台特性,即只要满足SOA的技术规范,不管使用何种平台和技术所实现的功能都可以封装成Web服务并发布。那么从原则上讲,只要一个应用满足这些要求,哪怕实际上是人工在屏幕上进行操作所完成的功能,也可以和其他完全由计算机执行的功能一样封装成Web服务。

亚马逊的Mechanical Turk(MTurk)可以说是一个典型的将人的工作任务当成像是计算机执行的任务那样进行管理的例子。MTurk的理念认为,目前还有很多事情人工处理比计算机来得更有效,比如识别照片或者视频中的内容,删除意思重复的内容,抄录录音记录或者是研究数据的细节。这些工作以往是通过雇佣大量的临时工来完成,其往往耗时、昂贵并且在规模上难以控制。MTurk为此专门提供一个Web服务的应用程序编程接口(application programming interface,API),通过远程过程调用(remote procedure call,RPC)将人的工作整合到一起。当任务的请求者提出一个具体的请求时,MTurk就会将这一请求发送给执行任务的人,并由执行者对此做出应答,然后MTurk将回应传给请求者。对于这种将人工的任务以计算机处理的方式进行整合的工作,亚马逊称为“人工的人工智能”(artificial artificial intelligence)。这种将基于软件的服务(software-based services,SBS)和人工提供的服务(human-provided services,HPS)混合在一起的服务系统设计称为混合型面向服务的系统(mixed serviceoriented systems),其最大的好处在于不需要为了区分SBS和HPS而设立并行的两套系统^[39]。

在我们的例子当中,如果将所有信息获取的功能,不管是计算机完成的还是人工完成的,都设计并封装成服务,我们同样可以在一个SOA系统当中完成业务流程的配置和实现。也许目前一些功能需要人工来完成,比如身份信息的录入,但如果将来这些功能可以由计算机来执行,那么替换掉人工完成的部分会变得相对容易——只需要将某个服务进行替换或者更新,而不会影响其他服务的内容。这是封装所带来的好处,同时提高了流程的可维护性。此外,本例子中的决策的功能比较简单,并且可以由计算机很好地执行,因此我们自然乐意将其封装在一个或多个服务当中。

既然我们已经决定将所有功能都封装到Web服务中去,接下来需要考虑的是什么功能应当封装在一个服务当中,而什么功能应当分别封装。从关注点分离的原则上讲,信息获取和决策是两种不同类型的功能:前者与过程相关,而后者与决策相关。将两种类型的功能混合封装进一个Web服务当中的做法并不合适,这一点即使没有特别学习过关注点分离的设计者也不会将两者混合封装。主要的问题是,同一个类型下的功能应该单独封装到不同的Web服务里还是合并封装到一个服务中。为了探讨这个问题,我们不妨将所有的封装方案都罗列出来。得益于我们这个例子的简单程度,所有的服务封装方案共计6种:其中,信息获取的服务有3项(如表3-1所示),另外3项为决策服务(如表3-2所示)。在提供信息获取功能的3项服务当中,GetAge和GetIncome都是细粒度的服务,其本身功能单一,已无进一步分解的必要;而GetProfile是相对粗粒度的服务,实际上包含了前两者的功能。与之相似,在提供决策功能的3项服务中,DecisionYoungerThan30和DecisionElderThan30是细粒度的服务,而DecisionMaking是相对粗粒度的服务。这里需要说明的是,在实际工作中,这种具有相同功能但粒度大小不同的服务通常不会并存,因为我们没有必要重复开发相同的功能。在这个例子当中,列出所有封装方案只是为了对它们进行比较和讨论。

表3-1　提供信息获取功能的3项服务

表3-2　提供决策功能的3项服务(www.daowen.com)

续表

如果我们的Web服务目录中拥有以上的6项服务可供任意选择,那么接下来的将是流程设计的问题,同时涉及服务的可重用性和对流程响应时间的要求,还有实施和维护上的考虑。在这些需求上的不同认识会对设计的决策带来很大的影响,并最终形成风格各异的设计结果。

接下来我们讨论一下3种典型的设计方案。这些流程设计都是为了实现同样的一个功能,即一个申请人通过服务端口程序向系统提交自己的ID,然后系统根据申请人的信息做出行政审批决策并返回审批结果。有BPEL使用经验的读者可能会发现,这些方案的流程示意图中所使用的“receiveInput”“callbackClient”“Assign” 和“Invoke”等关键词主要是在模仿Oracle BPEL用户界面的风格,这些设计方案想要表达的是在BPEL环境下,流程设计师所能实现的设计结果。这样的设定一方面可以反映在具体某个环境中设计师进行设计的自由度;另一方面,读者们也可以体会之前我们对服务封装的设计以及选取不同的服务在实际的使用中对流程设计的影响。

首先,我们来看看如果按照以前的单体系统的设计思路,我们是否可以实现一个尽可能包含所有业务逻辑的流程设计方案。虽然说这是一个SOA环境下的例子,但这只是意味着在流程的设计和配置环境中提供了许多Web服务可供选择和调用,并没有任何规定非要使用或者不使用Web服务。换句话说,流程设计者在SOA环境下设计一个单体系统看起来不太符合实际,但是并非没有可能。当然,在我们的例子当中,完全不调用Web服务是不可能的,因为流程的输入除了使用提供信息获取功能的三项服务之外,没有别的可供输入的渠道。然而,如果执意要这样做的话,设计者仍可以尽量少地使用Web服务,并把相关的业务逻辑直接写入到业务流程中。虽然表达能力比较有限,但是BPEL环境中确实可以将简单的判断逻辑写入到流程控制语句当中。当然这种设计思路下,设计方案不止一种,因为我们既可以先从申请人的年龄开始判断,然后再根据其收入进行决策;或者反过来,先根据申请人的收入,再根据其年龄进行判断,如图3-7所示。在方案一中,流程首先获取申请者的收入信息,通过判断结果,产生3条不同分支,在其中一条分支下,通过年龄信息继续进行判断,并产生两条分支。即总共有4条分支,最后返回相应的结果。这种将业务逻辑直接写入流程的设计方案,将业务逻辑的复杂度全部暴露在流程当中,其设计出的流程自然看起来要复杂一些,流程的分支也是最多的。

这样的设计方案也许不符合我们现代的设计观念,但是并非一无是处。在3种情况下,流程的设计者有较充分的理由来支持这样的设计。第一,如果决策功能不存在重用性的要求的话,并不一定非要将其中的业务逻辑封装成Web服务。虽然将业务逻辑封装会有一些附带的好处,比如更方便应对将来的结构性变化等考虑,但是在完全没有重用性需求的情况下,封装的必要性并不高。第二,如果该流程对响应时间和稳定性的要求非常高,减少Web服务的调用可以缩短程序的响应时间。与此同时,杜绝了将业务逻辑封装在Web服务中所造成的不透明的情况之后,流程的可靠性能够得到一定的提升。这里需要指出的是,这种提升是要视情况而定的。如果流程过于复杂,将所有东西放在一起杂乱无章难以维护的话,可靠性也许反而会下降。第三,如果封装在Web服务中的内容由其他部门或人员进行维护和管理,而流程的执行结果却必须由流程的设计者和执行者负责的话,不恰当的职责划分和规定可能会导致流程的设计者更愿意将所有内容都置于自己的掌控之下。如果业务逻辑需要更新,这种设计的方案至少可以清楚地看见业务逻辑的内容是否已经是最新的版本。由此可见,SOA只是提供了一个模块化的技术环境,想要贯彻模块化的设计还需要从流程和管理上进行相应的考虑。模块化的设计并不是一个单纯的技术问题。

图3-7　方案一的BPEL模型示意图

其次,如果我们考虑关注点分离的设计原则,将业务逻辑从流程中剥离出来可以简化流程的设计。简化的程度与业务逻辑剥离的程度相关。如果保留方案一中细粒度的信息获取服务,同时在业务逻辑的判断上也使用细粒度的决策服务,那么流程的路径便可以缩减到两条,如图3-8中的方案二所示。该方案将申请人年龄的判断条件直接写入了业务流程当中,而基于收入的判断业务逻辑则调用相应的Web服务来完成。由于DecisionYoungerThan30和DecisionElderThan30这两个服务本身不包含对年龄的判断,因此对申请人年龄的区分就只能交给流程本身去完成了。从这个角度来看,在选用细粒度服务进行流程设计的时候,也意味着流程当中必须保留部分业务逻辑,以便该流程根据输入的实际情况准确地调用合适的Web服务。该方案的最大特点是全部采用细粒度的Web服务,无论是信息获取服务还是决策服务。

这种设计方案有其优缺点。优点有三处,一是使用细粒度的服务可以在一定程度上保证服务的可重用性。细粒度的服务由于功能相对单一,可以使用的场合往往较多。例如获取申请人年龄和收入的两项细粒度服务,在申请工作居留的流程中可以使用,在其他一些行政审批当中,年龄或者收入通常也是需要获取的信息,创建并使用这些Web服务从单位的全局考虑是具有价值的,虽然对于单个流程而言,这样的设计也许不是最优化或者最简化的方案。二是细粒度服务封装的内容较少,在对内容进行修改的时候相对简单和容易。举个例子,如果法规只是对30岁及以上的人员的申请条件进行了修改,那么使用这种细粒度的服务在修改的时候会较为容易。不过,这样同时也意味着定位这些细粒度的服务会稍微麻烦一些,因为同样的功能被进行细粒度封装之后,Web服务的数量自然会比进行粗粒度封装的情况要多出不少。在我们的例子当中,粗细粒度之间成倍数关系。细粒度在修改的时候虽然会较方便,但是由于数目较多,寻找对应的细粒度服务自然会比寻找对应的粗粒度服务要麻烦一些。这符合我们之前的观点:复杂度不会消失,只会转移或者以不同的形式出现。三是流程的分支确确实实减少了,方案二的流程看起来的确要比方案一的容易理解一些。至于该方案的缺点,主要是需要调用的Web服务数量较多。我们之前也讨论过调用数量越多流程的响应时间会相对增加,与此同时,可靠性也会降低。此外,虽然这个方案只调用了4个Web服务,并不算多,但是在实际应用中,当一个流程涉及许多Web服务的时候,不仅是流程的分支数目问题,流程的调试和配置也会变得复杂。

图3-8　方案二的BPEL模型示意图

模块化的设计主要优先考虑的是信息隐藏,其次才是考虑重用性等附加的作用。如果我们将信息隐藏推向极致的话,方案三(如图3-9所示)应该是最容易想到的一种设计方案。该方案调用粗粒度的Web服务,服务调用次数很少,仅有两次。在该方案中,所有的业务逻辑都被剥离出业务流程,业务流程中不进行任何直接判断,基于申请者的年龄及收入判断均通过调用Web服务来实现。从流程的模型上看,该方案的业务流程非常清晰与简单,它只有一条路径,而无其他分支。这种设计方案的好处显而易见,对于流程的维护人员而言,这是一个化繁为简的好设计,前提是在服务的维护和流程的维护之间有着良好的管理规范和清晰的责任义务。例如,负责软件系统维护的IT技术人员主要保证系统的运行环境良好顺畅,而负责对法律法规进行解释和建模的知识工程师主要负责Web服务当中的业务逻辑的维护和更新,双方各司其职是确保该流程顺畅运行的前提。此外,该方案的响应速度也不会比方案二低,因为调用Web服务的数量较少。但如果要说该方案的缺点的话,首先是可重用性的问题。粗粒度的Web服务的可重用性往往不如细粒度的Web服务。从整个IT环境上讲,一般情况下,需要同时使用年龄和收入信息(GetProfile)功能的场合往往会比单独需要年龄(GetAge)或者收入(GetIncome)的场合要少。此外,单个粗粒度的服务在维护和更改上也要比单个细粒度的服务要麻烦一些。

纵观以上的3个方案,设计者在对粒度控制上的考虑会在很大程度上影响到流程设计本身。我们在每个方案当中分别讨论了它们的优缺点,并主要集中在重用性、响应时间和可维护性上。表3-3将这3个方案在以上几个考虑因素上的表现进行了比较。

图3-9　方案三的BPEL模型示意图

表3-3　三个方案之间的比较

本节着重探讨结构复杂度对架构设计的影响。虽然选取了非常简单的业务流程设计的例子以便讨论,但其中关于关注点分离和模块化的设计思想以及设计者对粒度的控制所带来的影响,在更复杂的业务流程管理中依然适用。