J2EE开发框架
-信息系统发展前景
摘要
分析了基于J2EE框架的专家系统软件的特点和发展优势。本文讨论了专家系统的基本结构和工作原理。重点研究基于J2EE的专家系统的总体设计和实现方法。
Java 2企业版在标准化许多重要的中间设备内容方面有重要的作用。例如，J2EE为分布式事务管理，目录服务和消息传递提供了标准接口。此外，支持J2EE的Java 2标准版（J2SE）为与关系数据库的Java交互提供了一个非常成功的标准。
但是，正如“J2EE缺乏应用程序编程支持”杂志报道所解释的那样，该平台未能提供令人满意的应用程序编程模型。
Sun Microsystems和大型应用服务器供应商大都通过提倡开发工具来隐藏J2EE的复杂性来回应这个问题。但是，用于管理J2EE组件的工具并不像使用Java语言的工具那样好，它具有复杂的重构功能，并且J2EE工具的支持作用通常不如Microsoft.NET平台。许多J2EE工具本身都很复杂，它们生成的代码也是如此。
开源领域的许多人，特别是较小的供应商，已经选择了开发框架的替代方案，旨在简化构建J2EE应用程序的体验。诸如Struts，Hibernate和Spring Framework等流行框架在当今许多J2EE开发项目中发挥着重要作用。
为什么使用框架？
软件框架是一组类，它们构成应用程序的可重用设计，或者更常见的是应用程序的一层。而应用程序代码调用一个类库来提供服务，一个框架调用应用程序代码，因此能够管理整个流程控制。这通常被称为好莱坞原则：“不要打电话给我们，我们会打电话给你。”应用程序开发人员编写一些代码，然后框架在运行时调用时会调用这些代码。
设计用于各种未知环境的框架具有挑战性。但是，框架方法很好地适应了J2EE开发的复杂性，因为它可以为应用程序员提供简单易用的模型。
使用精心设计的开源框架有许多优势：
bull; 通过良好的框架，开发人员只编写他们需要的代码; 他们不用深究底层的API。 这是关键的价值所在。
bull;精心设计的框架可以为应用程序提供结构和一致性。 加入该项目的其他开发人员也会清楚该结构。
bull;易于遵循的框架可以通过示例和文档来促进最佳实践。
bull; 成功的开源框架比底层代码更好进行测试。
bull;框架通常只有在可以提供的东西时才会有用武之地。 内部框架通常是强制性的，而J2EE项目很可能只有在框架能够提供明确的优势时才采用开源框架 。
J2EE本身定义了很多框架。例如，Enterprise JavaBeans（EJB）容器或Servlet引擎都依赖于Hollywood原则，J2EE运行时实例化并调用托管对象。开源Web应用程序框架（如Struts）在标准Servlet框架上添加自己的框架。这里要强调的框架是上述J2EE框架，它提供了一个简单的编程模型或其他很多好处。
开源框架的出现
一般来说，大多数大型J2EE项目都使用内部框架来隐藏平台的复杂性。 直到最近才出现了关于需要通用解决方案的问题以及提供良好通用解决方案的特定框架的共识。现在有一个明显的趋势，即框架可以“标准化”以前基于每个项目开发的更多基础设施。
J2EE框架突然受欢迎的一个原因是平台的成熟度增加。开发人员现在认识到了标准的APIs 领域现在是很缺乏的，并且从他们经验上来讲编写一个好的框架去弥补这个空缺非常困难。此外，还有许多高质量的框架现在可提供出色的文档和专业的开发团队的支持，而无需许可费。
Struts
开源框架的趋势始于Web应用程序。在1999- 2000年，开发者意识到了Java服务器页面“模式1”方式的困难，它包括在JSP模板处理传入的请求以及静态模板数据等。 这意味着JSP通常包含业务逻辑和复杂的HTML或其他标记。
在空间没有标准框架或者是没有J2EE特殊框架的支持下 ，开发人员只能用自己的前端控制器实现。这些行为将业务逻辑转移到Java类，从而消除了维护此类混合工件的需要。
在面向对象语言的GUI开发中常见的经典模型视图控制器架构模式之后，前端控制器模式通常被称为Web MVC。（这个名称有点误导，因为Web MVC视图必须从模型中提取信息，而在经典MVC，该模型推动事件浏览）
初始前端控制器的实现质量差异很大。Apache Software Foundation在2001 - 2002年发布的Struts（http://struts.apache.org）改变了这一切。虽然不是一个理想的Web MVC框架，但Struts工作得很好，很快就成为实际上的标准。
Struts证明开源框架的所有好处都是很适用的，如易于招募熟悉它的结构人才。 到2002年底，它是大多数J2EE Web应用程序的自然选择，每个认真的J2EE Web开发人员对它非常熟悉。
几乎普遍采用的Struts商品化了J2EE架构堆栈的一个重要组成部分。 即使是保守组织也在其软件基础架构的部分接受了它的使用，并同意Apache许可的条款。
Hibernate
下一个倒下的多米诺骨牌就是持久性。 J2EE“开箱即用”提供了两种访问持久性的方法存储-最常见的是关系数据库：JDBC，用于关系数据库管理系统访问的J2SE标准API；和实体bean，一种专用于对持久实体建模的EJB组件类型。
JDBC易出错的编程模型通过强制开发人员使用Java代码中的关系概念来禁止面向对象的设计。 尽管来自Sun和主要J2EE供应商的炒作，实体bean同样被证明是繁琐的：最初，该技术被严重低估，甚至没有被考虑到持久对象之间关系的管理;它使应用程序很难被测试; 它提供了不充分的查询语言。尽管EJB 2.0有所增强，但到2003年，开发人员基本上忽略了实体bean2.0和2.1。
早期努力。持久性问题的解决方案以对象关系映射（ORM）的形式出现，它为普通的旧Java对象（POJO）提供了透明的持久性，侧边栏中描述了一个概念，“无创框架：POJO的强大功能”。并非Java独有，ORM在Java领域中特别受欢迎，与怀疑此技术的NET开发人员相比正好相反。
商业ORM工具如Oracle的TopLink（www.oracle.com/技术/产品/IAS/排名靠前的链接），在90年代后期被很好地建立，而只是少数的项目使用它们，因为它们的成本昂贵，而且使用复杂，并出现了与实体bean标准冲突的标准。然而，它们通常在实践中取得比JDBC或实体bean更好的结果，从而证明了POJO持久性的情况。
Java数据对象，在2001年作为Java领域进程（WWW.jcp.org）的一个特殊对象出现，提供通用的POJO持久化到任何持久性存储（虽然实现通常提供关系数据库他们最好的支持）。然而,Suns lukewarm对JDO持有冷淡的态度，加上J2EE 厂商 缺乏当时POJO持久性间的EST，使得技术没能流行起来。
Hibernate到来了。2002年出现了根本性的变化，原因有两个。首先是普遍认识到实体bean已经在实践中失败了，开发商应该忽略J2EE规范的特殊部分。通过延缓而不是在推进的Java ORM的进步，实体bean仍然是一个很好的例子，说明糟糕的规范会如何扼杀高级技术的开发。
第二个因素是Hibernate（www.hibernate.org）的到来，这是一个流行的，功能齐全的开源ORM解决方案。Hibernate提供的功能少于TopLink，但提供了最理想的功能，并且其专注的开发团队积极寻求改进。基于对ORM的广泛理解，Hibernate并不是特别创新，但是它提供了比现有竞争对手更直观的编程模型，并一举消除了ORM的成本和易用性障碍。
大约在同一时间，新的商业产品提供了针对关系数据库的JDO规范的高效实现，为开发人员提供了丰富的选择。 与此同时，TopLink仍然是一个不错的选择，其许可证对开发人员来说更加友好。
ORM胜利。 总之，到了2003、2004年，所有的这些因素都集中在一起，使ORM成为规范而非例外。尽管一些项目仍构建了自己的持久性框架，但Hibernate，TopLink和领先的JDO实现的存在使得这种极其困难的工作变得不必要且不可辩驳。
应用程序堆栈的另一部分现在属于流行框架的领域，但仍然存在巨大差距。例如，使用Struts和Hibernate的典型Web应用程序仍然缺乏对业务逻辑的框架支持。虽然J2EE规范主要通过EJB解决了其中的一些问题，但是他们没有提供足够的应用程序编程模型。
Spring
J2EE框架不可避免地转移到应用程序框架中，旨在提供所有层中的一致编程，从而集成应用程序堆栈。 Spring Framework（www.springframework.org）是该领域的主导产品，其采用率与Hibernate相当。
Spring本质上结合了控制反转（ IOC ）和面向方面编程（AOP）—（侧边栏中描述的“无创框架：向POJO供电”）- 带有服务抽象，提供一个编程模型，其中应用程序代码是在POJO中实现，这些POJO很大程度上与J2EE环境分离（因此可以在各种环境中重用）。 Spring还在许多应用程序中提供了EJB的替代方法 - 例如，向任何POJO提供声明式事务管理。 事实证明，Spring方法可以在从小型Web应用程序到大型企业应用程序的各种项目中提供出色的结果。
同一空间中的其他产品包括 HiveMind （http：// jakarta.apache.org/hivemind），它在概念上类似Spring,但对 IOC 和NanoContainer （http：// nanocontainer.codehaus.org）） 有一些不同的看法。它结合了PicoContainer服务的IOC容器。总的来说，这些产品被称为轻量级容器，以区别于传统的J2EE方法。
通过将POJO模型与J2EE API分离,J2EE API在测试时很难被截取，轻量级容器极大地简化了单元测试。可以在普通的JUnit环境中进行单元测试，而无需将代码部署到应用程序服务器或模拟应用程序服务器环境。 鉴于测试驱动开发的增加和应得的普及，这是轻量级框架受欢迎程度的主要因素。
下一步是什么？
越来越多的人认识和使用J2EE开发框架可以显着降低许多项目的成本，并提供更快的上市速度和更高的可维护性。今天最好的框架提供优质，可靠的文档，以及许多支持其使用的书籍和文章。 尽管如此，J2EE领域的两个领域似乎也存在不确定性： J2EE “标准 ”与开源创新 之间 的 矛盾 ，以及AOP日益增长的重要性。
开源与标准之间的冲突主要表现在两个方面。在表示层中， 由Sun和一些最大的供应商支持的JavaServer Faces（JSF）与Struts等根深蒂固的开源解决方案展开竞争。在中间层，EJB 3.0提供了一个依赖注入功能，让人想起Spring的一部分功能，以及自由使用J2SE5.0注释。
在这两个领域，创新传统上都来自开源而非规范。 但是，JSF对ASP.NET有点亏欠，而开源 Tapestry项目（http：// jakarta.apache.org/tapestry）-许多相同概念的成熟实现 - 很大程度上归功于Apple的商业WebObjects。
同样，EJB 3.0似乎是试图标准化依赖注入，但目前还不清楚这会带来什么好处，特别是如果它导致的重要功能损失，这似乎是不可避免的。 EJB 3.0在进入应用程序空间方面也尝试了一个新的突破：J2EE至今为止还没出现的领域。
与此同时，AOP 的重要性正在J2EE领域内不断增加。虽然采用尚未普及，但是AOP的某些用途，如声明式事务管理，已经很普遍了。包括Spring和Dynaop（http：// dynaop.dev.java.net）在内的解决方案提供了可能被称为“带有训练轮的AOP”，有助于提高对AOP的认识。AspectJ等全面的AOP技术也可能在未来几年内得到更广泛的采用。
值得注意的是，Java领域流程没有显示任何标准化AOP的迹象，尽管JBoss（www.jboss.com）-公然致力于通过使用EJB 3.0规范的JCP - 正在积极寻求专有的AOP技术。
下一代J2EE规范作为一个整体正在采用一种更简单的POJO编程模型，类似于Spring和Hibernate等组合提供的模型。 J2EE开发人员肯定会从最近的趋势，这些趋势更多地是由实际经验驱动的，而不是由市场炒作驱动的。 这是平台早期的一个值得欢迎的变化，当时结果往往无法兑现供应商所承诺的承诺。
Rod Johnson是Interface21的首席执行官，Interface21是一家位于伦敦的J2EE咨询公司。 请通过rod@interface21.com与他联系。
编辑：Richard G. Mathieu，圣路易斯大学圣路易斯分校决策科学与管理信息系统部; mathieur@slu.edu
标注：
1、J2EE缺乏应用程序编程支持
尽管它在标准化与许多低级系统服务的交互方面取得了成功，但J2EE在很大程度上未能提供令人满意的应用程序编程模型。例如，Java Transaction API，Java命名和目录接口以及Java消息服务旨在容纳中间供应商;它们对应用程序开发人
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
