C#框架设计之浅谈SOA与钝化模式

一. 什么是SOA

      SOA即为Service-Oriented Architecture缩写，翻译过来也就是面向服务的软件架构。通过将软件功能或者是业务流程进行服务化发布，从而达到一种面向于契约和服务，独立于使用平台的效果。而这种效果是跨平台，跨语言的。

       如果要简述SOA，那么就必须去简述一下SOA的发展历史。如同设计模式每一个模式书写的那样，SOA的出现必然有其意图和”模式是做什么的”这两方面的内容。那么让我先来简述一下SOA出现的原因。

二. SOA的意图

       SOA的出现主要是为了解决如下两个问题：

    （1）程序模块或者是软件之间调用关系杂乱，导致摸个地方要进行修改，对于其他的调用方来说，也要进行一些反复的配置或者修改。通过隔离各个软件之间的关系，统一进行调用接口的管理（如下图1），改变杂乱的调用关系。

图1

    （2）随着企业软件的日益发展，单模块已经不能满足发展的需要，从而重构形成了多模块的整体架构，这一步通常会使各个模块之间的调用更加的明确，也会使重复功能更加的少，使软件的模块代码功能更加的明确。于此同时对于各个模块所控制的数据库部分，也会进行相应的水平分库或者是进行垂直分表，来满足日益提高的业务需求。如果这样“模块化”之后，还是不能满足需求，那么就需要将一个软件的各个功能在进行相应的细化拆分。使得软件的各个功能从原来的模块化，变成为服务化。这样软件的功能可以分布在不同的服务器上，而不需要将一个软件的所有功能发布在同一个服务器上（如下图2）。

图2

三. SOA的实现

    SOA的实现有很多种，例如：webservice、web api等等，我们比较常用的服务发布http接口，通过post json来进行交互。

    上述的实现都是即时交互的，即我调用服务走一个业务流程的时候，我每一个服务之间的调用会是瞬时的。也就是说我不会去等一个http请求，等上几个小时，这明显是不合理的，当然软件自身也会有超时处理。那么如果真的存在一个业务，会使得一个流程的处理长达几小时或者业务的处理过程中需要人工审核停顿，那么上述的实现方式可能不在适用。

    那么如何处理这种服务流程的调用呢？下面我就要来说说SOA的钝化模式。

四. 钝化模式的意图

    这里我沿延用王清培前辈写的《.net框架与设计》书中的原话来说明该模式的意图（当然大家有兴趣也可以看一下该书中有关钝化模式的讲解），书中写道如图3内容

图3

       不难看出钝化模式就是用来解决一个业务在不同流程中的持久化问题的。这里还是要强调一下持久化，所谓持久化就是将文件或者数据保存在一个可以持久保存的介质上的行为。钝化模式通过将程序进行冻结处理后，放在一个持久化介质上，等待到他需要再次进行执行处理的时候，在将其进行恢复执行状态，继续执行。可能说到这里大家一头雾水。什么？程序还可以跑一半，隔一段时间之后，恢复一点继续跑的吗？恩，确实通过钝化模式可以做到。我们来看看代码。

五. 模拟的业务场景

      在摆出代码之前，我还是想先介绍一下这个代码模拟的业务场景，以便于理解。

      某公司是一个罐头制造厂商，生产各种罐头，包括我最喜爱的黄桃罐头和我最不喜欢的鲱鱼罐头。这个批发商生意很好，有很多很多的客户下订单，但是一个审核流程需要信息员确认客户信息、业务员审核客户购买商品数量和总经理在最终审核之后在该笔订单上签字确认。但是这个审核流程由于业务繁多，或者总经理比较繁忙，无法再每次客户下单的时候，立即对业务进行处理，也无法在每一个角色完成之后，下一个角色立即进行处理。于是改制造厂商通过钝化模式，开发了一个用来处理他们业务流程的软件。业务流程如以下图4所示。

图4

六. 程序实现

      先大致的说一下各个类实现的功能。下面的是vs生成的类图，如下图5：

1.  PassivationStatus枚举：这个枚举是用来标示流程究竟走到了哪一个流程，类似于一个描点。通过从PassivationManger（流程控制器，以下该类均称为流程控制器）中获取对应的存放着当前流程的属性CurrentStatus来确定流程究竟走到了那里；

2.  PassivationManger类：这个类是钝化模式的核心。他维护了一个用来绑定信息员、业务员和总经理三个方法的委托实体。他同时也维护了一个流程审核过程每一个过程转移到下一个过程的状态链（flowList)。通过使用AddFlow来增加业务和业务状态，通过RunFlows来对业务流程链进行执行。其中FlowStatusMoveNext是用来当一个流程走完之后，自动将执行状态进行下一的方法，而_currentStatusId是用来记录当前移动在flowList中的索引位置；

3.  PassivationMangerDelegate委托：用来统一信息员、业务员和总经理三个业务方法参数和返回值，以便于注册到流程控制器的业务流程链中。当然这也是统一参数设计思想的体现。

4.  ManagerControl类：主要是用来管理流程控制器的类，用来冻结和还原PassivationManger类。其内部维护一个流程控制器。

      实现原理：通过将每个业务方法和业务状态注册到流程控制其中，在每次执行代码的时候将序列化的流程执行状态还远，然后根据当前的流程状态来执行对应状态的流程，在执行完之后对流程状态进行后移，然后将执行的情况进行序列化。

七. 程序运行结果

       由于个人不喜欢在book文章中贴一大段一大段的代码，所以就放一下运行的结果吧。具体的代码和相关详细的解释会在工程中给出，个人用的vs版本是2010。

       三次运行，运行的结果如下面图所示。

       信息员的业务：

       业务员的业务：

       总经理的业务：

        文件序列化后的内容大家如果有兴趣也可以自己分析一下，还有持久化的载体和方式也不止那么一种，大家可以自己去尝试一下。

每次运行之后序列化的文件

七.后续

        大家最喜欢的工程文件请点击下方文字下载。

        下载源代码

        如果对本文有什么意见或者是建议都可以在下面的评论中提出，我之后会多写一些有关于框架的文章。您的支持是我的动力。

        转载请注明出处。