前 言

    本文没有抛出可运行的范例，仅仅是程序片断而已，不过在 OSWorkflow 的 Wiki 上，Quake Wang 已把官方入门教程完整地翻译成中文了，有兴趣的读者可去阅读。关于 OSWorkflow 更加细节性的内容，可参考官方手册，相信你在了解了入门教程后，可轻松阅读官方手册。
   
OSWorkflow 概念

    在商用和开源世界里，OSWorkflow 都不同于这些已有的工作流系统。最大不同在于 OSWorkflow 有着非常优秀的灵活性。在开始接触 OSWorkflow 时可能较难掌握（有人说不适合工作流新手入门），比如，OSWorkflow 不要求图形化工具来开发工作流，而推荐手工编写 xml 格式的工作流程描述符。它能为应用程序开发者提供集成，也能与现有的代码和数据库进行集成。这一切似乎给正在寻找快速“即插即用”工作流解决方案的人制造了麻烦，但研究发现，那些“即插即用”方案也不能在一个成熟的应用程序中提供足够的灵活性来实现所有需求。
   
OSWorkflow 优势

    OSWorkflow 给你绝对的灵活性。OSWorkflow 被认为是一种“低级别”工作流实现。与其他工作流系统能用图标表现“loops(回路)”和“conditions(条件)”相比，OSWorkflow 只是手工“编码(coded)”来实现的。但这并不能说实际的代码是需要完全手工编码的，脚本语言能胜任这种情形。OSWorkflow 不希望一个非技术用户修改工作流程，虽然一些其他工作流系统提供了简单的 GUI 用于工作流编辑，但像这样改变工作流，通常会破坏这些应用。所以，进行工作流调整的最佳人选是开发人员，他们知道该怎么改变。不过，在最新的版本中，OSWorkflow 也提供了 GUI 设计器来协助工作流的编辑。

    OSWorkflow 基于有限状态机概念。每个 state 由 step ID 和 status 联合表现（可简单理解为 step 及其 status 表示有限状态机的 state）。一个 state 到另一 state 的 transition 依赖于 action 的发生，在工作流生命期内有至少一个或多个活动的 state。这些简单概念展现了 OSWorkflow 引擎的核心思想，并允许一个简单 XML 文件解释工作流业务流程。

OSWorkflow 核心概念
   
step（步骤）
    一个 step 是工作流所处的位置。可能从一个 step 流转到另外一个 step（或者有时候还是停留在一样的 step）。举例来说，一个 OA 系统的请假流程，它的 step 名称可能有“本部门审批阶段”，“办公室审批阶段”，“总经理审批阶段”等。
 
status（状态）
    工作流 status 是一个用来描述工作流程中具体步骤状态的字符串。OSWorkflow 的有 Underway（进行中）、Queued（等候处理中）、Finished（完成）三种 status。
 
action（动作）
    action 指定了可能发生在 step 内的转变，会导致 step 的变更。在 OA 系统中，“本部门审批阶段”可能有“拒绝”或“批准”两个 action。action 和 step 之间的关系是，step 说明“在哪里”，action 说明“可以去哪里”。 一个 action 典型地由两部分组成：可以执行此动作的 condition（条件），以及执行此动作的 result（结果）。
 
condition（条件）
    类似于逻辑判断，可包含“AND”和“OR”逻辑。比如一个请假流程中的“本部门审批阶段”，该阶段利用“AND”逻辑，判断流程状态是否为等候处理中，以及审批者是否为本部门主管。
   
result（结果）
    Result 代表指向新的 step 及其 step status，也可能进入 split 或者 join。Result 分为两种， contidional-result （有条件结果），只有条件为真时才使用该结果，和 unconditional-result（无条件结果），当条件不满足或没有条件时使用该结果。

split/join（分离/连接）
流程的切分和融合。很简单的概念，split 提供多个 result；join 则判断多个 current step 的状态，提供一个 result。

OSWorkflow 包用途分析及代码片断
   
com.opensymphony.workflow
    该包为整个 OSWorkflow 引擎提供核心接口。例如 com.opensymphony.workflow.Workflow 接口，可以说，实际开发中的大部分工作都是围绕该接口展开的，该接口有 BasicWorkflow、EJBWorkflow、OfbizWorkflow 三个实现类。

com.opensymphony.workflow.basic
    该包有两个类，BasicWorkflow 与 BasicWorkflowContext。BasicWorkflow 不支持事务，尽管依赖持久实现，事务也不能包裹它。BasicWorkflowContext 在实际开发中很少使用。

  public void setWorkflow(int userId) {   Workflow workflow = new BasicWorkflow(Integer.toString(userId));  }

com.opensymphony.workflow.config
    该包有一个接口和两个该接口的实现类。在 OSWorkflow 2.7 以前，状态由多个地方的静态字段维护，这种方式很方便，但是有很多缺陷和约束。最主要的缺点是无法通过不同配置运行多个 OSWorkflow 实例。实现类 DefaultConfiguration 用于一般的配置文件载入。而 SpringConfiguration 则是让 Spring 容器管理配置信息。

  public void setConfiguration(SpringConfiguration configuration) {   SpringConfiguration configuration = configuration; workflow.setConfiguration(configuration);  }

com.opensymphony.workflow.ejb
    该包有两个接口 WorkflowHome 和 WorkflowRemote。该包的若干类中，最重要的是 EJBWorkflow，该类和 BasicWorkflow 的作用一样，是 OSWorkflow 的核心，并利用 EJB 容器管理事务，也作为工作流 session bean 的包装器。

com.opensymphony.workflow.loader
    该包有若干类，用得最多的是 XxxxDescriptor，如果在工作流引擎运行时需要了解指定的动作、步骤的状态、名字，等信息时，这些描述符会起到很大作用。

  public String findNameByStepId(int stepId,String wfName) {   WorkflowDescriptor wd = workflow.getWorkflowDescriptor(wfName);   StepDescriptor stepDes = wd.getStep(stepId);   return stepDes.getName();  }

com.opensymphony.workflow.ofbiz
    OfbizWorkflow 和 BasicWorkflow 在很多方面非常相似，除了需要调用 ofbiz 的 TransactionUtil 来包装事务。

com.opensymphony.workflow.query
    该包主要为查询而设计，但不是所有的工作流存储都支持查询。通常，Hibernate 和 JDBC 都支持，而内存工作流存储不支持。值得注意的是 Hibernate 存储不支持混合型查询（例如，一个查询同时包含了 history step 上下文和 current step 上下文）。执行一个查询，需要创建 WorkflowExpressionQuery 实例，接着调用 Workflow 对象的 query 方法来得到最终查询结果。

  public List queryDepAdmin(int userId,int type) {   int[] arr = getSubPerson(userId,type);   //构造表达式   Expression[] expressions = new Expression[1 + arr.length];   Expression expStatus = new FieldExpression(FieldExpression.STATUS,     FieldExpression.CURRENT_STEPS, FieldExpression.EQUALS, "Queued");   expressions[0] = expStatus;   for (int i = 0; i < arr.length; i++) {    Expression expOwner = new FieldExpression(FieldExpression.OWNER,      FieldExpression.CURRENT_STEPS, FieldExpression.EQUALS,      Integer.toString(arr[i]));    expressions[i + 1] = expOwner;   }   //查询未完成流编号   List wfIdList = null;   try {    WorkflowExpressionQuery query = new WorkflowExpressionQuery(      new NestedExpression(expressions, NestedExpression.AND));    wfIdList = workflow.query(query);   } catch (Exception e) {    e.printStackTrace();   }

com.opensymphony.workflow.soap
    OSWorkflow 通过 SOAP 来支持远端调用。这种调用借助 WebMethods 实现。

com.opensymphony.workflow.spi
    该包可以说是 OSWorkflow 与持久层打交道的途径，如当前工作流的实体，其中包括：EJB、Hibernate、JDBC、Memory、Ofbiz、OJB、Prevayler。

  HibernateWorkflowEntry hwfe = (HibernateWorkflowEntry) getHibernateTemplate()      .find("from HibernateWorkflowEntry where Id="          + wfIdList.get(i)).get(0);

com.opensymphony.workflow.util
该包是 OSWorkflow 的工具包，包括了对 BeanShell、BSF、EJB Local、EJB Remote、JNDI 的支持。

小 结

    由于本人所在公司希望在 OA 系统中引入工作流引擎，经过分析决定采用 OSWorkflow 引擎。利用 OSWorkflow，已经在系统中实现了请假条流程原型，该流程结合 OA 系统中已有的 RBAC 模型进行逐级审核。我个人认为要用 OSWorkflow 让某个流程跑起来似乎很麻烦，主要是需要扩展和自己实现的太多。
   
    另外，引用一段 Quake Wang 的原话：电子政务/OA 如果要使用workflow engine的话，shark，jbpm 之类的workflow engine有点杀鸡用牛刀的味道。shark 和 jbpm 都强迫你使用它的用户模型，怎样把企业现有的用户模型（包括组织结构）映射过来是很繁琐的事情，比如常见的 OA 应用中，申请者对应的部门负责人为下一个流程的人工参与者，使用 shark 或者 jbpm 都得绕一圈，通过现有的人力资源系统，获得用户，再对应过来。这还仅仅是一个简单的需求，更不用说国内企业千奇百怪的组织结构，以及各种特殊流程，用 wfmc 或者其他所谓的 workflow 通用标准去做不怎么标准的事情。吃力不讨好。用 osworkflow 这种基于状态机的 workflow engine 反而会轻松很多，而且它也没有强迫你使用它的用户模型。另外纠正一点：osworkflow 不仅仅支持简单的 BeanShell，还支持 java class，bsf，ejb。如果做电子政务/OA 的话，觉得目前 osworkflow 是最适用的 opensource workflow engine。


请注意！引用、转贴本文应注明原作者：Rosen Jiang 以及出处：http://www.blogjava.net/rosen

来源：醉书生札记

http://spaces.msn.com/tuxw/Blog/cns!1p1KRL2snDHMdTagFMfJCgKg!1341.entry

    <servlet>
        <servlet-name>dwr-invoker</servlet-name>
        <display-name>DWR Servlet</display-name>
        <description>Direct Web Remoter Servlet</description>
        <servlet-class>uk.ltd.getahead.dwr.DWRServlet</servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>true</param-value>
        </init-param>
    </servlet>

    <servlet-mapping>
        <servlet-name>dwr-invoker</servlet-name>
        <url-pattern>/dwr/*</url-pattern>
    </servlet-mapping>

<dwr>
    <allow>
        <convert converter="bean" match="dwr.sample.Apartment"/>
        <create creator="new" javascript="ApartmentDAO" class="dwr.sample.ApartmentDAO">
            <include method="findApartments"/>
            <include method="countApartments"/>
        </create>
    </allow>
</dwr>

  <script src='dwr/interface/ApartmentDAO.js'></script>
  <script src='dwr/engine.js'></script>
  <script src='dwr/util.js'></script>

function updateTotal() {
    $("resultTable").style.display = 'none';
    var bedrooms = document.getElementById("bedrooms").value;
    var bathrooms = document.getElementById("bathrooms").value;
    var price = document.getElementById("price").value;
    ApartmentDAO.countApartments(loadTotal, bedrooms, bathrooms, price);
}

function loadTotal(data) {
    document.getElementById("totalRecords").innerHTML = data;
}

function updateResults() {
    
    DWRUtil.removeAllRows("apartmentsbody");
    var bedrooms = document.getElementById("bedrooms").value;
    var bathrooms = document.getElementById("bathrooms").value;
    var price = document.getElementById("price").value;
    ApartmentDAO.findApartments(fillTable, bedrooms, bathrooms, price);
    $("resultTable").style.display = '';
}

function fillTable(apartment) {
    DWRUtil.addRows("apartmentsbody", apartment, [ getId, getAddress, getBedrooms, getBathrooms, getPrice ]);
}

 

 

利用 MSMQ（Microsoft Message Queue），应用程序开发人员可以通过发送和接收消息方便地与应用程序进行快速可靠的通信。消息处理为您提供了有保障的消息传递和执行许多业务处理的可靠的防故障方法。

MSMQ与XML Web Services和.Net Remoting一样，是一种分布式开发技术。但是在使用XML Web Services或.Net Remoting组件时，Client端需要和Server端实时交换信息，Server需要保持联机。MSMQ则可以在Server离线的情况下工作，将Message临时保存在Client端的消息队列中，以后联机时再发送到Server端处理。

显然，MSMQ不适合于Client需要Server端及时响应的这种情况，MSMQ以异步的方式和Server端交互，不用担心等待Server端的长时间处理过程。

 

虽然XML Web Services和.Net Remoting都提供了[OneWay]属性来处理异步调用，用来解决Server端长方法调用长时间阻碍Client端。但是不能解决大量Client负载的问题，此时Server接受的请求快于处理请求。

一般情况下，[OneWay]属性不用于专门的消息服务中。

 

1. 基本术语和概念（Basic terms and concepts）

“消息”是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。

 

消息被发送到队列中。“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。

 

“消息队列”是 Microsoft 的消息处理技术，它在任何安装了 Microsoft Windows 的计算机组合中，为任何应用程序提供消息处理和消息队列功能，无论这些计算机是否在同一个网络上或者是否同时联机。

 

“消息队列网络”是能够相互间来回发送消息的任何一组计算机。网络中的不同计算机在确保消息顺利处理的过程中扮演不同的角色。它们中有些提供路由信息以确定如何发送消息，有些保存整个网络的重要信息，而有些只是发送和接收消息。

 

“消息队列”安装期间，管理员确定哪些服务器可以互相通信，并设置特定服务器的特殊角色。构成此“消息队列”网络的计算机称为“站点”，它们之间通过“站点链接”相互连接。每个站点链接都有一个关联的“开销”，它由管理员确定，指示了经过此站点链接传递消息的频率。

 

“消息队列”管理员还在网络中设置一台或多台作为“路由服务器”的计算机。路由服务器查看各站点链接的开销，确定经过多个站点传递消息的最快和最有效的方法，以此决定如何传递消息。

 

2. 队列类型（Queue Type）

有两种主要的队列类型：由您或网络中的其他用户创建的队列和系统队列。

用户创建的队列可能是以下任何一种队列：

“公共队列”在整个“消息队列”网络中复制，并且有可能由网络连接的所有站点访问。

“专用队列”不在整个网络中发布。相反，它们仅在所驻留的本地计算机上可用。专用队列只能由知道队列的完整路径名或标签的应用程序访问。

“管理队列”包含确认在给定“消息队列”网络中发送的消息回执的消息。指定希望 MessageQueue 组件使用的管理队列（如果有的话）。

“响应队列”包含目标应用程序接收到消息时返回给发送应用程序的响应消息。指定希望 MessageQueue 组件使用的响应队列（如果有的话）。

 

系统生成的队列一般分为以下几类：

“日记队列”可选地存储发送消息的副本和从队列中移除的消息副本。每个“消息队列”客户端上的单个日记队列存储从该计算机发送的消息副本。在服务器上为每个队列创建了一个单独的日记队列。此日记跟踪从该队列中移除的消息。

“死信队列”存储无法传递或已过期的消息的副本。如果过期或无法传递的消息是事务性消息，则被存储在一种特殊的死信队列中，称为“事务性死信队列”。死信存储在过期消息所在的计算机上。有关超时期限和过期消息的更多信息，请参见默认消息属性。

“报告队列”包含指示消息到达目标所经过的路由的消息，还可以包含测试消息。每台计算机上只能有一个报告队列。

“专用系统队列”是一系列存储系统执行消息处理操作所需的管理和通知消息的专用队列。

在应用程序中进行的大多数工作都涉及访问公共队列及其消息。但是，根据应用程序的日记记录、确认和其他特殊处理需要，在日常操作中很可能要使用几种不同的系统队列。

 

3. 同步和异步通信（Synchronous VS. Asynchronous Communication）

队列通信天生就是异步的，因为将消息发送到队列和从队列中接收消息是在不同的进程中完成的。另外，可以异步执行接收操作，因为要接收消息的人可以对任何给定的队列调用 BeginReceive 方法，然后立即继续其他任务而不用等待答复。这与人们所了解的“同步通信”截然不同。

 

在同步通信中，请求的发送方在执行其他任务前，必须等待来自预定接收方的响应。发送方等待的时间完全取决于接收方处理请求和发送响应所用的时间。

 

4. 同消息队列交互（Interacting with Message Queues）

消息处理和消息为基于服务器的应用程序组件之间的进程间通信提供了强大灵活的机制。同组件间的直接调用相比，它们具有若干优点，其中包括：

• 稳定性 — 组件失败对消息的影响程度远远小于组件间的直接调用，因为消息存储在队列中并一直留在那里，直到被适当地处理。消息处理同事务处理相似，因为消息处理是有保证的。

• 消息优先级 — 更紧急或更重要的消息可在相对不重要的消息之前接收，因此可以为关键的应用程序保证足够的响应时间。

• 脱机能力 — 发送消息时，它们可被发送到临时队列中并一直留在那里，直到被成功地传递。当因任何原因对所需队列的访问不可用时，用户可以继续执行操作。同时，其他操作可以继续进行，如同消息已经得到了处理一样，这是因为网络连接恢复时消息传递是有保证的。

• 事务性消息处理 — 将多个相关消息耦合为单个事务，确保消息按顺序传递、只传递一次并且可以从它们的目标队列中被成功地检索。如果出现任何错误，将取消整个事务。

• 安全性 — MessageQueue 组件基于的消息队列技术使用 Windows 安全来保护访问控制，提供审核，并对组件发送和接收的消息进行加密和验证。

 

5. 在.Net环境下编写简单的Message Queue程序

（1）先安装Message Queuing Services

通过Control Panel，“Add/Remove Programs” – “Add/Remove Windows Components”步骤安装MSMQ。

MSMQ可以安装为工作组模式或域模式。如果安装程序没有找到一台运行提供目录服务的消息队列的服务器，则只可以安装为工作组模式，此计算机上的“消息队列”只支持创建专用队列和创建与其他运行“消息队列”的计算机的直接连接。

 

（2）配置MSMQ

打开Computer Management – Message Queuing，在Private Queues下创建MSMQDemo队列

 

（3）编写代码－简单演示MSMQ对象

MessageQueue 类是“消息队列”周围的包装。MessageQueue 类提供对“消息队列”队列的引用。可以在 MessageQueue 构造函数中指定一个连接到现有资源的路径，或者可在服务器上创建新队列。在调用 Send、Peek 或 Receive 之前，必须将 MessageQueue 类的新实例与某个现有队列关联。

 

MessageQueue 支持两种类型的消息检索：同步和异步。同步的 Peek 和 Receive 方法使进程线程用指定的间隔时间等待新消息到达队列。异步的 BeginPeek 和 BeginReceive 方法允许主应用程序任务在消息到达队列之前，在单独的线程中继续执行。这些方法通过使用回调对象和状态对象进行工作，以便在线程之间进行信息通讯。

// Send Message

private void btnSendMessage_Click(object sender, System.EventArgs e)

{

       // Open queue

       System.Messaging.MessageQueue queue = new System.Messaging.MessageQueue(".\\Private$\\MSMQDemo");

 

       // Create message

       System.Messaging.Message message = new System.Messaging.Message();

       message.Body = txtMessage.Text.Trim();

       message.Formatter = new System.Messaging.XmlMessageFormatter(new Type[] {typeof(string)});

 

       // Put message into queue

       queue.Send(message);

}

 

// Receive Message

private void btnReceiveMessage_Click(object sender, System.EventArgs e)

{

       // Open queue

       System.Messaging.MessageQueue queue = new System.Messaging.MessageQueue(".\\Private$\\MSMQDemo");

 

       // Receive message, 同步的Receive方法阻塞当前执行线程，直到一个message可以得到

       System.Messaging.Message message = queue.Receive();

       message.Formatter = new System.Messaging.XmlMessageFormatter(new Type[] {typeof(string)});

       txtReceiveMessage.Text = message.Body.ToString();

}

 

Demo界面：

******

关于MSMQ消息队列介绍文字来自于MSDN.

 

 

References:

1, MSDN, 消息队列（Message Queue）

来自：http://rickie.cnblogs.com/archive/2004/11/16/64345.aspx