理论介绍（一些定义）

　　业务流程是一个组织及其合作伙伴的人员及系统所完成的工作的一种正式表达， 它旨在给内部或外部客户提供产品或服务。业务流程最简单的表达形式就是一组活动，它们表示流程的不同步骤，通过一些转换连接在一起。活动可能需要人为干预，也可能是全自动的。对于需要人为交互的活动，可以在流程中定义一个角色，标识允许谁在这里与流程交互。流程起到定义的作用，而流程中的实例就是完成整个流程的实际项目，从一个活动转换到另一个活动。实例总是开始于流程的Begin活动，而结束于流程的End活动。实例的路径完全取决于实例的数据以及外部环境。

　　 转换是活动之间的直接连接, 许多的转换进出一个活动.。一旦某个实例完成了一项活动件，外发转换将被评估， 其中之一被选中，以使实例转向下一活动。条件转换包含一个布尔表达式，该表达式将被计算，要使实例继续沿流程前进，结果必须为true。有些转换是基于时间的，这就意味着如果到了预期时间，实例还在那里，这些转换将会触发到目标活动的自动路由。流程也可以有状态：可为流程定义属性，接受每个实例的一个值，这能帮助您保持实例状态，以转换到不同的活动（例如，报价总数>X，那么就执行该活动）。.

　　 从纯建模的角度看，这就是BPM。但要执行流程，这里的定义是不够的；您还需要与其他系统沟通，将流程反映到基础架构中。这就是集成发挥作用的地方了。对于流程中的每一个活动，您都可以定义任务，这些任务基本上是由一个实例抵达该活动时所执行的代码组成的。任务可以通过多种方式实现。当某个实例抵达一个自动活动时，为该活动定义的任务就会被执行，实例将根据执行结果移动到下一活动。

　　 对于人为交互的活动，任务的执行是由最终用户通过客户端工作空间触发的。AquaLogic产品内置了集成功能，可以应用于任务代码之中（这一特性将在以后的文章中更全面地加以介绍，它也是本产品最重要的特性）。任务更新流程状态、访问和更改外部系统，并与最终用户交互等等。任务就是将一个简单的流程模型转变为一个流程驱动的应用程序。

　　 业务流程管理是正式化和自动化业务流程的技术。要想成功地进化为一个面向流程的组织，您必须使用合适的工具来设计、执行和监控业务流程。这就是业务流程管理系统的构建目的。也是AquaLogic BPM设计的目的所在。

时间问题（转移到BPM之前）

　　如果组织想要获得更高的敏捷性，就需要适应业务运转所用到的软件。从概念的角度来看，变化最频繁的不是后台应用程序、不是访问客户的web服务定义、不是EJB的位置，也不是它们所基于的ERP的版本。业务需要适应的最重要的变化就是流程本身：业务必须以某些标准为依据，添加一条更快捷的途径，来自动地认可顺序，从而修改提高或降低认可率的参考值。组织需要处理认可，并平行地检查活动；需要改变执行某项活动的角色；需要手动处理一些异常；需要实施新的业务规则。处理此类变更是BPM的核心内容，允许在不更改任何底层组件的情况修改业务流程。

　　 下节将介绍一些我认为对于理解BPM的真正价值十分重要的东西。

业务流程管理背后（流程尽在控制之中）

　　通过接纳BPM，也就具体化了业务中的一个重要片段。问题是，如果用户的流程模型不可执行（即它只是纯粹的模型），那么最终您是不得不将其映射到一个应用程序、转换它，就像从“分析”到“设计”再到“实现”时的转换一样。这使得将业务流程映射到生产中真正运行的部分非常困难。采用AquaLogic BPM Suite，您可以构建出一个完整的流程驱动的应用程序，将任务附加到活动，而这些活动就是业务流程内部发生的真实操作。任务是流程的代码，既可以是用户驱动的，也可以是系统驱动的。任务的执行是流程中状态改变的主要驱动力。因此，这个流程切实地驱动了应用程序，直接实施了流程中允许的流、任务和操作。

　　 编写流程驱动的应用程序并不会改变您编写代码或实现服务的方式，您仍然是在以相同的方式编写Java类、Web services和JSP。主要的差异在于这个应用程序是流程驱动的。也就是说，所有的代码是通过活动任务触发的，所以您只需专注于这些任务的代码即可，剩下的事情都可由AquaLogic BPM Suite处理。用户工作空间中提供了一些开箱即用的基本流程操作。

设身处地（为最终用户着想）

　　对于您的最终用户（即您所构建的解决方案的用户）来说，最主要的变化就是他们有了一份待完成任务的单一列表。他们可以在收件箱中查看待处理的实例以及对于各实例来说可执行的任务。

　　 以前，用户必须在不同的页面、系统和应用程序上查看需要执行的任务。幸运的是，如果有新的待执行任务，用户会接收到相关通知，但他们很有可能不会在一个单独的视图中发现这样的通知。而BPM可以将工作分配情况很直观地展现在用户面前。

　　 对于最终用户来说，最重要的改变就是呈现在他们面前的将是更加面向任务的工作视图。他们能够很容易地了解，他们有等待通过执行为相应活动启用的任务而许可的待处理事项单。只要清晰地定义流程，您就可以创建出对所有参与实体（如其他系统和人员）来说都很清晰明了的工作单元。

　　 有了流程和实例后，您就需要一个用户前台来管理实例（类似CRUD的基本操作）。对于BPM，这些操作将是创建、搜索、执行、取消、委托和路由。AquaLogic BPM Suite 通过HiPer Workspace（以任意风格）或直接通过使用API（基于Java或Web服务）提供了所有这些特性。用户无需再构建这些功能，它们已经存在了。

　　 BPM是波澜壮阔的SOA运动的一部分，在其中发挥着非常重要的作用。下面分析一下它是如何发挥作用的。

我眼中的世界（BPM眼中的SOA世界）

　　许多知名人士对BPM和SOA之间的关系做了定义。

• Bruce Silver的BPM Watch有一篇非常出色的 文章，标题为BEA's take on BPM-SOA。
• Alfred Chuang 在Exec2Exec时事通讯中撰写了一篇 文章，也提供了很好的描述。

　　我对SOA的观点是：它与构建封装的、可重用、去耦的服务有关。SOA涉及两个主要“方面”：构建去耦服务和以简单的方式将它们绑定在一起。在SOA企业中，所有服务都将在不同级别上自顶向下地连接在一起（否则就不能使用这些服务）。一些绑定极为静态，而另一些绑定却非常动态。BPM试图提供一种工具，来建模变化最大的层次——业务层。流程利用SOA服务作为构建块，它将在底层系统中反映您的业务流程。这些核心服务将在所有流程中重用，提供了真正的重用价值。这些流程将业务、数据和表示服务绑定在一起，实现价值产生因素：真正的业务流程。

　　 如果没有流程层，您最终就要在表示层或业务层里连接这些服务调用，业务逻辑的某些变更将决定哪些服务器要修改，并重新根据新的业务定义来连接服务。下面通过一个例子来详细描述：您拥有一个Web应用程序，它具有双层架构，即业务组件和表示。某些表示组件包含应用程序的排序逻辑。商业用户决定改变业务流程，改变某些操作的顺序及一个业务组件的使用。那么您应如何将这样的业务需求精确地映射到需要更改的代码呢？如何才能知道在哪里修改？为什么需要了解更改流程所需的实现？

　　 使用业务层，您拥有明确的空间来利用可用服务，这里流程层就扮演了这些服务的胶合剂，使它们在业务流程的范围内能够起作用。因此，当业务发生改变时，只有一个地方发生更改：流程，而不是服务。

　　 在BPM的上下文中提到重用时，有多个级别需要考虑：

• 外部系统的低级重用，这里有许多业务流程要访问同一Web服务。
• BPM的中级重用，这里您可以在共享流程和组件模板，重用代码和流程模型的最佳实践。
• 流程的高级重用，这里您可以公开一个流程，该流程可供组织的其他部分使用。