刘文涛

swf有他先天的优点，就是用户交互的友好。
所以在看到论坛上沸沸扬扬的RIA，RCP后，
1、XUL看了好些文档，觉得还不错，但是大家的评论给我感觉有点穷途末路？而且是在浏览器基础上的，放弃；
2、XAML是微软的，……放弃；
3、Flex虽然要钱多，但是开发者并没有多少限制，Flex Builder也是十分的出色。laszlo体积大了点，而且文档有点过时。但他的存在对Flex是件好事。Flash的存在让我相信离开浏览器也能生存是迟早的事情。在看过两者的Demo之后，我决定在未来3个月内搞定Flex。

SWT的程序真的让人写的很郁闷，Flex的examples让我心头一亮，短短几行ui描述就做了这么多事情，如果是SWT，没有400行搞不定的事情。
<mx:....>们都能干什么，是我接下来要学习的东西，今天把以前C/S结构的项目拿来，研究了一下，真是太rapid了！
1、把S放在Tomcat里，基本没有做什么，换了一下JNDI，花了1小时；
2、C显然不能用了，DAO里随便找了一个查询返回List，用RemoteObject，结果放在datagrid里，大体就这样子：
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">
<mx:RemoteObject id="srv" source="test.DepartmentService">
<mx:method name="departments"/>
</mx:RemoteObject>
<mx:Button label="Get Data" click="srv.departments()"/>
<mx:DataGrid id="dg" dataProvider="{srv.departments.result}" width="100%" height="100%" />
</mx:Application>
在S里test.DepartmentService.departments()返回一个Set.
RPC就这么简单的实现了，一次就通过了，而且没有一贯的中文问题。1小时。
js提取数据？dom4j分析？serialized接口？JAXP？metadata API？统统不用自己搞了。

这样看来，写RIA的重点已经不是ui的布置、事件的处理，也不是通讯，而可以把重心放在优化通信，甚至优化离线，异步。当然，也可以有更多的时间做一些ui的特效。
Flex的高起点让我欣喜不已。
 
1。Flex是macromedia推出的新的表现层技术产品（或者说解决方案），基于Rich Internet Application的理念。简单的说，他的原理就是通过解析xml文件实时的生成SWF并返回到客户端。所以，最终用户看到的就是纯Flash的界面，也就是swf文件/字节流。

2。HTML已经雄霸Internet多年，已经跟不上当今全球网络环境日新月异的发展速度。使用HTML，表现方式和效果有限，虽然上手不难，但开发效率普遍低下，而且HTML与XML虽是表亲，但毕竟不如XML这般一清二楚，数据，逻辑，样式，排版，统统糅杂于一处，大不符当今分层解耦的大趋势。这也是为什么近年来，基于浏览器(其实就是基于HTML)的各种表现层框架层出不穷的原因之一。即使后来各路诸侯想尽办法，今天DHTML，明天JavaScript，还是无法彻底解决上文所说的两个问题。所以，瘦客户端技术-浏览器将死，胖客户端技术-RIA似要卷土重，倒也不是胡乱说得了。

富客户端肯定是今后web应用的发展方向了。
实现的技术也越来越多。flex，ajax.....
哪种的前景更好些呢？
flex的优点是代码编写比较简单，用相比ajax更少的代码就可以生成比较丰富的功能。和更佳的用户体验。
而且绝对跨平台，跨浏览器。毕竟运行环境下有flash播放器就可以了。不受script各浏览器标准不同的约束，
尽情写代码，不用对兼容性考虑太多。

本来内心中对ajax的前景更看好，可是写到这里，却突然发现，说不出ajax的更多优点了。
不过毕竟script跟html关系更密切。短时间内，html依然会是页面表示的基础。没有html如何SEO，虽然adobe已经
根google协议在文字，媒体检索中支持flash，但真正实现不知何年何月。
flex的最大瓶颈就应该是对html操作不够了吧。

正是跟其他语言之间的区别一样，各有所长，未来富客户端的领域更多的UI技术相信也会如此吧。

1、是客户端链接到服务器，这个时候如果要使用推模式的话，就要申明推模式，用于区分一般的ajax应用。在dwr中使用以下代码实现，调用startPoll，注册成功。

function startPoll() {    
     DWREngine.setPolling(true);
}

2、这样就会在链接服务器的时候产生一个异步长链接，并且在服务端，根据这个页面id，sessionid，sessionscriptid（dwr生成的）注册这个这个长链接。

3、这个时候客户端可以自由异步发送其他信息。

3、发现有客户端有信息发送过来，往所有的长链接发送js。这个js可以和客户端js结合，主要是传输数据，调用方法。

4、客户端接收到发送过来的js，运行。

5、经过特定时间（长链接的定时），链接断开，重新建立一个长链接。由此循环。

Struts 2.0已经为您实现很多常用的校验了，以下在jar的default.xml中的注册的校验器。

OpenCms是1999年发布的，瑞典互联网顾问Framfab支持它。Framfab在欧洲六个国家设有分支机构。德国Framfab是OpenCms项目的主要发起人。对于OpenCms的咨询和支持可以在Framfab以及其他的欧洲公司（比如Alkacon）那里获得。美国的支持选择就比较有限，但是所有的文件和培训资料都有英文版的。现在，OpenCms已经被LGT Bank of Lichtenstein、BP South Africa、和UNICEF Netherlands以及其他很多用户采用。按照Emmerich的观点，OpenCms适用于那些每天有150，000 PV（page view）的网站。



http://www.opencms.org/opencms/en/index.html

2008年3月3日，OpenCms7.0.4发布了

D:\Program Files\MySQL\MySQL Server 5.0\bin>mysql -h localhost -u root -p123456 < c:\bbscs8.sql

java.lang.OutOfMemoryError: Java heap space 解决方法

这个问题的根源是jvm虚拟机的默认Heap大小是64M,可以通过设置其最大和最小值来实现.设置的方法主要是几个.

1.可以在windows 更改系统环境变量
加上JAVA_OPTS=-Xms64m -Xmx512m

2,如果用的tomcat,在windows下,可以在

C:\tomcat5.5.9\bin\catalina.bat  中加上:

set JAVA_OPTS=-Xms64m -Xmx256m

位置在: rem Guess CATALINA_HOME if not defined  这行的下面加合适.

3.如果是linux系统
Linux  在{tomcat_home}/bin/catalina.sh的前面，加
set JAVA_OPTS='-Xms64 -Xmx512'

     摘要: 接口选择： 　　osworkflow提供几种实现com.opensymphony.workflow.Workflow接口的类。 　　 　　BasicWorkflow： 　　不提供事务支持，你可以通过持久层来实现事务处理。 　　Workflow wf = new BasicWorkflow(username) 　　这里的username是用来关联当前请求的用户。 　　 　　EJB...  阅读全文

 Osworkflow是完全用java语言编写的开放源代码的工作流引擎，具有显著的灵活性及完全面向有技术背景的用户的特点。用户可以根据自身的需求利用这款开源软件设计简单或是复杂的工作流。通过使用，用户就可以把工作中心放在业务和规则的定义上，而不需通过硬编码的方式实现一个Petri网(Petri网是对离散并行系统的数学表示)或是一个有穷自动机。用户可以以最小的代价把osworkflow整合到自己的程序中来。Osworkflow几乎提供了所有用户可能在实际流程定义中需要用到的工作流构成元素，如：

环节（step）
条件（conditions）
循环（loops）
分支（spilts）
合并（joins）
角色（roles）等等。

    但是，这款开源软件的文档十分匮乏，而且在大多数现实情形中并不适用。本文将尝试为读者填平实际的用例需求与十分简单的说明文档间的鸿沟。
    用户可以在OpenSymphony的网站上下载osworkflow的发布。当前的最高版本是2.8. 解压缩发布的软件包，即得到二进制程序、源代码、API文档、说明文档等。用户可以在软件的论坛和维基上获得进一步的帮助。

什么是工作流？
    维基百科（Wikipedia，WP）把工作流定义为“一份工作的操作过程”：

任务如何组成
如何操作
相关顺序如何
如何同步
信息如何流动以支持这些任务
以及任务如何被跟踪等。

    一个工作流引擎实现了业务的流程处理。用户应可以自动跟踪过程，这将使得引擎更具效率。同时用户可以对工作流进行建模，监控及统计引擎数据等。

示例业务过程：贷款程序
    本文的示例业务过程研究一个贷款应用程序的实例。我们将通过一个利用osworkflow工作流引擎的工作流来实现它。这个过程会在每家银行及金融机构中出现, 其区别仅仅体现为有更过的部门或更多地文档需要处理. 在本示例中, 我们会用尽量简单的方法来实现这个业务流程以便于用户理解。图一描述了这个业务流程


           
图一 贷款业务流程

    过程非常简单，分为如下4步，如下所示：
1）    填写表格：银行客户填写表格申请贷款。
2）    风险分析：一位风险分析家评估不良贷款的风险。
3）    财务历史审查：财务管理官员负责检查客户历史贷款、应付账单、信用卡历史纪录等信息。
4）    最终决定（同意/拒绝）：银行部门主管根据风险分析情况及财务历史审查情况最终决定是否贷款给该客户。

正如我们之前看到的，每个工作流都包含角色，每个角色都包含被分配的任务。下文说明了业务流程中涉及到的角色：
1）    前台职员：在某个银行部门向顾客提供信贷申请表的雇员。
2）    财务官员：负责检查申请者历史财务情况（往期贷款、未支付帐单等等）的职员。
3）    风险分析家：负责分析将钱给予借贷申请者的外部因素（比如社会经济情况等）及借贷者本人的个人情况。
4）    银行部门经理：负责最终决定是否给予借贷者贷款的经理。
     请记住，“信贷申请表”是一个重要的概念（我们将在系统实现一节看到其重要性）因为它是流经整个工作流的业务数据。

基本工作流概念

    笔者在开篇曾介绍osworkflow提供了一些特有的构造，现在笔者将逐一介绍它们。
    首先，在osworkflow中读者需要了解得最重要的概念是环节，每个工作流包含了多个环节(step)，读者可以把环节(step)想象成工作流中每一个重要的活动。每个环节可以有一些诸如“已完成”、“正在处理”、“已添加至处理队列”、“未处理”等的状态(status)，设计工作流的人可以根据需要自己定义状态。
在每个环节，动作被用户指定为自动或手动地执行。每个动作执行后，都有一个结果（result）。结果决定了工作流的流转方向：

可以停留在同一环节
跳转到另一环节
跳转到一个分支
或者汇集到一个合并等。

最后两个概念涉及用户对业务流程的并发执行，

分支把工作流分解为两个并行的环节，
合并则在用户满足一定条件后，把两个并行的环节合并成一个。


动作的执行代表了业务流程的执行，每个动作都有一组预处理功能（pre-functions）和一组后处理功能（post-functions）。其作用正如读者想象的那样，一个在动作触发之前执行，一个在动作触发之后执行。一个简单的例子是：可以在预处理功能中检验申请表格数据的正确性，而后在后处理贡功能中把经检验的数据保存至数据库。

动作的执行结果可以是有条件的（conditional）或无条件的（unconditional）。对于有条件的结果，引擎将首先检查是否条件被满足，然后再交给工作流来处理。如果条件不满足的话，引擎将进一步判断下一个有条件结果是否得到满足，以此类推，直到系统最终执行到无条件结果进行处理。
读者可能会问，如果所有的条件结果都没有得到满足会如何呢？事实上，每个动作都强制要求具有唯一一个无条件结果。与此对应的，可以有多个有条件的结果。

业务规则常常在最终结果中带有条件判断，比如，“如果申请来自于一个老客户，则流转到环节1”或者“如果当前系统的用户的角色是经理的话，直接流转道最后一个环节”。

最后一个重要的概念是步骤状态（process state），在osworkflow中，当前步骤状态是所有当前环节状态的集合。读者可能会认为工作流在运行过程中只能有一个状态，但现实的情况是：因为对分支和合并的支持，引擎能够做到对环节的并发控制，因此工作流的当前状态就可能出现：“等待风险分析及已核查财务历史”的情况。

激活动作的用户被顺理成章地称为触发者（caller），
每个环节都有一个所有者（owner），以代表在当前环节中负责执行动作的角色或用户。

当用户在环节中运转流程的时候，已完成的环节被保存至历史表中（history），用户当前所处的环节成为当前环节（current steps）。

最后，读者可能注意到，在osworkflow中并不存在其他工作流引擎中所包含的工作项（workitem）的概念。这是因为osworkflow是“十分底层”的工作流实现，怎样实现或定义工作项完全交由用户来决定。笔者认为工作项的概念太过抽象，用业务数据来称呼它或许更为贴切一些。

Osworkflow的文档中介绍了更多的构造元素，如寄存器（Registers），共用方法（common functions）等，但笔者建议在建立好第一个工作流以后再去研究它们。它们是osworkflow基本元素外的高级特性，而我们前面所认识的元素则是osworkflow的根本所在。

Osworkflow体系结构

    我们将在本节分析控制osworkflow的体系结构，我们需要理解它是怎样适用到我们的程序中来的。如我们所猜想的，Osworkflow最主要的接口是Workflow，这个接口也是整个工作流引擎的入口点。是整个系统的门面（facade）。

    接口的实现主要关注具体的业务操作能力，这个接口定义了

工作流查询
获取当前的可执行动作
执行动作
显示历史环节等。

    工作流被持久化在工作流存储体（Workflow Store）中，osworkflow提供了几种持久化的方法，包括Hibernate持久化集成，JDBC持久化集成等。一个存储体包含了环节信息，变量，工作流自身的描述信息等等。

    用户可能遇到的最常见的应用模式如下所示：
1）    通过给定的状态在工作流存储体中查询工作流信息，通常还根据某一个工作流程中具有需执行动作的用户来进行查询。这种查询时通过WorkflowQuery对象中的Workflow.query()方法实现的。
2）    通过getAvailableActions()方法列出所有在满足条件查询结果中可执行的操作。
3）    通过doAction()方法执行用户选择的动作。在执行动作的时候一些执行参数可以以java.util.Map的形式传递，以实现在工作流定义的运行期进行信息的传递。
4）    用户可以有选择地通过调用initialize()实例化一个工作流。

在理想情况下，由业务逻辑层负责调用osworkflow中的方法，如图二所示：
 
图二 在业务逻辑中集成工作流

在osworkflow中，业务逻辑描述在一个XML文件中，称为工作流描述符（workflow descriptor.）。我们将在实现小节中建立一个简单的描述符。在工作流描述符中的功能（functions）和条件（conditions）中，用户可以定义自己的业务逻辑。笔者将在把工作流集成到应用程序中一节中进行论述。

实现

    本小节介绍如何把一个业务逻辑抽象成一个工作流。首先我们要在业务流程图中识别出工作流的环节。如图一所示，显然，我们共有四个环节，同时包含一个分支及一个合并。在下面的bank.xml文件中，读者将看到它们在描述符中是如何被表示的。
    建立好环节以后，必须在每个环节中添加一些动作以便于工作流运转。每个动作有唯一的无条件结果，条件结果由读者有选择地来实现。
<step id="1" name="Form Filling">
 <actions>
  <action id="2" name="Fill Form">
   <results>
        <unconditional-result old-status="Finished" split="1"/>
   </results>
  </action>
 </actions>
</step>
    接下来要并行地执行风险分析和财务历史核查，这里是放置分支的最理想地点。
<splits>
 <split id="1">
  <unconditional-result old-status="Finished"
    status="Underway" owner="Risk Analyst" step="2"/>
  <unconditional-result old-status="Finished"
    status="Underway" owner="Financial Officer" step="3"/>
 </split>
</splits>
    在部门经理最终确认以前，并发的工作流环节必须得到合并。我们可以通过应用一个合并（join）来实现它，合并通过一个条件告诉工作流引擎，是否可以合并并进行到下一环节。在本例中，我们假设这个条件为：前面两个环节都已具有“Finished”的结束状态。即当风险分析或财务审核任何一个未完成前，不能进行到下一步：
<joins>
 <join id="1">
  <conditions type="AND">
   <condition type="beanshell">
    <arg name="script"><![CDATA[
     "Finished".equals(jn.getStep(2).getStatus()) &&
        "Finished".equals(jn.getStep(3).getStatus())
      ]]></arg>
    </condition>
   </conditions>
  <unconditional-result old-status="Finished"
    status="Underway" owner="Manager" step="4"/>
 </join>
</joins>
下面在描述符中加入每个环节的所有者，正如我们在基本概念一节看到的那样，所有者通常代表了环节间交互的角色，角色的引入默认情况下通过osuser框架来实现。
    用户既可以手写XML描述符文件，也可以通过osworkflow提供的设计器来实现。读者可以在OpenSymphony的网站上试用这个工具。

测试实现

    测试时，我们可以应用osworkflow提供的例子，把bank.xml放到WEB-INF/classes文件夹下，在文件workflows.xml中添加一行以使引擎能够识别这个工作流。

把工作流集成到应用程序

    在建模及测试工作流之后，我们即可以通过下面的几行代码把osworkflow集成到我们的程序中。
Workflow wf = new BasicWorkflow(username);
HashMap inputs = new HashMap();
inputs.put("docTitle", request.getParameter("title"));
wf.initialize("workflowName", 1, inputs);
    inputs哈希表包含了初始工作流动作中需要传出的参数,有几个实现了Workflow接口的类，其中BasicWorkflow是不支持事务的简单实现。在工作流执行过程中可以在流程中调用外部的方法，这种方法应该是实现了FunctionProvider接口的方法类。然后我们就可以用以下的方式调用它：

<action id="1" name="Execute business rule">
 <pre-functions>
  <function type="class">
   <arg name="class.name">java.net.DroolsExecutorFunction</arg>
   <arg name="ruleBaseName">BusinessRules.drl</arg>
  </function>
</pre-functions>
...
用户可以通过实现Condition接口，添加自己的条件控制。FunctionProvider及Condition接口可以调用工作流中的已知方法，这两个接口都可以接受来自于XML描述符文件中的参数。

结论

    把一个业务流程抽象成一个工作流的任务并不容易，需要好的方法和合适的工具，osworkflow是一个为我们提供了许多可重用结构的理想工具。希望通过对本文的阅读，读者能够理解最基本的osworkflow概念。本文论述过程中所采用的方法非常基础和简单，但却值得借鉴。