Laszlo 平台由LZX语言和Laszlo展示层服务器组成。

• LZX 语言是一个XML和JavaScript描述语言组合，本质上类似XUL和XAML。LZX使用声明性的和基于文本的开发步骤，支持快速原型法和最佳软件开发实践。
• Laszlo 展示层服务器(LPS)是一个Java Servlet，将LZX应用程序编译为目标运行环境的可执行代码。Laszlo当前的运行环境目标为flash播放器，LPS将LZX应用程序编译为flash播放器的SWF字节代码，为任何嵌入Flash5播放器或更高版本的Web浏览器提供已编译过的应用程序的代码和缓存，并且可以为应用程序代理请求后台的XML数据和Web服务。

        
使用Laszlo你将可以：

• 使用基于XML和JavaScript的标准RIA应用
• 可以将应用部署到任何运行在Linux、Unix、Windows或者Mac OS X上的J2EE应用服务器或Java Servlet容器中。
• 可以将应用展示在拥有97%桌面Web浏览客户端的flash 5播放器或更高版本中

自 2002 年起，基于 Laszlo 的应用程序已经被证明在百万级用户的公共 Web 环境中是可行的，并且是稳定可衡量的。

前言

    如果数据库系统（ database systems）像受人尊敬的智者讲述的条理清晰的故事，那么工作流（workflow）就像一群乳臭未干的小子在大谈各自的“哲理”。之所以这样讲，我是想指出，工作流系统 （workflow management systems）还处于技术发展曲线（ technology hype curve）上的初级阶段。在这个领域我们将面临一个激动人心的阶段。 为了描述这一点，可以将工作流和关系数据库系统（RDBMS）做一个对比。当在软件开发团队中谈论RDBMS时，大部分人会有一个清晰的概念，在你和他们交流的时候，人们会通过轻微的点头表示认可或理解你所说的。可当使用工作流术语讨论工作流时，他们会摇头表示不同意，因为每个人对工作流术语都有不同的理解。

Figure 1: Workflow vs. RDBMS positioned in the hype-curve

    导致形成这种状况的原因之一，是在工作流中使用了过多的概念。在这个领域中的大量规范和工具没有一个是相似的。当然，它们相互之间有重叠并且会相互参考引证。
    在介绍工作流时有一个话题必须包括，那就是工作流和业务流程管理（BPM）的关系。术语“工作流”通常描述人与计算机系统的一系列相关交互。在开发人员中，工作流经常被提及。有时，工作流的意思是指一些不同的UI界面。业务流程管理的范围比较广，相比之下工作流多半局限于技术领域。业务流程管理还从管理人员的角度涉及了非技术问题，比如分析、组织的效率。

    在本文中，我首先解释什么是工作流管理系统，然后介绍业务流程管理的优点。接下来描述一下为什么工作流市场乍看起来如此混乱。本文给出的主要结论是：选择工作流系统是想用工作流系统的公司，将要面对的最困难的事情。为此，本文的核心部分描述了一个流程定义（process definition）的四个层次，为你选择工作流提供一个基础。本文还用中立的语言描述了工作流和BPM的通用概念。最后，给出了一些规范和工具的指导性描述。

什么是工作流管理系统（WFMS）

定义

    工作流系统是以规格化的流程描述作为输入的软件组件,它维护流程的运行状态,并在人和应用之间分派活动。

    为了后面的描述，我们先定义一些基本的术语：流程定义（process definition）和流程实例（process instance）. 一个流程定义是一个业务流程或过程的规格化描述。一个流程实例是流程定义的一个运行实体。 都目前为止，概念还比较清晰是不是？但当再深入一步时，我们就要小心使用文字了。如何阐述流程中的步骤，现在还没有一个统一的方式。这是各种工作流规范和工具之间主要的分歧。

    工作流系统另一个重要的职责是维护每一个流程运行的上下文信息。 流程上下文变量（process context variable） ，或简称变量，是与流程实例相关的变量。如，休假申请的开始日期、数据库中一条记录的键值、文档管理系统中一篇文档的索引等。通常在流程定义中声明这些变量，然后在流程实例生成时，这些流程变量被实例化。所有成熟的工作流管理系统都支持定制的变量类型。

目标领域（Target usage）

    使用工作流管理系统的目的之一是作为企业应用系统集成（EAI）的平台。在当前大部分企业级IT架构中，各种各样的异构（heterogeneous）应用和数据库运行在企业内网中。在这些系统被应用到组织时，都有一个清晰的目标。例如，客户管理、文档管理、供应链、订单、支付、资源计划等等。让我们称这些系统为专门应用（ dedicated applications）。每一个专门应用都包含它们所支持业务流程的领域知识。这些专门应用中的自动化流程，被拼装到企业中更大的非自动化流程中。每当一个这样的专门应用安装并投入使用，都会带来涉及其他多个应用的新功能需求。企业应用系统集成（EAI）就是通过使用多个专门应用满足软件新需求的方法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。可以这么说，在你购买专门应用时，你是购买了一组固定的自动化业务流程。而工作流管理系统是不必事先知道问题域的相关信息的。工作流系统将业务流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活（当然你也要花精力编写业务流程的规格化描述）。这就是为什么说工作流系统和专门系统是相互补充的。工作流系统可以用来管理全局的业务流程。如果专门应用支持你所需要的业务流程，那么使用专门应用。在此讨论的工作流系统的第一种使用方式就是：结合所有的专门应用，使用工作流系统构建一个EAI平台。

    工作流系统能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流系统都有一个方便的机制，来生成执行任务的表单。对于专注于ISO 或者CMM认证的组织，采用这种方式使用工作流系统能够显著提高生产率。 不用将过程用文字的形式写在纸上，工作流系统使你通过流程定义建模实现过程的自动化（如使用基于Web的应用）。

    工作流系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在前面我们谈到，专门应用将指定问题域相关的业务流程固化在软件中。开发专门应用的公司也可以将工作流引擎嵌入到他们的软件中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用（不重复发明轮子）和应用软件的可维护性。

The case for workflow

    对于引入工作流的组织，能够在软件开发和业务两个层次受益。

方便开发

    工作流管理系统能够简化企业级软件开发甚至维护。

• 降低开发风险 - 通过使用状态和动作这样的术语，业务分析师和开发人员使用同一种语言交谈。这样开发人员就不必将用户需求转化成软件设计了。
• 实现的集中统一 -业务流程经常变化，使用工作流系统的最大好处是：业务流程的实现代码，不再是散落在各种各样的系统中 。
• 加快应用开发 - 你的软件不用再关注流程的参与者，开发起来更快，代码更容易维护。

业务流程管理 (BPM)

    在自动化业务流程之前，分析并将它们规格化是一件艰苦但会有很好回报的工作。e-workflow.org对于分析流程能够带了的益处有不错的阐述：

• 提高效率 - 许多流程在自动化过程中会去除一些不必要的步骤
• 较好的流程控制 - 通过标准的工作方法和跟踪审计，提高了业务流程的管理
• 改进客户服务 - 因为流程的一致性，提高了对客户响应的可预见性
• 灵活 - 跨越流程的软件控制，使流程可以按照业务的需要重新设计。
• 业务流程改进 - 对流程的关注，使它们趋向于流畅和简单

    我认为他们还遗漏了一个使用工作流系统最重要的因数：提高对迭代开发的支持。如果软件中业务流程部分不容易更改，组织就会花很大的精力在开发前的业务流程分析中，希望一次成功。但可悲的是，在任何软件项目开发中，这都很少能实现。工作流系统使得新业务流程很容易部署，业务流程相关的软件可以一种迭代的方式开发，因此使用工作流系统使开发更有效、风险更低。

缺失的一环（Missing link）

    我确实认为工作流系统是企业应用开发中缺失的一环。将企业业务流程逻辑在企业级软件中实现的缺省方式是分散的。这意味着业务流程逻辑散布在各种系统中，如EJB、数据库触发器、消息代理等等。这样得到的软件难于维护，结果，企业只能将改变业务流程软件作为最后的选择。他们经常能够做的是，改变流程以适应软件。上述问题也适用于采用大型外部ERP软件包的企业。进一步，假设我们认识到这个问题，并打算将一个流程相关的代码都集中起来。对于一个流程来说这很不错，但当你要实现多个流程时，你会看到管理状态和流程变量的代码被到处复制。最后，我们会整理这些代码放到一个集中的库中。好，...这就是一个工作流管理系统了，不用费心自己来实现，你可以从本文后面的列表中选择一个。

A closer look

WFMS interfaces

    一个工作流管理系统以流程定义作为输入。在这里，可以将流程定义看作UML活动图、UML状态图或者有限状态机。在提交一张费用单据、申请休假、要求一个报价、...之后，工作流系统负责维护这些流程定义的执行状态和上下文。为此，需要通知工作流系统状态的变化。运行流程的状态变化可以记录下来，以备监控管理。

Figure 2: Interfaces of a WFMS

• 定义   工作流系统的定义接口使流程开发人员能够部署流程定义。注意，这里的“流程开发人员”可以是业务分析师和软件开发人员的组合。

  圈套（Pitfall） 许多工作流管理系统的开发商想使你相信，通过使用他们的图形化流程开发工具，只要业务分析师就可以生成流程定义。这种幻想源于“编程很难”这样的事实。开发商的销售人员喜欢说“看，你不用写一行代码”。不用写代码是好事，可大部分开发商在这点上走的太远，忽略了在某些场合提供一种将代码集成到流程定义中的机制是很适合的。在将工作流系统作为EAI平台时，必须在流程中集成代码。开发流程定义需要业务分析师和软件开发人员的合作。一个好的图形流程设计工具应该能够支持这种合作。

• 执行   执行接口使用户和系统可以操作流程实例。流程实例是流程定义的执行。流程定义的控制流通过状态机描述。执行接口的两个主要方法是启动一个流程实例和通知工作流系统一个状态结束了。
• 应用   应用接口代表了由工作流系统发起的工作流系统和外部系统之间的交互。当一个用户或系统操作一个流程实例的运行时，会生成一些事件（如一个迁移的执行）。流程定义中可以指定一段响应一个事件的可执行代码逻辑，这段代码和组织内外部的其他系统打交道。
• 监控   管理人员通过监控接口获得流程运行的确切数据。有时，运行日志也可用于审计。

流程定义的四个层次

    在下面这部分，我尝试回答这样的问题“什么是流程定义包括的内容？”。这是从各种规范和工具所使用模型的原则和概念中总结得来的，反映了大部分模型中通用的基本思想。流程定义的内容可以分为四个不同的层次：状态（state）、上下文（context）、程序逻辑（programming logic）和用户界面（UI）。

状态层

    所有状态和控制流的表述，都属于业务流程的状态层。标准编程语言中的控制流来源于Von Neuman体系。控制流定义了必须被执行的指令的顺序，控制流由我们书写的命令、if语句、循环语句等确定。在业务流程中的控制流基本与此一致。但在业务流程中不是使用命令而是使用状态作为基本元素。

    在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。状态的意思就像“现在X系统或某某人必须作某些事，在此等待直到参与者通知这些任务已完成”。状态定义了一种对外部提供结果的依赖。状态典型的例子是批准步骤（step）。

    流程定义中的状态也指定了执行依赖于哪个参与者。在活动图中，泳道（swimlanes）的标注代表这些参与者的名字。工作流系统使用这些信息构建任务列表，这是一般工作流系统都有的功能。如前所述，参与者可以是人也可以是系统。对于需要人参与的状态，工作流系统必须在运行时计算出具体的个人。这样的计算使工作流系统必须依赖于组织结构信息。关于这方面的一篇非常有趣的文章是在further reading section提到的“工作流应用中的组织管理”（ 'Organizational Management in Workflow Applications'）。

    流程定义的控制流包含一组状态和它们之间的关系。状态之间的逻辑关系描述了哪些执行路径可以同时执行，那些不可以。同步执行路径用分叉（forks）和联合（joins）建模，异步执行路径用判断（decisions）和合并（ merges）建模。注意在大多数模型中，在每个状态之前都有一个隐式合并。

    UML活动图经常被用来做业务流程建模。作为一种直观和通用的表达，活动图在图形表述上有一个主要问题，就是没有区分状态和动作，它们都用活动来表示。缺少这种区分（导致状态概念的缺失）是学术派对UML活动图的主要批评。UML活动图的第二个问题是在UML2.0版中引入的。当多个迁移（transitions）到达一个活动时，以前的版本规定这是一个缺省合并（merge），在2.0版中规定这是一个需要同步的缺省联合（join）。在我看来，UML活动图的图形部分仍旧可以用来对业务流程状态层次建模，只要使用时对两条构建语义作如下的变化：

1. 在用图形表述业务流程时，只建模状态层（状态和控制流），不要包括动作。这意味着图形中的矩形都是状态而不是活动
2. 如果多个迁移到达一个状态，缺省定义为不需要同步的合并（merges）

    在流程运行过程中，工作流系统用一个令牌（token）作为指针跟踪流程的状态。这相当于Von Neuman体系中的程序计数器。当令牌到达一个状态时，它被分配给工作流系统等待的外部参与者。外部参与者可以是个人、组织或者计算机系统。我们定义流程运行的执行人或系统为“参与者”（actor）。只有在工作流系统将令牌分配给一个参与者时，才需要访问组织结构信息。工作流系统通过分配令牌构建任务列表。

上下文层

    流程上下文变量（process context variable） ，或简称变量，是与流程实例相关的变量。流程开发人员可以使用流程变量存储跨越流程实例整个生命周期的数据。一些工作流管理系统有固定数目的数据类型，另一些你可以定义自己的数据类型。

    注意变量也可以用来存放引用（ references）。一个变量可以引用如数据库中的记录、网络上的文件。什么时候使用引用，取决于使用引用数据的其他应用。

    和流程变量相关的另一个令人感兴趣的方面是：工作流系统如何将数据转化为信息。工作流是用于组织内部跨越各种异构系统实现任务和数据协同的。对于业务流程中人工执行的任务，工作流系统负责从其他相关系统，如SAP、数据库、CRM系统、文档管理系统收集数据。在业务流程的每一个人工步骤，只有相关联的数据项被从异构系统中收集和计算。通过这种方式，从不同系统来的数据被转换并展现为信息。

程序逻辑层

    如前所述，动作是在流程运行过程中，工作流系统响应指定的事件（event）执行的一段程序逻辑（programming logic）。程序逻辑可以是二进制或源代码形式的、用任何语言或脚本编写的软件。程序逻辑层是所有这些软件片断和关于在什么事件发生时调用它们的信息的组合。程序逻辑的例子包括发Email、通过消息代理发消息、从ERP系统中拿数据和更新数据库。

用户界面层

工作流全景

可执行流程与工作流管理系统的比较（Executional processes versus a WFMS）

    当前在BPM领域中，关于可执行业务流程的规范有趋向于统一集中的趋势。 XLANG, WSFL 和BPML合并为基于交互（消息交换）的BPEL。BPEL在面向服务体系结构(SOA)的大背景下定义。它的前提条件之一是涉及的服务必须用WSDL声明。BPEL规定了一套XML语法，这套语法可以看作一种编程语言，用来描述包括对WSDL定义的服务调用的控制流。

    在可执行业务流程和基于状态的工作流管理系统所使用的方法中，我注意到了三点主要的区别：

• 基于状态与面向消息：基于状态的工作流系统以状态（或者活动）概念为中心。工作流引擎维护状态并计算从一个状态到另一个状态的迁移。另一方面，像BPEL这样的可执行流程以对输入消息响应的定义为中心。一组这些响应外加其他信息（other bells and whistles）可以看作一个业务流程。这也解释了为什么BPEL可以看作是对基于状态的工作流系统的某些方面的补充。一个响应输入消息的BPEL onMessage事件处理器，可以在工作流状态之间的迁移中执行。
• 流程实例ID与消息相关处理：可执行业务流程的复杂性之一来自消息相关性的处理。流程描述的一部分必须说明BPEL引擎如何从输入消息中确定具体流程的标识。这必须基于输入消息的一个数据项。而工作流系统在每个流程实例生成同时生成了实例ID，客户端在后续调用引擎API时使用这个ID。
• 工作流引擎API与抽象服务端点（endpoint）：工作流系统提供一组集中的API，客户端通过调用API完成与所有流程实例的交互。在可执行业务流程中，每个流程表现为一个服务。这意味着对于每个流程定义都有一个不同的访问点。

学术界

开放源代码项目

    最后我们看看真实世界中的工作流管理系统。选择一个工作流管理系统是一件困难的事情，但有选择总比没有选择好。:-) 本文阐述工作流基本概念的目的之一，就是使你能够作更好的选择。但我也意识到，对于现在的软件架构师来说，选择工作流系统是一件最具挑战性的工作。

    下面的列表来源于三个地方：my previous article, the list of Carlos E Perez, 和 list by Topicus.

• jBpm - jBpm是本文作者编写的一个灵活可扩展的工作流管理系统。作为jBpm运行时server输入的业务流程使用简单强大的语言表达并打包在流程档案中。jBmp将工作流应用开发的便利性和杰出的企业应用集成（EAI）能力结合了起来。jBmp包括一个Web应用程序和一个日程安排程序。jBmp是一组J2SE组件，可以作为J2EE应用集群部署。
• OpenEbXML - OpenebXML项目致力于提供一个ebXML框架，主要支持不久将由 UN/CEFACT和OASIS发布的ebXML规范2.0版。
• Werkflow - Werkflow是一个灵活可扩展的基于流程和状态的工作流引擎。它的目标是满足可以想象的所有工作流程，从企业级的业务流程到小范围的用户交互流程。通过使用可插拔和分层结构，可以方便地容纳各种工作流语义。
• OSWorkflow - OSWorkflow最独到之处是绝对的灵活。
• wfmOpen - WfMOpen是WfMC和OMG中所谓工作流设施（workflow facility） (工作流引擎)的J2EE实现。工作流通过扩展的XPDL描述。
• OFBiz - OFBiz工作流引擎基于WfMC和OMG的规范，使用XPDL作为流程定义语言。
• ObjectWeb Bonita - Bonita是一个符合WfMC规范、灵活的协同工作流系统。 对于各种动作如流程概念建模、定义、实例化、流程控制和用户交互等提供了全面的集成图形工具。 100% 基于浏览器、使用SOAP和XML数据绑定技术的Web Services封装了已有的工作流业务方法并将它们以基于J2EE的Web Service形式发布。基于活动预测模型的第三代工作流引擎。
• Bigbross Bossa -速度非常快、轻量级的引擎，使用富有表达能力的Petri网定义工作流，不要求关系数据库，使用简单，能和Java应用集成。事实上，它是按嵌入式设计的。
• XFlow - XFlow运行于EJB和servlet容器中。
• Taverna - Taverna项目的目标是提供一种语言和软件工具，方便在eScience中使用工作流和分布计算技术。
• Enhydra Shark - Shark完全基于WfMC和OMG标准，使用 XPDL作为工作流定义语言。流程和活动的存储使用Enhydra DODS。
• PowerFolder - PowerFolder包括开发人员使用的studio，管理环境和一个运行时引擎。
• Breeze - Breeze一个轻量级、跨平台、基于组件的工作流引擎原型。
• Open Business Engine - Open Business Engine是一个开放源码的Java工作流引擎，支持WfMC规范，包括接口1（XPDL）、接口2/3（WAPI）和接口5。OBE为活动的运行提供了一个可控的集中环境。OBE主要基于J2EE实现。
• OpenWFE - OpenWFE是一个开放源码的Java工作流引擎。 它包括可升级的三个组件：引擎、工作列表和Web界面。它的流程定义语言虽然使用XML格式，其灵感来源于 Scheme，一种Lisp方言。
• Freefluo - Freefluo是一个使用Web Service的工作流协同工具，可以处理WSDL的Web Service调用。支持两种XML格式的工作流语言：IBM的WSFL和XScufl。Freefluo非常灵活，它的核心是不与任何工作流语言或执行架构关联的可重用协同框架。 Freefluo包括可执行使用WSFL一个子集描述的工作流的运行库。
• ZBuilder - ZBuilder3是第二代工作流开发管理系统，也是一个开放源码产品。它为不同的工作流引擎和工作流定义了一组标准的JMX管理接口。
• Twister - Twister的目标是提供新一代、易集成、应用Java领域中最新成果、面向B2B的工作流解决方案。流程引擎基于BPEL业务流程规范和Web Service标准。
• Con:cern - con:cern工作流引擎基于扩展的案例（case）处理方法，流程由一组具有前后条件的活动组成。

商业软件提供商

• Bea's WLI
• Carnot
• Dralasoft
• Filenet
• Fujitsu's i-Flow
• IBM's holosofx tool
• Intalio
• Joinwork （译者加:-) ）
• Lombardi
• Oakgrove's reactor
• Oracle's integration platform
• Q-Link
• SAP's NetWeaver
• Savvion
• Seebeyond
• Sonic's orchestration server
• Staffware
• Ultimus
• Versata
• WebMethod's process modeling

工具目录

• http://dmoz.org/Computers/Software/Workflow/Products/
• A collection of links to tools for modelling business processes and workflows maintained by Bart-Jan Hommes at TU Delft, the Netherlands.

规范

    Michael zur Muehlen作了一个所有工作流相关规范的介绍性的幻灯片，很不错。

    我同意John Pyke 和 Wil van der Aalst 的观点：工作流标准还处于制定阶段。现在存在大量相互丛叠的规范。

    在我看来，导致规范如此之多而同时每个规范的应用又很有限的原因是，在工作流最基础概念上大家达成的共识很少。工作流是最容易让你感到心烦的话题，因为工作流本身的概念会和其他相关概念和技术混淆在一起。可以举一个具体的例子，比如说工作流完全是对Web Service的补充。你可以通过暴露接口以Web Service的方式访问一个工作流管理系统，但是不能假定总是必须通过Web Service接口访问工作流系统接口。一些规范造成了这样的假设。除了Web Service，其他容易混淆的概念和技术包括：Email、流程之间的通讯、Web应用和组织结构。

    在工作流领域第一个致力于标准化工作的是Workflow Management Coalition (WfMC)，开始于 1993。 WfMC发布的参考模型很不错，它定义了工作流管理系统和其他相关部分之间的接口。WfMC的另一项成果是XPDL规范。 XPDL定义了描述工作流声明部分（declarative part）的XML结构。我个人认为，参考模型和XPDL是目前最好的规范。

• JSR 207: Java的流程定义 -是由Java Community Process (JCP) 发起，如何在J2EE应用服务器中实现业务流程自动化的标准。其基本模型是定义一个特殊类型的ejb session bean，作为一个业务流程的接口。JSR207标准化一组XML元标记（meta tags）作为JSR175元数据的一部分。JSR207 将session bean和元数据作为ejb容器的输入，然后生成绑定方法的代码，这些方法在元数据中描述。此规范还处于初级阶段，没有发布任何内容。专家小组成立于 March 2003.
• WfMC's XPDL - WfMC是由约300家成员参加的组织，基于参考模型定义了一系列的标准。参考模型用用例（use case）的形式描述了工作流系统和其他相关部分之间的关系。XPDL是WfMC制定的描述业务流程控制流（control flow ）的XML格式规范。
• ebXML's BPSS - ebXML是协同流程的相关标准集，主要关注不同公司流程之间的通讯。可以看作EDI的继承者。 ebXML是由OASIS和UN/CEFACT联合发起。 BPSS 是ebXML的规范，其中的概念和本文阐述的很接近。
• BPMI's BPML & WSCI - (Intalio, Sun, SAP, ...)BPMI 也定义了一个规范 (BPMN) ，描述如何将“可执行”业务流程可视化的表现。
• BPEL - (Microsoft, BEA, IBM, SAP & Siebel) BPEL由一系列基于消息交换的规范（ XLANG, WSFL, BPML）产生。还有一个将此规范引入到Java的提案: BPELJ。 此规范描述如何处理输入的消息，而不是对流程状态进行建模。就像本文提到的，它不是一个关于业务流程规格化定义的规范。简单的说，可以将它看作XML形式的编程语言，提供将WSDL-Services组合成控制流的能力。顾名思义，此规范重点在（也不只限于）Web Service。
• OMG's Workflow management facility - 基于WfMC规范，定义如何向CORBA转换。
• UML - UML定义了建模和设计软件系统的9类图。每类图包括可视化的表示和语义。其中活动图的目的就是要可视化的表现业务流程。 注意到在一个流程定义包含四个层次的内容，我想指出的是：一个流程定义包含的内容远远多于它的可视化部分。UML只涉及了可视化部分。
• RosettaNet - RosettaNet主要定义了一组 Partner Interface Processes (PIP). 一个 PIP 描述了一个有两个交易参与者、包括消息格式的流程。
• UBL - The Universal Business Language (UBL)定义了用于不同组织间通讯的XML文档标准库。可以看作是对ebXML的补充，因为ebXML只定义了建立组织间流程的基础。此规范的竞争对手是 RosettaNet标准中的一个子集。

结论

    我在本文中指出工作流市场还属于年轻而又混乱（young and wild）的阶段，但已经有可靠的工具存在了:

1. 到目前，像J2EE和.NET这样成熟的集成平台才可用。在这样一个平台上运行工作流管理系统才能真正发挥工作流系统的附加价值。这也是为什么只有在今天，工作流系统才被重新发现。
2. 在 'The case for workflow'一节，我们介绍了引入工作流管理系统，是如何同时在技术和业务上带来投资回报的。
3. 工作流在技术发展曲线的位置表明，BPM和工作流中使用的概念还需要明确。
4. “开放源代码项目”和“商业软件提供商”列表中的工具，可以让你获得工作流和业务流程管理的益处。

    从以上所有这些中能得到的结论是：

1. 规范还没有成熟，没有标准被大范围采用
2. 对于现在想应用BPM的公司来讲，比较工作流系统是一个极其困难的挑战
3. 尽管标准化工作慢了一拍，可好的工作流管理系统还是有的。这对于已经在挑选工作流系统的组织来说是一个好消息。

    我希望本文能够激发你对工作流的兴趣并且能够为你进行有效的对比提供正确的背景知识。

Further reading

• Workflow Patterns -Wil van der Aalst教授的工作流模式学术研究网站
• ebpml.org - 有关业务流程管理和工作流的网站，信息量大、全面
• Business process management group - The Business Process Management Group (founded in 1992) is a global business club exchanging ideas and best practice in business process and change management.
• Enix - 英国流程管理顾问公司，在网站上有不错的内容
• ebizq.net - Commercial community that has booths, webinars and other interesting stuff put together in a nice website.
• An introduction to petri nets - The title says it all.
• Organizational Management in Workflow Applications- An interesting article that discusses the relation between business processes and the organisational data involved.
• Web services orchestration - an HP-paper that reviews the emerging technologies tools and standards. (Januari 2003)
• Business process standards for web services - An article that discusses the various aspects involved in workflow and BPM.

　　首先，我们从一个高度来抽象一下表现层框架应有的技术架构，下图可以说所有表现层框架技术都必须实现的功能架构图：

　　当然，我们不必废话罗嗦MVC模式，MVC模式是基准模式，现在框架技术已经不必再拼是否是MVC模式了。 在上图MVC模式基础上，一个表现层框架无外乎要实现图中的三个功能：

1.在当前页面能够显示一个组件对象的内容；而不是象纯JSP那样，需要在Jsp页面写入“调用对象方法”的Java代码。

2.当用户按下页面的提交按扭或链接后，事件发生，这时应该触发服务器端并将当前页面的参数提交给服务器。这种机制表现在Form表单提交和有参数的链接<a href=""></a>

3.从一个页面视图直接跳转到另外一个页面视图，单纯的导航作用。

我们通过下表来比较这 三种框架在实现上图各个功能时技术细节，从而得出他们的异同点和偏重点。

Struts组件编程模型

　　Struts实现组件编程时有一些复杂：经常为一个页面中需要引入多个组件而头疼，因为Struts中无法直接引入多个组件，必须绕一些圈子:

　　一般分两种情况：如果同一个Action就可以对付这些组件，那么在这种情况下有两个办法：

1.将这多个组件装入一个ActionForm中，如使用MapForm等机制；

2.手工将多个组件装入request/session等scope中，然后根据其名称在jsp中获得。

　　这两个方法都有缺点： 第一种办法经常一个ActionForm弄得面目全非，变成一个大杂烩，违反了OO分派封装的原则；第2种办法其实又回到jsp编程；

　　第二种情况，如果这些组件必须有预先由不同的Action来处理，每个组件必须经过Action -->ActionForm流程，在这种情况下有两种办法：

1.使用Tiles, 不同流程输出到同一个页面的不同区域。是一种并行处理方式。

2. 对多个流程首尾相连，第一Action forward结果是第二个Action，最后输出一个Jsp，在这个jsp中就可以使用前面多个流程的多个ActionForm了，这属于串行方式。

Struts组件模型缺点

　　Struts组件编程必须限定在Action/ActionForm/JSP这三个框框中做文章，难度相对比较大，而Tapestry/JSF则没有太多这些技术框框限制，两者在组件编程方面更让编程者自由一些，方便一些，这也是组件型框架的优势吧。

Struts标签库

　　在Struts中，经常需要使用标签库来显示组件ActionForm中内容，这就涉及到一个结合的问题，标签库是别人写的，参考Struts的标签库用法，而组件是自己的，难度和麻烦就体现在这个结合点上。

　　JSF基本思路和Struts差不多，只不过换了不同标签库，也需要标签库+组件的结合思考，不过因为组件这里是通用组件，没有什么限制，所以这样比Struts要轻松一些。

　　Tapestry使用了组件库概念替代了标签库，没有标签库概念，这样就没有标签库和自己的组件需要结合的问题，都是组件的使用，组件中分Tapestry标准组件和自己定义的组件，这也是接触了Jsp体系的人学习Tapestry面临的一个思路转换。

　　具体以页面跳转为例子，页面跳转是靠链接<a href="目标"></a> 实现，链接是页面经常使用的元素。

　　Struts提供的html:link在频繁使用就特别不方便，尤其在传递多个参数时：其中html:link的page值，是跳转对方页面或Action的path，这个path一般需要到struts-config.xml查找Action的相应path,一旦配置文件path值修改，涉及到这个所有相关页面都要修改。

　　JSF将链接概念划分两个方面：导航性质和事件激活，在导航方面还是需要到配置faces-config查询Navigation的from-outcome的值。

　　由于Tapestry没有标签库概念，只有组件或页面两个概念，因此，链接跳转目标要么是组件，要么是页面，简洁简单，它没有多余的path概念，就是组件名，也就是对象名称，组件名称和path名称合二为一。

总结

　　JSF在很大程度上类似Struts，而不是类似Tapestry，可以说是一种Struts 2.0，都是采取标签库+组件的形式，只是JSF的组件概念没有象Struts那样必须继承ActionForm的限制；JSF在事件粒度上要细腻，不象Struts那样，一个表单一个事件，JSF可以细化到表单中的每个字段上。

　　JSF只有在组件和事件机制这个概念上类似Tapestry，但是不似Tapestry那样是一个完全组件的框架，所以，如果你做一个对页面要求灵活度相当高的系统，选用Tapestry是第一考虑。

　　Struts/JSF则适合在一般的数据页面录入的系统中，对于Struts和JSF的选用，我目前个人观点是：如果你是一个新的系统，可以直接从JSF开始；如果你已经使用Struts，不必转换，如果需要切换，可以将JSF和Tapestry一起考虑。

　　另外，JSF/Tapestry不只是支持Html，也支持多种客户端语言如WML或XUI等。

　　这三者之间关系：如果说Struts是左派；那Tapestry则是右派；而JSF则是中间派，中庸主义是SUN联盟的一贯策略。

　　当然，你也可以发表你在实践中这三者任何一个的使用感受，以使得后来者有一个比较。