不同框架介绍

Java版Web框架

　　Struts

　　Struts是一个基于Sun J2EE平台的MVC框架，主要采用Servlet和JSP技术来实现的。它已成为用Java创建Web应用的一个最流行的框架工具，Struts所实现的MVC模式给Web应用带来了良好的层次划分，同时也提供了一系列的工具来简化Web应用的开发。

　　Struts通过提供一个中心化的Servlet来实现MVC中的控制器模式。Struts中的控制器提供集中请求转发功能，就好似一个路由器系统，解析来自客户端发起的请求，并将请求定向到对应的业务逻辑上，最后将业务逻辑处理得到的结果展现到对应的视图上。通过这种模式，它将控制器与视图逻辑进行了较好的分离，使得应用系统能更快适应业务逻辑的变化。在视图技术上，Struts不仅限于JSP，同时可以与XML/XSLT、Velocity等技术进行结合。这些丰富的标签库为加速应用开发提供了更为快捷的途径。

　　Struts框架也为用户提供了极为丰富的开发文档，同时Struts相关的书籍也大量上市，这为开发人员学习和使用Struts提供了可靠的保障和支持。Struts经过多年的发展，已经拥有大量的开发者群体，这些开发群体使得Struts的开发和改进工作得到不断的支持，Struts框架因此具备更为长期和稳定的发展潜力。

　　WebWork

　　WebWork是由OpenSymphony组织开发的、致力于构件化和代码重用的拉出式MVC模式J2EE Web框架，它以其精巧、灵活、功能强大而闻名。WebWork 2.x早期是由著名的开源专家Rickard Oberg开发完成；随着技术的演化，WebWork项目现在被拆分成两个单独的项目Xwork1和WebWork2两个项目。 Xwork是一个标准的Command模式实现，完全从Web层脱离出来。 WebWork2建立在Xwork之上，处理HTTP的响应和请求。在WebWork 2.2中添加了对AJAX的支持，这支持构建在DWR与Dojo这两个框架的基础之上。

　　WebWork与Struts的不同表现在以下一些方面——

　　线程模型：Struts 的请求只有一个实例去处理，这使得所有资源都必须保持同步，会产生线程安全的问题。在WebWork的实现中，每一个请求对应一个Action, 每一个处理都是相对隔离，不会产生线程安全的问题。

　　容器外测试：Struts的Action依赖ServletRequest和ServletResponse，因此进行单元测试时必须依赖容器本身。WebWork2中的Action不依赖任何容器，可以较好地进行容器外测试。

　　Action的控制：WebWork提供Action拦截器处理机制，允许在每一个Action前后进行其他操作。

　　WebWork用户群体较小，相关的文档资料和支持工具也较少，比较适合技术能力较强的开发人员使用。

　　EasyJWeb

　　EasyJWeb是基于Java技术、应用于Web应用程序快速开发的MVC框架，框架设计构思来源于国内众多项目实践，框架充分借鉴了当前主要流行的开源Web框架（Struts、Webwork等），吸取了其优点及精华，利用Velocity作为模板页面引擎，是一个实现了页面及代码完全分离的MVC开发框架。EasyJWeb具有以下几个特点：

　　1、零配文件置支持。EasyJWeb实现零配置支持，可以不写一句配置文件就在框架基础上构建运用（适合小型网站系统）。

 

 

 

Java版持久层框架　　Apache Torque

　　Apache Torque是一个使用关系数据库作为存储手段的Java应用程序持久化工具，是Apache的公开源代码项目。Torque由Web应用程序框架Jakarta Apache Turbine发展而来，但现在已完全独立于Turbine。Torque主要包含两部分：一部分是Generator，它可以产生应用程序需要的所有数据库资源，包括SQL和Java文件；另外一部分是Runtime，提供使用这些代码访问数据库的运行时环境。

　　Hibernate

　　Hibernate最早是Sourceforge.net的一个子项目，后被JBoss购入麾下，目前已成为炙手可热的持久数据管理框架。它是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲地使用对象编程思维来操纵数据库。

　　iBatis

　　iBatis提供了ORM机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象，这一层与通过Hibernate 实现ORM 而言基本一致。对于具体的数据操作，Hibernate 会自动生成SQL语句，而iBatis 则要求开发者编写具体的SQL 语句。相对Hibernate等“全自动”ORM机制而言，iBatis 以SQL开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。

Java版J2EE框架

　　Spring

　　Spring是由Interface21公司的CEO Rod Johnson领导开发的开源J2EE应用框架，它解决了许多在J2EE开发中常见问题。Spring还提供了管理业务对象的一致方法，并且鼓励对接口编程而不是对类编程的良好习惯。Spring的架构基础是基于使用JavaBean属性的Inversion of Control容器。

　　Spring为J2EE应用开发提供了一个完整的分层体系架构，为使用轻量级的方法解决复杂的企业级应用开发提供了一个最佳实践。Spring应用框架由几个模块组成——

　　Spring核心容器：以Setting Injection为主的IoC（反转控制容器），通过XML配置模式，应用组件间的依赖进行关联。

　　Spring Context：Spring Context作为贯穿Spring整体的一个引线，为框架内集成的服务提供上下文环境。

　　Spring MVC框架：将已有的Web MVC框架与Spring进行集成，使现有的MVC框架能与Spring 的IoC容器进行挂接，提供从控制层到业务层的反转控制式编程。

　　Spring AOP：为Spring提供了面向方面的编程能力。

　　Spring ORM：集成了Hibernate、JDO、Ibatis SQL Map 等持久化组件，为上层应用开发提供了一致的持久化编程模型。

　　Spring DAO：将JDBC的应用开发操作进行抽象，提供统一的模板方法和异常层次结构，同时提供透明的事物处理机制，极大地简化了基于数据库应用的开发过程。

　　Spring框架的这种松耦合编程体系结构和非入侵性的特性，使得J2EE的应用开发不依赖于任何J2EE应用服务器，为提高J2EE应用开发的整体质量起到了极其关键的作用。

　　JFoxSOAF

　　JFoxSOAF（JFox Service-Oriented Application Framework）由Huihoo.org 开源社区开发，是以Type3模式的IoC为核心的J2EE应用开发框架。JFoxSOAF采用基于IoC微内核的系统设计架构，将现有众多开源的成熟软件框架、组件集成到一个体系中来，将原来相对零散的部件构成一个整体，为应用项目的开发提供一个完整的框架结构和实践的指南。JFoxSOAF作为应用服务器上层的技术基础件，提供三个层面的系统服务，即应用服务层、业务服务层、系统服务层。

　　JFoxSOAF与Spring的不同表现在以下几方面——

　　IoC核心容器：JFoxSOAF采用基于构造器注入方式的IoC容器，无需在大量的XML描述文件中声明类间的依赖关系，极大地简化了应用开发的部署描述。

　　独立的上下文环境：JFoxSOAF采用独立的上下文环境，通过ServiceFactory，任何一个类都可以在任何环境获得注入在IoC容器中的实例，从而建立起引用关系。Spring在Web应用中，必须通过Web容器环境获得上下文的环境。

　　JDBC开发模板：JFoxSOAF集成了DBUtils作为JDBC DAO的模板框架，提供数据自动填装功能，简化了CRUD操作的开发过程，简单易用。Spring的DAO模板功能也非常强大，但其需要手工进行数据填装操作，增大了应用开发的复杂度。

　　事务处理：JFoxSOAF采用JOTM作为事务处理器，提供编程式的事务管理，Spring框架提供声明式的事务管理，更易于灵活地配置开发。

.Net 开源框架

　　Castle

　　Castle是.Net系统级框架，它通过将一些成熟开源应用进行无缝整合而成的一套完善的应用系统框架，这其中包括了ActiveRecord、DynamicProxy、MonoRail及MicroKernel/Windsor。MicroKernel/Windsor是Castle的底层核心实现，它采用IoC容器对系统进行运行期动态设置，主要包括Facilities、Components、Services三大部分。

　　ActiveRecord对当前热门的ORM框架NHibernate进行了封装处理，主要包括将一些常用的数据进行抽象化、通过Attribute来取代mapping文件等。在ActiveRecord的实现中，Model对象必须继承于Active-RecordBase对象以便于Castle容器进行控制，限制Model对象从其他非持久化对象继承的可能，这是有违NHibernate/Hibernate最初的设计思想的。在Hibernate的设计思想中，Model对象可以是任意的Java Bean对象。MonoRail是Ruby on Rail的.Net实现，这是一个MVC Web框架。它与传统WebForm在控制上的不同在于WebForm采用页控制器模式，而MVC采用前端控制器模式。在界面表达方式上MonoRail采用模板引擎输出，模板引擎在PHP和JSP上已广泛使用，而在ASP.NET上因为服务端控件的强大功能和易用性而很少有人使用，两者是各有优缺点。

　　Spring.NET

　　Spring.NET是由Spring框架移植而来的，Spring框架是Java著名的应用系统框架，它已成为了替代轻量级企业应用的开发标准框架了。Spring.NET包括——

　　Spring.Core core：就是一个对象工厂（ObjectFactory），它通过配置中的对象定义来创建对象，它的目的是消除对象的new操作。在配置文件中，除了定义对象的一些属性外，还能定义对象之间的相互关系，这就使得对象之间的耦合延迟到了运行时，如果针对接口或抽象类进行编程，则还可以通过具体对象的不同实现来定制系统的行为。

　　Spring.AOP：这是按AOP联盟的接口定义来实现的，AOP即面向截面编程，其核心是通过给对象创建一个动态代理对象来接管对象的操作，这样就能对操作进行前置和后置处理了。

　　Spring.Data：这是一个由第三方实现的整合到Spring内的数据访问组件，目前已包括了NHibernate的实现部分。

　　Spring.NET还显得不够成熟，一些功能因为平台的局限性而导致了移植上的困难，与Castle相比就差了一些。

　　Nhibernate

　　Nhibernate是.NET持久层框架，它从Java上的Hibernate移植而来。作为一种o/r mapping框架，它具有以下一些特点：完善的数据映射及关联操作；可扩展的持久机制；强大的数据加载功能；面向对象的数据查询语言HQL；缓存机制; 多数据库支持。

　　Nhibernate的强大之处在于开发者几乎不用去了解任何数据存储和查询的细节问题，而能更专注地通过面向对象设计来构建系统。其HQL查询语言完全是针对对象及其属性来设计的，与SQL语法保持一致，降低了学习的曲线。

　　当然，Nhibernate还有一些不足之处，如报表数据。另外在性能上, Nhibernate通过反射来执行一些操作以及数据行到对象之间的转换, 都会造成性能上的一些损失。

　　iBatis.NET

　　作为另一种.Net持久层框架，iBatis.NET同样是从Java上的iBatis移植而来的o/r mapping框架，它包括DataMapping和DataAccess两部分——

　　DataMapping：ORM的实现部分，对象映射通过映射文件来定义，支持one-to-one、one-to-many等对象关系映射。与Nhibernate显著不同的是，ibatis.net不会自动生成SQL语句，它通过预先定义好的SQL映射来执行数据操作，对于想自由操作SQL或使用复杂表达式的人来说，这是个不错的选择。

　　DataAccess：数据存取框架实现，通过在配置文件中定义DAO接口及其实现，就可以方便使用DaoManager进行数据操作了，这也是一个在运行时决定具体实现的标准应用。

Java版工作流

　　Shark

　　Shark是体系和功能最为复杂的代表。它是另一款遵循WfMC的XPDL标准开源工作流引擎，并且同时遵循OMG组织的Workflow Management Facility规范。在所有开源工作流引擎中，Shark的体系最为完备和复杂。其一直秉承着“模块化”的思想，所以比较容易扩展。但是自从被Together公司收购后，Shark的商业化色彩已经越来越浓，改称为Together Workflow Server，并仅以Community Edition的形式提供了部分开源代码供参考。

　　OSWorkflow

　　OSWorkflow是最轻量型的代表，也是一款非常灵活和低级别定位的工作流引擎的实现框架。低级别定位的意思是说，它不是定位在解决流程模型对象和运转场景，而是提供一套可维护调度的机制，供开发人员自主扩展。这个维护流程调度机制OSWorkflow选择的是基于行为（Action）的FSM理论，所以OSWorkflow更像是一个复杂而灵活的有限状态调度机。

　　OSWorkflow在国内项目应用得较多，很多国内的简易审批流程项目都是基于其引擎二次开发而来。这主要是由于OSWorkflow是基于Action驱动的，而国内的客户也很容易接受这样的操作习惯。但OSWorkflow所依赖的FSM模型对于分支、聚合、子流程的支持度很低，这一点在实施过程中需要注意。

　　jBpm

　　jBpm是最适合扩展的代表，是在所有开源引擎中最适宜被商业化应用的一款。首先其流程建模模型是基于Activity Diagram（活动图）的，并在引擎构建上融入了FSM和PetriNet思想，所以其内核和根基比较牢固扎实。其次，自从被JBoss收购后，其3. x系列的结构更加趋于微内核，Plug-in思想也更加深入。其同时还提供了对BPEL扩展，存储支持JBoss Hibernate实现，集成了JBoss seam，规则引擎准备采用JBoss rules，并准备集成JBoss Messaging。这样，不论从内核和外围应用，jBpm都具有了强劲的动力。

　　另外，jBpm对Token的应用也很有特色，巧妙地利用Parent-Child Token的机制处理分支、父子流程等复杂应用场景。这个设计思想很值得大家学习参考。

　　YAWL

　　YAWL是算法和模式最值得研究的代表，它是Alast力主倡导的一款基于PetriNet建模的工作流引擎，其将PetriNet的Token与And、XOR、OR算法进行了融合，并对Workflow Patterns（工作流模式）中所有模式提供支持。但YAWL本身仅是一个研究性项目，所以其结构和实现缺少了商业化应用的特点。但有必要研究一下YAWL，一方面可以加深对工作流模式的理解，另一方面，YAWL的一些建模思想、处理算法很值得推敲和吸纳。

　　ActiveBPEL

　　ActiveBPEL 是BPEL引擎的代表，也是一款可执行BPEL4WS规范的开源流程引擎，其结构和实现方式具有很高的参考价值。目前国内很多正在开发基于BPEL产品的中小型软件厂商，其实现的很多基础性内容和思想都参考自ActiveBPEL。受目前国内中小型客户对流程需求的限制，基于BPEL的开源引擎或小型产品被市场接受度还很低。但BPEL所围绕的业务流程及流程整合应用是一个发展趋势。（TechTarget）