??xml version="1.0" encoding="utf-8" standalone="yes"?>
Laszlo
q_?span lang="EN-US">LZX语言?span lang="EN-US">Laszlo展示层服务器l成?span lang="EN-US">
使用Laszlo你将可以Q?span lang="EN-US">
?/span> 2002 qvQ基?/span> Laszlo 的应用程序已l被证明在百万用户的公?/span> Web 环境中是可行的,q且是稳定可衡量的?/span>
如果数据库系l( database systemsQ像受h敬的智者讲q的条理清晰的故事,那么工作?/STRONG>Q?STRONG>workflowQ就像一^臭未q的子在大谈各自的“哲理”。之所以这栯Q我是想指出Q?STRONG>工作?/STRONG>pȝ Q?STRONG>workflow management systemsQ还处于技术发展曲U( technology hype curveQ上的初U阶Dc(din)在q个领域我们面临一个激动h心的阶段?Z(jin)描述q一点,可以?STRONG>工作?/STRONG>和关pL据库pȝQRDBMSQ做一个对比。当在Y件开发团队中谈论RDBMSӞ大部分h?x)有一个清晰的概念Q在你和他们交流的时候,Z?x)通过d的点头表C可或理解你所说的。可当用工作流术语讨论工作?/STRONG>Ӟ他们?x)摇头表CZ同意Q因为每个h?STRONG>工作?/STRONG>术语都有不同的理解?/SPAN>
D形成q种状况的原因之一Q是?STRONG>工作?/STRONG>中用了(jin)q多的概c(din)在q个领域中的大量规范和工h有一个是怼的。当?dng)它们怺之间有重叠ƈ且会(x)怺参考引证?BR> 在介l?STRONG>工作?/STRONG>时有一个话题必d括,那就?STRONG>工作?/STRONG>?STRONG>业务程理QBPMQ的关系。术语?STRONG>工作?/STRONG>”通常描述Z计算机系l的一pd相关交互。在开发h员中Q?STRONG>工作?/STRONG>l常被提?qing)。有Ӟ工作?/STRONG>的意思是指一些不同的UI界面。业务流E管理的范围比较q,相比之下工作?/STRONG>多半局限于技术领域。业务流E管理还从管理h员的角度涉及(qing)?jin)非技术问题,比如分析、组l的效率?/P>
在本文中Q我首先解释什么是工作?/STRONG>理pȝQ然后介l业务流E管理的优点。接下来描述一下ؓ(f)什?STRONG>工作?/STRONG>?jng)场乍看h如此混ؕ。本文给出的主要l论是:(x)选择工作?/STRONG>pȝ是想?STRONG>工作?/STRONG>pȝ的公司,要面对的最困难的事情。ؓ(f)此,本文的核心部分描qC(jin)一个流E定义(process definitionQ的四个层次Qؓ(f)你选择工作?/STRONG>提供一个基。本文还用中立的语言描述?STRONG>工作?/STRONG>和BPM的通用概念。最后,l出?jin)一些规范和工具的指导性描q?/P>
工作?/STRONG>pȝ是以规格化的程描述作ؓ(f)输入的Y件组?它维护流E的q行状?q在人和应用之间分派zd?/P>
Z(jin)后面的描qͼ我们先定义一些基本的术语Q流E定义(process definitionQ和程实例Qprocess instanceQ? 一个流E定?/U>是一个业务流E或q程的规格化描述。一?U>程实例是流E定义的一个运行实体?都目前ؓ(f)止,概念q比较清晰是不是Q但当再深入一步时Q我们就要小心用文字了(jin)。如何阐q流E中的步骤,现在q没有一个统一的方式。这是各U?STRONG>工作?/STRONG>规范和工具之间主要的分歧?/P>
Z么应当禁止用术语“活动(activityQ?.. 工作系l?/STRONG>另一个重要的职责是维护每一个流E运行的上下文信息?程上下文变量(process context variableQ?/U> Q或U变量,是与程实例相关的变量。如Q休假申L(fng)开始日期、数据库中一条记录的键倹{文档管理系l中一文档的索引{。通常在流E定义中声明q些变量Q然后在程实例生成Ӟq些程变量被实例化。所有成熟的工作管理系l?/STRONG>都支持定制的变量cd?/P>
使用工作管理系l?/STRONG>的目的之一是作Z业应用系l集成(EAIQ的q_。在当前大部分企业IT架构中,各种各样的异构(heterogeneousQ应用和数据库运行在企业内网中。在q些pȝ被应用到l织Ӟ都有一个清晰的目标。例如,客户理、文档管理、供应链、订单、支付、资源计划等{。让我们U这些系lؓ(f)专门应用Q?dedicated applicationsQ。每一个专门应用都包含它们所支持业务程的领域知识。这些专门应用中的自动化程Q被DC业中更大的非自动化流E中。每当一个这L(fng)专门应用安装q投入用,都会(x)带来涉及(qing)其他多个应用的新功能需求。企业应用系l集成(EAIQ就是通过使用多个专门应用满软g新需求的Ҏ(gu)。有Ӟq只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务程编码在软g中。可以这么说Q在你购C门应用时Q你是购C(jin)一l固定的自动化业务流E。?STRONG>工作管理系l?/STRONG>是不必事先知道问题域的相关信息的?STRONG>工作系l?/STRONG>业务流E描qC入ƈ理程实例的执行,q得它比专门应用更灉|Q当然你也要q力编写业务流E的规格化描qͼ(j)。这是Z么说工作系l?/STRONG>和专门系l是怺补充的?STRONG>工作系l?/STRONG>可以用来理全局的业务流E。如果专门应用支持你所需要的业务程Q那么用专门应用。在此讨论的工作系l?/STRONG>的第一U用方式就是:(x)l合所有的专门应用Q?STRONG>工作系l?/STRONG>构徏一个EAIq_?/P>
工作系l?/STRONG>能够发挥很大价值的W二个用方式是Q协助涉?qing)多人相关Q?STRONG>工作?/STRONG>软g的开发。ؓ(f)?jin)达到这个目的,大部?STRONG>工作系l?/STRONG>都有一个方便的机制Q来生成执行d的表单。对于专注于ISO 或?A >CMM认证的组l,采用q种方式使用工作系l?/STRONG>能够显著提高生率?不用过E用文字的Ş式写在纸上,工作系l?/STRONG>使你通过程定义建模实现q程的自动化Q如使用ZWeb的应用)(j)?/P>
工作系l?/STRONG>的第三种使用方式是:(x)?STRONG>工作引?/STRONG>嵌入到其他应用中。在前面我们谈到Q专门应用将指定问题域相关的业务程固化在Y件中。开发专门应用的公司也可以将工作引?/STRONG>嵌入C们的软g中。在q里Q?STRONG>工作引?/STRONG>只是作ؓ(f)一个Y件组Ӟ对于应用的最l用h不可见的。将工作引?/STRONG>嵌入到应用中的主要原因是Z(jin)重用Q不重复发明轮子Q和应用软g的可l护性?/P>
对于引入工作?/STRONG>的组l,能够在Y件开发和业务两个层次受益?/P>
工作管理系l?/STRONG>能够化企业软g开发甚至维护? 在自动化业务程之前Q分析ƈ它们规格化是一件艰苦但?x)有很好回报的工作?A >e-workflow.org对于分析程能够带了(jin)的益处有不错的阐qͼ(x) 我认Z们还遗漏?jin)一个?STRONG>工作?/STRONG>pȝ最重要的因敎ͼ(x)提高对P代开发的支持。如果Y件中业务程部分不容易更改,l织׃(x)花很大的_֊在开发前的业务流E分析中Q希望一ơ成功。但可?zhn)的是Q在M软g目开发中Q这都很能实现?STRONG>工作?/STRONG>pȝ使得C务流E很Ҏ(gu)部vQ业务流E相关的软g可以一UP代的方式开发,因此使用工作?/STRONG>pȝ使开发更有效、风险更低?/P>
一?STRONG>工作管理系l?/STRONG>以流E定义作入。在q里Q可以将程定义看作UMLzd图、UML状态图或者有限状态机。在提交一张费用单据、申请休假、要求一个报仗?..之后Q?STRONG>工作?/STRONG>pȝ负责l护q些程定义的执行状态和上下文。ؓ(f)此,需要通知工作?/STRONG>pȝ状态的变化。运行流E的状态变化可以记录下来,以备监控理?/P>
圈套QPitfallQ?/B> 所有状态和控制的表述Q都属于业务程的状态层。标准编E语a中的控制来源于Von Neuman体系。控制流定义?jin)必被执行的指令的序Q控制流由我们书写的命o(h)、if语句、@环语句等定。在业务程中的控制基本与此一致。但在业务流E中不是使用命o(h)而是使用状态作为基本元素?/P>
在流E中Q?U>状?/U> (或者说{待状?代表?jin)一U对外部参与者(actorQ的依赖。状态的意思就像“现在Xpȝ或某某h必须作某些事Q在此等待直到参与者通知q些d已完成”。状态定义了(jin)一U对外部提供l果的依赖。状态典型的例子是批准步骤(stepQ?/P>
程定义中的状态也指定?jin)执行依赖于哪个参与者。在zd图中Q泳道(swimlanesQ的标注代表q些参与者的名字?STRONG>工作?/STRONG>pȝ使用q些信息构徏d列表Q这是一?STRONG>工作?/STRONG>pȝ都有的功能。如前所qͼ参与者可以是Z可以是系l。对于需要h参与的状态,工作?/STRONG>pȝ必须在运行时计算出具体的个h。这L(fng)计算?STRONG>工作?/STRONG>pȝ必须依赖于组l结构信息。关于这斚w的一非常有的文章是在further reading section提到的?STRONG>工作?/STRONG>应用中的l织理”( 'Organizational Management in Workflow Applications'Q?/P>
程定义的控制流包含一l状态和它们之间的关pR状态之间的逻辑关系描述?jin)哪些执行\径可以同时执行,那些不可以。同步执行\径用分叉QforksQ和联合QjoinsQ徏模,异步执行路径用判断(decisionsQ和合ƈQ?mergesQ徏模。注意在大多数模型中Q在每个状态之前都有一个隐式合q?/SPAN>?/P>
UMLzd囄常被用来做业务流E徏模。作ZU直观和通用的表达,zd囑֜囑Ş表述上有一个主要问题,是没有区分状态和动作Q它们都用活动来表示。缺这U区分(D状态概늚~失Q是学术z֯UMLzd囄主要批评。UMLzd囄W二个问题是在UML2.0版中引入的。当多个q移QtransitionsQ到达一个活动时Q以前的版本规定q是一个缺省合qӞmergeQ,?.0版中规定q是一个需要同步的~省联合QjoinQ。在我看来,UMLzd囄囑Ş部分仍旧可以用来对业务流E状态层ơ徏模,只要使用时对两条构徏语义作如下的变化Q?/SPAN>
在流E运行过E中Q?STRONG>工作?/STRONG>pȝ用一个o(h)牌(tokenQ作为指针跟t流E的状态。这相当于Von Neuman体系中的E序计数器。当令牌到达一个状态时Q它被分配给工作?/STRONG>pȝ{待的外部参与者。外部参与者可以是个h、组l或者计机pȝ。我们定义流E运行的执行人或pȝ为“参与者”(actorQ。只有在工作?/STRONG>pȝo(h)牌分配给一个参与者时Q才需要访问组l结构信息?STRONG>工作?/STRONG>pȝ通过分配令牌构徏d列表?/P>
程上下文变量(process context variableQ?/U> Q或U变量,是与程实例相关的变量。流E开发h员可以用流E变量存储跨流E实例整个生命周期的数据。一?STRONG>工作管理系l?/STRONG>有固定数目的数据cdQ另一些你可以定义自己的数据类型?/P>
注意变量也可以用来存攑ּ用( referencesQ。一个变量可以引用如数据库中的记录、网l上的文件。什么时候用引用,取决于用引用数据的其他应用?/P>
和流E变量相关的另一个o(h)人感兴趣的方面是Q?STRONG>工作?/STRONG>pȝ如何数据{化ؓ(f)信息?STRONG>工作?/STRONG>是用于组l内部跨各U异构系l实CQ务和数据协同的。对于业务流E中人工执行的Q务,工作?/STRONG>pȝ负责从其他相关系l,如SAP、数据库、CRMpȝ、文档管理系l收集数据。在业务程的每一个h工步骤,只有相关联的数据被从异构系l中攉和计。通过q种方式Q从不同pȝ来的数据被{换ƈ展现Z息?/P>
如前所qͼ动作是在程q行q程中,工作?/STRONG>pȝ响应指定的事ӞeventQ执行的一D늨序逻辑Qprogramming logicQ。程序逻辑可以是二q制或源代码形式的、用M语言或脚本编写的软g。程序逻辑层是所有这些Y件片断和关于在什么事件发生时调用它们的信息的l合。程序逻辑的例子包括发Email、通过消息代理发消息、从ERPpȝ中拿数据和更新数据库?/P>
当前在BPM领域中,关于可执行业务流E的规范有趋向于l一集中的趋ѝ?XLANG, WSFL 和BPML合ƈ为基于交互(消息交换Q的BPEL。BPEL在面向服务体pȝ?SOA)的大背景下定义。它的前提条件之一是涉?qing)的服务必须用WSDL声明。BPEL规定?jin)一套XML语法Q这套语法可以看作一U编E语aQ用来描q包括对WSDL定义的服务调用的控制?/P>
在可执行业务程和基于状态的工作管理系l?/STRONG>所使用的方法中Q我注意C(jin)三点主要的区别:(x)
最后我们看看真实世界中?STRONG>工作管理系l?/STRONG>。选择一?STRONG>工作管理系l?/STRONG>是一件困隄事情Q但有选择L没有选择好?-) 本文阐述工作?/STRONG>基本概念的目的之一Q就是你能够作更好的选择。但我也意识刎ͼ对于现在的Y件架构师来说Q选择工作?/STRONG>pȝ是一件最h战性的工作?/P>
下面的列表来源于三个地方Q?A >my previous article, the list of Carlos E Perez, ?list by Topicus. Michael zur Muehlen作了(jin)一个所?STRONG>工作?/STRONG>相关规范的介l性的qȝ?/A>Q很不错?/P>
我同?A >John Pyke 在我看来Q导致规范如此之多而同时每个规范的应用又很有限的原因是Q在工作?/STRONG>最基础概念上大家达成的p很少?STRONG>工作?/STRONG>是最Ҏ(gu)让你感到心烦(ch)的话题,因ؓ(f)工作?/STRONG>本n的概念会(x)和其他相x念和技术淆在一赗可以D一个具体的例子Q比如说工作?/STRONG>完全是对Web Service的补充。你可以通过暴露接口以Web Service的方式访问一?STRONG>工作?/STRONG>理pȝQ但是不能假定L必须通过Web Service接口讉K工作?/STRONG>pȝ接口。一些规范造成?jin)这L(fng)假设。除?jin)Web ServiceQ其他容易淆的概念和技术包括:(x)Email、流E之间的通讯、Web应用和组l结构?/P>
?STRONG>工作?/STRONG>领域W一个致力于标准化工作的?A >Workflow Management Coalition (WfMC)Q开始于 1993?WfMC发布?A >参考模?/A>很不错,它定义了(jin)工作管理系l?/STRONG>和其他相关部分之间的接口。WfMC的另一Ҏ(gu)果是XPDL规范?XPDL定义?jin)描q?STRONG>工作?/STRONG>声明部分Qdeclarative partQ的XMLl构。我个h认ؓ(f)Q参考模型和XPDL是目前最好的规范?/P>
我在本文中指?STRONG>工作?/STRONG>?jng)场q属于年轻而又混ؕQyoung and wildQ的阶段Q但已经有可靠的工具存在?
从以上所有这些中能得到的l论是:(x)
我希望本文能够激发你?STRONG>工作?/STRONG>的兴ƈ且能够ؓ(f)你进行有效的Ҏ(gu)提供正确的背景知识?/P>
about the author 译?BR> 以下者加Q?/P>
1、网友flyislandҎ(gu)文的可视化展?/A>Q很直观Q?/P>什么是工作?/STRONG>理pȝQWFMSQ?/H1>
定义
程定义通常用一些活动表q。我认ؓ(f)q是D工作领域所有q主要原因。我告诉你ؓ(f)什么:(x)因ؓ(f)术语“活动”淆了(jin)状态(stateQ和动作QactionQ之间的差异。在程中,状?/U> (或者说{待状?代表?jin)一U对外部参与者(actorQ的依赖。在程q行Ӟq意味着程引擎必须{待Q直到外部参与者通知工作管理系l指定的状态完成了(jin)。比如,{待可进一步运行的认可?U>动作是在程q行q程中,工作系lؓ(f)响应指定事gQeventQ运行的一D늨序逻辑Qprogramming logicQ。当程q行q程中指定的事g发生Ӟ工作系l启动ƈ执行q些动作。比如,当状态分配给一个参与者时Q发一Email。你也能看出Q状态和动作是如此不同,因此使用同样的术语去描述q些概念是一个坏?fn)惯。我的徏议是避免使用术语“活动”,使用“状态”或者“动作”代替它?/SPAN>目标领域QTarget usageQ?/H2>
The case for workflow
方便开?/H2>
业务程理 (BPM)
~失的一环(Missing linkQ?/H2>
我确实认?STRONG>工作?/STRONG>pȝ是企业应用开发中~失的一环。将企业业务程逻辑在企业软g中实现的~省方式是分散的。这意味着业务程逻辑散布在各U系l中Q如EJB、数据库触发器、消息代理等{。这样得到的软g难于l护Q结果,企业只能改变业务流EY件作为最后的选择。他们经常能够做的是Q改变流E以适应软g。上q问题也适用于采用大型外部ERP软g包的企业。进一步,假设我们认识到这个问题,q打将一个流E相关的代码都集中v来。对于一个流E来说这很不错,但当你要实现多个程Ӟ你会(x)看到理状态和程变量的代码被到处复制。最后,我们?x)整理这些代码放C个集中的库中。好Q?..q就是一?STRONG>工作管理系l?/STRONG>?jin),不用费心自己来实玎ͼ你可以从本文后面的列表中选择一?/SPAN>?/SPAN>
A closer look
WFMS interfaces
Figure 2: Interfaces of a WFMS
q些是WfMC参考模型(reference model of the WfMCQ中定义的五个接口中的四个?
许多工作管理系l?/STRONG>的开发商想你相信,通过使用他们的图形化程开发工P只要业务分析师就可以生成程定义。这Ux于“编E很䏀这L(fng)事实。开发商的销售h员喜Ƣ说“看Q你不用写一行代码”。不用写代码是好事,可大部分开发商在这点上走的太远Q忽略了(jin)在某些场合提供一U将代码集成到流E定义中的机制是很适合的。在?STRONG>工作?/STRONG>pȝ作ؓ(f)EAIq_Ӟ必须在流E中集成代码。开发流E定义需要业务分析师和Y件开发h员的合作。一个好的图形流E设计工具应该能够支持这U合作?/SPAN>程定义的四个层?/H2>
在下面这部分Q我试回答q样的问题“什么是程定义包括的内容?”。这是从各种规范和工h使用模型的原则和概念中ȝ得来的,反映?jin)大部分模型中通用的基本思想。流E定义的内容可以分ؓ(f)四个不同的层ơ:(x)状态(stateQ、上下文QcontextQ、程序逻辑Qprogramming logicQ和用户界面QUIQ?/SPAN>
状态层
上下文层
E序逻辑?/H2>
用户界面?/H2> 一个参与者通过向流E变量中填充数据的事Ӟ来触发结束一个状态。比如,在请假的例子中,老板提供“同意”或“不同意”数据到程中。某?STRONG>工作?/STRONG>pȝ允许指定哪些数据可以填充到流E中Q以?qing)它们如何在程变量中存储。通过q些信息Q可以生成从用户攉信息的UI表单。基于流E定义生成用h交表单的Web应用例子Q可以访?A >the jBpm online demo?/SPAN>
工作?/STRONG>全景
可执行流E与工作管理系l?/STRONG>的比较(Executional processes versus a WFMSQ?/H2>
学术?/H2> 学术界对工作?/STRONG>的研I可以回溯到上个世纪七十q代。在当前Q研I域趋向于认ؓ(f)petr |?/A>?A >所有流E定义语a之母。关于petri|已有大量先q的分析技术,d?2003 conference on Business Process Management上我有幸?x)晤了(jin)Petri教授。对于大部分够访问和理解的有关Petyri|最好的研究之一?STRONG>工作?/STRONG>模式(workflow patterns)?STRONG>工作?/STRONG>模式比较?jin)大量?STRONG>工作管理系l?/STRONG>q以petri|的术语表述?jin)通用程建模概念?/SPAN>
开放源代码目
商业软g提供?/H2>
工具目录
规范
l论
Further reading
Thanks
A special thanks for Gustavo Maciel Dias Vieira and Jef Vanbockryck for their valuable feedback on the draft versions of this article.
Tom Baeyens leads the jBpm support organisation, specialized in Java, workflow and business process management. His expertises are both at a technical, analysis and at a business level. Tom is the founder of jbpm.org, an open source workflow engine. Tom is also a member of the expertgroup of the JSR 207: Process Definition for Java. Tom Baeyens can be contacted at tom at jbpm.org
dinghong嵌入式Java工作系l?A target=_blank>Joinwork的设计开发者之一。emailQ?A href="mailto:dinghong@joinwork.net">dinghong@joinwork.net?
]]>
首先Q我们从一个高度来抽象一下表现层框架应有的技术架构,下图可以说所有表现层框架技术都必须实现的功能架构图Q?/P>
当然Q我们不必废话罗嗦MVC模式QMVC模式是基准模式,现在框架技术已l不必再拼是否是MVC模式?jin)?在上图MVC模式基础上,一个表现层框架无外乎要实现图中的三个功能:(x)
1.在当前页面能够显CZ个组件对象的内容Q而不是象UJSP那样Q需要在Jsp面写入“调用对象方法”的Java代码?/P>
2.当用h下页面的提交按扭或链接后Q事件发生,q时应该触发服务器端q将当前面的参数提交给服务器。这U机制表现在Form表单提交和有参数的链?lt;a href=""></a>
3.从一个页面视囄接蟩转到另外一个页面视图,单纯的导航作用?/P>
我们通过下表来比较这 三种框架在实C囑个功能时技术细节,从而得Z们的异同点和偏重炏V?/P>
|
Strutslg~程模型
Struts实现lg~程时有一些复杂:(x)l常Z个页面中需要引入多个组件而头|因ؓ(f)Struts中无法直接引入多个组Ӟ必须l一些圈?
一般分两种情况Q如果同一个Action可以对付这些组Ӟ那么在这U情况下有两个办法:(x)
1.这多个lg装入一个ActionForm中,如?SPAN class=unnamed3>MapForm{机Ӟ
2.手工多个组件装入request/session{scope中,然后Ҏ(gu)其名U在jsp中获得?/P>
q两个方法都有缺点:(x) W一U办法经怸个ActionForm弄得面目全非Q变成一个大杂烩Q违反了(jin)OO分派装的原则;W?U办法其实又回到jsp~程Q?/P>
W二U情况,如果q些lg必须有预先由不同的Action来处理,每个lg必须l过Action -->ActionForm程Q在q种情况下有两种办法Q?/P>
1.使用Tiles, 不同程输出到同一个页面的不同区域。是一Uƈ行处理方式?/P>
2. 对多个流E首q,W一Action forwardl果是第二个ActionQ最后输Z个JspQ在q个jsp中就可以使用前面多个程的多个ActionForm?jin),q属于串行方式?/P>
Strutslg模型~点
Strutslg~程必须限定在Action/ActionForm/JSPq三个框框中做文章,隑ֺ相对比较大,而Tapestry/JSF则没有太多这些技术框框限Ӟ两者在lg~程斚w更让~程者自׃些,方便一些,q也是组件型框架的优势吧?/P>
Struts标签?/STRONG>
在Struts中,l常需要用标{ֺ来显C组件ActionForm中内容,q就涉及(qing)C个结合的问题Q标{ֺ是别人写的,参考Struts的标{ֺ用法Q而组件是自己的,隑ֺ和麻?ch)就体现在这个结合点上?/P>
JSF基本思\和Struts差不多,只不q换?jin)不同标{ֺQ也需要标{ֺ+lg的结合思考,不过因ؓ(f)lgq里是通用lgQ没有什么限Ӟ所以这hStruts要轻松一些?/P>
Tapestry使用?jin)组件库概念替代了(jin)标{ֺQ没有标{ֺ概念Q这样就没有标签库和自己的组仉要结合的问题Q都是组件的使用Q组件中分Tapestry标准lg和自己定义的lgQ这也是接触?jin)Jsp体系的h学习(fn)Tapestry面(f)的一个思\转换?/P>
具体以页面蟩转ؓ(f)例子Q页面蟩转是靠链?lt;a href="目标"></a> 实现Q链接是面l常使用的元素?/P>
Struts提供的html:link在频J用就特别不方便,其在传递多个参数时Q其中h(hun)tml:link的page|是蟩转对斚w面或Action的pathQ这个path一般需要到struts-config.xml查找Action的相应path,一旦配|文件pathg改,涉及(qing)到这个所有相关页面都要修攏V?/P>
JSF链接概念划分两个方面:(x)D性质和事件激z,在导航方面还是需要到配置faces-config查询Navigation的from-outcome的倹{?/P>
׃Tapestry没有标签库概念,只有lg或页面两个概念,因此Q链接蟩转目标要么是lgQ要么是面Q简z简单,它没有多余的path概念Q就是组件名Q也是对象名称Q组件名U和path名称合二Z?/P>
ȝ
JSF在很大程度上cMStrutsQ而不是类似TapestryQ可以说是一UStruts 2.0Q都是采取标{ֺ+lg的Ş式,只是JSF的组件概忉|有象Struts那样必须l承ActionForm的限ӞJSF在事件粒度上要细腻,不象Struts那样Q一个表单一个事ӞJSF可以l化到表单中的每个字D上?/P>
JSF只有在组件和事g机制q个概念上类似TapestryQ但是不似Tapestry那样是一个完全组件的框架Q所以,如果你做一个对面要求灉|度相当高的系l,选用Tapestry是第一考虑?/P>
Struts/JSF则适合在一般的数据面录入的系l中Q对于Struts和JSF的选用Q我目前个h观点是:(x)如果你是一个新的系l,可以直接从JSF开始;如果你已l用StrutsQ不必{换,如果需要切换,可以JSF和Tapestry一赯(g)虑?/P>
另外QJSF/Tapestry不只是支持HtmlQ也支持多种客户端语a如WML或XUI{?/P>
q三者之间关p:(x)如果说Struts是左z;那Tapestry则是xQ而JSF则是中间z,中庸M是SUN联盟的一贯策略?/P>
当然Q你也可以发表你在实践中q三者Q何一个的使用感受Q以使得后来者有一个比较?/P>