刚安装完flex3.0 beta2,运行起来界面如下：
1）先创建一个flex Project
按着向导一步一步做就可以了。
2）开始设计GUI
Flex书籍资源
osworkflow descriptor 解析 重要概念
转贴
在这篇文章中，主要介绍osworkflow的核心概念以及重要的部分，让大家对osworkflow有个比较全面的认识。
在osworkflow中最最核心的东西就是工作流定义的xml文件。尽管它并不是一定要定义成xml文件。但是xml格式是一种标准的通用的格式。
这个xml文件为某一个给定的工作流进行描述steps、states，transitions，和functionality。下面阐述一下此xml的一般规则：
1、 一个工作流由多个steps组成
2、 对于每个step，可以包括多个actions。一个action可以被设置成自动运行或者需要通过人工交互才可以运行。
3、 每个action都要包括至少一个unconditional result和0或多个conditional results。
4、 如果设定了多个concitioanl results，所有当中的第一个将被执行，如果没有设定conditional results或者没有conditions满足，那么执行unconditional result
5、 一个result过后可能依旧停留在当前的step中，一个新的step，一个split，一个join。在所有的情形中，工作流的state跟着变化（例子工作流中的states分别为：Underway,Queued,和finished）
6、 如果一个result引起一个split，这个result会指定split >的属性，以指向一个split元素。
7、 一个split可以有一个或者多个unconditional results，但是没有conditional results。Unconditional results。Unconditional results需要指定steps。
8、 一个propertyset是一个持久层数据的map，在全局应用中都是可用的。
9、 还有一种叫做transientVars的map，它只存活于一个工作流调用过程中的一定的生命周期，它将会对所有functions和conditions，包括所有的registers，user input，以及工作流上下文状态等起作用。
工作流概念：
下面开始理解osworkflow的核心概念：
对于step，status，actions部分就不多说明了，其实我觉得理解概念的最快方法应该是参照实例，即使我们不能用高高大大的词汇描绘出来，能自己理解是什么意思就可以了。
Unconditional result 和 conditional results
这里做以简单介绍，对于每个action，要求至少存在一个Unconditional result，一个result也就是通过一系列指示来告诉osworkflow下一步的任务是干什么。这种调用使得产生变迁进而从一个state到另外一个state。这种概念是在UML的状态机里有讲，希望了解状态机相关概念的可以到UML相关书籍中查看。
Conditional result是unconditional result的一种扩展。不同的地方在于他需要一些子元素：condition。用and 和 or来标志各个condition之间的关系。
Conditional 和unconditional 的最终result可以产生三种效应或者说是结果：
1、 一个新的step/status
2、 一个split，出现一或多个step/status
3、 一个join，一个新的step/status
普遍的，一个split或者join不能result出另外一个split或join。
一个step/status result可以按下面方式简单的设定：
status=”Underway” owner=”${someOwner}”/>
从一个state split 到多个 states可以按以下方式达到：
...
status="Underway" owner="${someOwner}"/>
status="Underway" owner="${someOtherOwner}"/>
Joins是比较复杂的用例。一个典型的join看起来大致如下：
利用osworkflow实现业务流程
转贴：
Osworkflow是完全用java语言编写的开放源代码的工作流引擎，具有显著的灵活性及完全面向有技术背景的用户的特点。用户可以根据自身的需求利 用这款开源软件设计简单或是复杂的工作流。通过使用，用户就可以把工作中心放在业务和规则的定义上，而不需通过硬编码的方式实现一个Petri网或是一个 有穷自动机。用户可以以最小的代价把osworkflow整合到自己的程序中来。Osworkflow几乎提供了所有用户可能在实际流程定义中需要用到的 工作流构成元素，如：环节（step）、条件（conditions）、循环（loops）、分支（spilts）、合并（joins）、角色 （roles）等等。(假如读者对这些概念还不熟悉，笔者将在Osworkflow基本概念一节中进行简单描述。)
但是，这款开源软件的文档十分匮乏，而且在大多数现实情形中并不适用。本文将尝试为读者填平实际的用例需求与十分简单的说明文档间的鸿沟。
用户可以在OpenSymphony的网站上下载osworkflow的发布。当前的最高版本是2.7（译者注：最新版本为2.8）. 解压缩发布的软件包，即得到二进制程序、源代码、API文档、说明文档等。用户可以在软件的论坛和维基上获得进一步的帮助。
什么是工作流？
维基百科（Wikipedia，WP）把工作流定义为“一份工作的操作过程”：任务如何组成、如何操作、相关顺序如何、如何同步、信息如何流动以支持这些任务、以及任务如何被跟踪等。
一个工作流引擎实现了业务的流程处理。用户应可以自动跟踪过程，这将使得引擎更具效率。同时用户可以对工作流进行建模，监控及统计引擎数据等。
示例业务过程：贷款程序
本文的示例业务过程研究一个贷款应用程序的实例。我们将通过一个利用osworkflow工作流引擎的工作流来实现它。这个过程会在每家银行及金融机构中 出现, 其区别仅仅体现为有更过的部门或更多地文档需要处理. 在本示例中, 我们会用尽量简单的方法来实现这个业务流程以便于用户理解。图一描述了这个 业务流程
图一 贷款业务流程
过程非常简单，分为如下4步，如下所示：
1） 填写表格：银行客户填写表格申请贷款。
2） 风险分析：一位风险分析家评估不良贷款的风险。
3） 财务历史审查：财务管理官员负责检查客户历史贷款、应付账单、信用卡历史纪录等信息。
4） 最终决定（同意/拒绝）：银行部门主管根据风险分析情况及财务历史审查情况最终决定是否贷款给该客户。
正如我们之前看到的，每个工作流都包含角色，每个角色都包含被分配的任务。下文说明了业务流程中涉及到的角色：
1） 前台职员：在某个银行部门向顾客提供信贷申请表的雇员。
2） 财务官员：负责检查申请者历史财务情况（往期贷款、未支付帐单等等）的职员。
3） 风险分析家：负责分析将钱给予借贷申请者的外部因素（比如社会经济情况等）及借贷者本人的个人情况。
4） 银行部门经理：负责最终决定是否给予借贷者贷款的经理。
请记住，“信贷申请表”是一个重要的概念（我们将在系统实现一节看到其重要性）因为它是流经整个工作流的业务数据。
基本工作流概念
笔者在开篇曾介绍osworkflow提供了一些特有的构造，现在笔者将逐一介绍它们。
首先，在osworkflow中读者需要了解得最重要的概念是环节，每个工作流包含了多个环节，读者可以把环节想象成工作流中每一个重要的活动。每个环节 可以有一些诸如“已完成”、“正在处理”、“已添加至处理队列”、“未处理”等的状态，设计工作流的人可以根据需要自己定义状态。
在每个环节，动作被用户指定为自动或手动地执行。每个动作执行后，都有一个结果（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）。
接口的实现主要关注具体的业务操作能力，这个接口定义了工作流查询，获取当前的可执行动作，执行动作，显
IT规划中的技术体系架构
体系架构通常会建立一个共有的远景，然而，简单的设定远景是远远不够的，必须和构建人员、客户、其他相关人员进 行沟通以达成共识，在构建过程中要维护该体系架构。它在一个横跨于客户需求、构建人员的要求以及客观世界约束的沟壑之间架构了一座桥梁。
一、什么是体系架构
体系架构可以定义为一种使用的、有条理的部件集合的结构化形式，该架构通过这些部件以一种精确的方式为用户提供远景的支持。IT行业使用“体系架构”这一 概念的历史不是很长，它同其他行业在体系结构使用方法上有相同的应用前景，体系架构的实现连接了具体的需求和远景的战略规划。
从IT规划角度看，企业IT体系架构往往和软件系统架构、应用程序架构混为一谈，确切讲，企业IT体系架构的概念比软件系统架构的概念更宽泛，它指明了通 过IT系统支持业务目标的方向。按照这种使用体系结构技术的组织可以满足许多关键IT原则：
1、对于业务系统和IT系统的管理可以帮助实现业务目标；
2、在业务目标和信息需求的一致说明的基础上，就业务系统优先级和相互依赖性作决策；
3、快速灵活的实施新系统、改进系统以及获取支持业务创新的信息；
4、技术的发展和采用受到业务优先权的影响。
企业IT体系架构包括了体系架构化准则的层次结构：
1、信息体系结构：信息体系结构设计组织信息的结构和用途，根据组织的战略、战术和运营方面的要求对信息加以调整。
2、业务系统体系结构：根据必需的业务系统，业务系统体系结构指导对信息结构化处理以满足业务系统的要求。
3、技术体系结构：技术体系结构定义了整个信息系统中的技术环境和基础结构。
4、软件体系结构或应用程序体系结构：它们定义了基于所定义的技术的单个系统的“结构”。
二、技术体系架构的重 要性
在企业IT体系架构中，最关键的一个部分是技术体系架构。之所以技术体系架构重要是因为它对IT规划的实现起着支撑作用。从本质上讲，技术体系架构定义了 组织为了获得商业利润而构建与使用的信息技术平台。
技术体系架构包含如下内容：
1、描述和定义了所交付业务系统所采用的技术环境的结构；
2、建立和维护一套评价技术项目的核心技术标准；
3、建立了技术与业务系统有机结合的一个行之有效的方法；
4、建立技术实现决策的框架；
5、为组织的技术环境保持良好的发展态势提供管理理架构。
技术体系架构并不仅仅是一套标准，确切讲，它是一种组织能力的体现，这种能力不仅体现在文档方面，还反映了技术专家、IT管理员、规划、设计人员以及实施 人员的知识与经验。从总体展望一下，可以看到技术体系架构可能为企业带来的优势：
更为行之有效的IT运营方式
定义良好的结构和具体IT实现的模块化结构可以导致更加行之有效的IT运维方式：
1、较低的软件开发、支持和维护费用；
2、更好的应用程序可移植性；
3、改进的互操作性、更简单的系统和网络管理方式；
4、可以跟高的解决诸如安全性之类的企业关键问题；
5、系统组件的更新与更换更方便。
现有投资的更大回报与未来投资的更低风险
现有的和已经规划的系统结构定义清晰，会产生如下效果：
1、减少IT基础结构的复杂性；
2、使得现有IT基础结构投资产生最大的回报；
3、增加了制作和购买IT解决方案的灵活性；
4、降低了IT所有权费用和新投资的风险。
更为廉价便捷的采购方式
技术体系架构对未来的采购和移植有完整的策略，其产生的结构是：
1、采购决策更为简单，可以更方便的利用在一致的规划中的采购信息；
2、采购过程更快、最大化采购速度和采购灵活性而不会破坏体系架构的移植性。
业务增长和结构重组的灵活性
定义良好的技术体系架构可以确保更为方便的跨企业访问集成信息：
1、业务增长和结构重组的最大灵活性；
2、通过内部合并、兼并和重新设计业务流程以节约实际成本。
加速进入市场的时间
构建良好的IT基础架构可以更快的开发以任务为中心的业务应用程序：
1、新产品和服务进入市场的时间加快；
2、扩大发展规模和盈利能力。
要为企业构建合理的技术体系架构，可以通过“企业IT情况检查表”来确定哪些问题可以通过构建合理的技术体系架构得以解决。如下表所示，在该表中所罗列的 问题并非技术问题。