本书的最后两章将介绍最后两个框架组件。B2B应用的业务需求非常简单。我希望创建一个应用，它能够接受业务伙伴从因特网传送来的输入文档；在进行内部业务处理之前，还要进行几项服务性处理，例如数据解密、文档结构转换和文档日志记载等；之后，文档将被传递给一个工作流模块，进行一系列业务任务的处理；待文档被处理之后，B2B应用可能产生一个输出文档或收据，并将其通过不同协议返回至发送方。图3-2说明了该B2B应用的高层处理流程。

图3-2  构建于SAF之上的B2B应用处理流程

这个典型的B2B流程图由三组处理组成：输入文档处理、工作流处理和输出文档处理。

输入文档处理包括一系列文档处理层（document processing layer），它们对输入文档进行很多服务性处理。文档处理层的一些例子包括：文档解密、文档结构转换、文档日志记载以及往文档中写入特定应用数据等。

输出文档处理的概念和输入文档处理十分相似，只是施加在文档上的操作是反方向的。然而，情况并非总是要如此，施加在文档上的操作可以增加、减少或根据应用的业务需求重新安排顺序。

诸如更新库存、处理新订单和更新数据库这些真正的“业务”任务，在工作流处理中进行。处理业务文档经常涉及到企业之内的多个应用和系统。工作流处理的主要任务是：识别参与的应用，把它们连接起来使特定业务文档的处理自动化。

因为B2B应用都或多或少地适合上述模型，所以我们可以使用该模型作为高层设计来为B2B应用开发特定领域框架组件。有了这些组件，B2B应用变得更容易开发，也变得更加灵活，可以更优雅地应付业务规则和需求的变化。

SAF有两个支持B2B应用的特定领域组件：DocumentLayer服务和Workflow服务。

3.3.1  文档层服务（DocumentLayer Service）

SAF.DocumentLayer服务为开发者提供一种易用的方法，来创建单独的文档处理层。一方面，各处理层之间相互解耦；另一方面，它们共同协作，来处理输入文档和输出文档。使用SAF.DocumentLayer服务，开发者能够很容易地通过配置文件，来定义特定文档应当如何通过每一处理层被处理。当一个新的处理层要被引入系统时，开发者也只是通过配置文件将新的处理层插入到现存处理层之间，而不会涉及现有的应用代码。

SAF.DocumentLayer的核心是装饰设计模式，它使你能够以“逐层”的方式对一个对象进行服务性处理。在第14章，我们将深入地讨论该框架组件。

3.3.2  工作流服务（Workflow Service）

当一个业务文档通过B2B应用时，许多业务组件都参与对该文档的处理。你必须管理这些业务组件的协调问题，以保证文档能够以正确的顺序处理。随着这些业务组件数量的增加，更多的组件需要相互协作，所以协调逻辑会变得越来越复杂。当处理文档背后的业务规则有所改变时，无论是组件还是组件处理业务文档的顺序，都可能严重改变。

SAF.Workflow服务通过将处理文档的业务逻辑和控制处理流程的协调逻辑解耦，减小了这些处理的复杂性。一方面，如果多个组件相互协作的规则有所变化，或者增加了新的规则，我们只需改变工作流的协调逻辑；另一方面，如果一个具体组件处理文档的规则有所改变，我们只需改变那个组件。

SAF.Workflow借助访问者设计模式，来隔离工作流的业务逻辑和协调逻辑，并使用户易于向工作流中引入新的协调逻辑和业务组件。在第15章，我们将深入地讨论SAF.Workflow及其实现。