开源软件轻量级构架J2EE应用和迭代开发
来源:互联网 发布:asp.net 抓取网页数据 编辑:程序博客网 时间:2024/06/06 01:34
1. 引言
1.1. 背景
曾几何时,人们一提到J2EE就会想到EJB。EJB被人们当做J2EE的核心而顶礼膜拜。然而多年过去了,开发人员发现实际情况并不像EJB承诺的那样简单高效,在项目中使用EJB会导致一系列问题:花费的人力物力巨大;系统难于部署;代码不能重用;不容易进行轻量级测试。这几年随着开源社群和AOP的提出和成熟让开发人员看见了曙光。我们终于可以摆脱复杂的EJB部署,无处不在的侵入式代码,贵重的应用服务器的添置。在避免种种问题的基础上,我们仍然可以使用EJB给我们带来的系统级的支持和服务。
1.2. 简介
本文主要介绍如果不用EJB,J2EE还剩下什么。重点分析了四种不同的基于J2EE的系统应用架构的优缺点。以及为什么我们要使用开源软件,部分开源软件的简介。
在简要讨论了上述问题的基础上,我又就现在的开发方式进行了一些讨论。不断变化的用户需求一直在困扰着我们,使用传统的瀑布式的开发模型会带来许多问题,严重的会导致项目的失败。推崇使用基于迭代的开发方式进行开发,在文中罗列了一些优点。
2. 轻量构架J2EE企业级应用
传统的J2EE架构方案得到的结果常常无法让人满意:过于复杂的应用程序,令人失望的性能,难以测试,开发和维护的成本高昂。特别是EJB, 对它的批评从2002年末开始就逐渐成为家常便饭。
从EJB规范成型以来,许多事情都变了样:
² EJB规范中的一些部分已经过时。J2SE1.3引入的动态代理直接对EJB采用的容器代码生成机制提出了质疑。
² EJB最善于实现业务对象分布的体系结构,然而这种体系结构究竟有多达程度的普遍性,如今看来是相当值得怀疑的
² EJB规范正变得日益复杂,几乎没有哪个开发者或架构师有时间去通读它,更不用说是理解它了
² 严格的单元测试和测试驱动开发正在日益变得流行。然而大量的使用EJB的应用程序很难测试。
² 对于EJB致力解决的中间件问题,面向方面的程序设计的飞速发展为我们指出了一条更为强大和简单的解决之道。在某种意义上来说,EJB提供的服务只是AOP的子集。
没了EJB, J2EE还剩下什么?
从本质上来说,J2EE就是一大堆标准化的企业级服务的集合体:
命名和目录服务(JNDI)
异构的事务性资源提供的标准事务管理接口(JTS和JTA)
连接遗留系统的标准机制(JCA)
资源池、线程管理
EJB是开发者能够通过一个特定的组件模型使用这些用价值的服务,它仅仅是使用这些服务的手段之一。对EJB容器所提供的特有的服务,现在也有很好的替代品。
² Entity Bean:J2EE的数据库访问组件,也是J2EE最饱受非议的部分。有许多非J2EE产品可以很好的取代它。如Hibernate和JDO。在某些应用中JDBC是更好的选择
² 容器管理的事务:在J2EE中,EJB是唯一享受声明性事务管理待遇的。现在借助AOP, 我们同样可以让普通对象享受这一服务。
3. J2EE架构
J2EE应用系统把企业系统大致划分成三层结构
• 表现层
• 业务服务层
• 数据访问层
从上述角度,让我们来看一些重要的J2EE架构。举例四种不同的架构方案,其中两种到了EJB。我们主要关注的是基于Web的应用系统,虽然Web和其它的应用系统有一些区别,不过它们主要集中在UI,也就是表现层方面。服务层和数据访问层基本上都是一致的。
n 经典的J2EE架构(远程EJB)
n 本地EJB
n 自制的J2EE架构
n 使用轻量级容器(Spring, Pico Container)的架构
3.1. 经典的J2EE架构(远程EJB)
优势
l 提供了严格定义的服务层
l 提供了多种服务(事务管理,安全管理)
l 因为是分布式,给系统带来了很强的扩展性,提高了计算性能
劣势
l 系统的开销巨大,并且需要遵守大量的规范,有可能遇到框架本身的问题导致项目的失败
l 配置文件众多,部署复杂
l 用DTO来传输对象,造成资源的浪费,并且违背了OO的原则
l 分布式的系统难于调试
3.2. 本地EJB架构
优势
l 消除了分布式系统带来的种种问题
l 所有业务对象都在一个JVM实例中,不用再组装DTO来进行远程调用
l 性能的提高
劣势
l 因为需要实现或满足种种J2EE的规范,本地的开发和调试仍然复杂,配置依然繁琐,EJB的许多负担都还存在
3.3. 自制的J2EE架构
优势
l 能够在Servlet引擎中运行,抛开了对EJB Container的需要,节省软件费用的开支
l 实现简单。不需要再去强制实现EJB规范的接口和服务
l 部署容易,在Web Container之间可以自由移植
l 开发周期短,测试方便
劣势
l 没有清晰的服务层,对本应该由服务层提供的事务管理,安全性等系统级服务不提供内置的支持
l 缺乏一致性。不同的系统可能在资源的查找,业务对象的调用,数据的持久化等方面采用不同的策略。因为有着不同的学习曲线,所以各个项目之间人员不容易流动
3.4. 使用轻量级容器(Spring, Pico Container)的架构
优势
l 架构简单,功能强大
l 使用轻量级的容器时我们不用编写捆绑于特定容器的代码,方便移植
l 提供资源查找,安全等企业级的服务。如果容器支持AOP,我们可以使
用声明式的服务,如事务声明管理。
l 不需要EJB Container,即便是在一个Servlet引擎的容器中我们
仍然享用企业级的服务
l 在逻辑上分离了表示层和业务层,使得架构清晰明确,而且易于调试测试
劣势
l 跟EJB规范相比,轻量级容器还没有统一的标准。不过它的影响不大,
因为我们底层的代码没有跟容器绑定,只是一些POJO,仍然容易移植
l 开发人员需要花费时间来学习这些开源框架的使用
我们可以看到,在实际开发应用软件时使用开源的轻量级容器带来的好处是
巨大的。不过大家仍然有一个问题:我们自己开发了一个简单的应用框架,
各个层面的问题都考虑进去了,客户也认同。那我们为什么花时间来学习别
人的框架呢?开源业界有一句话,“不要重复发明轮子”。下面开始讨论这个问题。
4. 为什么使用开源软件?
面前有两条路:内部框架和开源source
比起开放源码的第三方解决方案,自主开发的内部基础框架明显处于劣势。后者的缺点在于:
² 浪费时间: 最好的开发者东希望投入到内部基础设施的开发,这能够体现他们的价值。然而这些开发者不应该去解决应用域的问题,而不是去解决那些别的优秀开发者早已解决过的,而且公开了解决办法的问题
² 困难:一个好的基础设施框架需要经过两到三次迭代的磨砺。照我的经验,已经成功解决了这些问题的开发者大多数知道有哪些出色的第三方解决方案可供选择,而且通常愿意使用第三方的方案,而不是自主开发它们
² 不标准:自主开发会让你得到一个私有的编程模型。新来的开发者必须熟悉这个私有架构,然后才能有所作为,这也就是意味着需要更多的培训
² 通常没有合适的文档:成功的第三方产品通常有完备的教材和范例,而自主开发的框架很难提供这些
² 社群支持:开源项目拥有庞大的用户社群,可以有效避免项目因缺乏支持而陷入的困境
部分开源软件介绍
AOP与Spring
u AOP(Aspect-Oriented Programming)
实现方式:
Java代码生成:EJB
语言扩展:AspectJ
J2SE动态代理:Java Dynamic Proxy
动态字节码生成:cglib, Javassit
u Spring
Spring是一个应用框架,并且还是一个IOC的轻量容器
Spring默认的使用J2SE动态代理
O/R Mapping 与Hibernate, IBATIS
IBATIS: SQL语句在XML文件中定义,并预留参数占位符。在执行时,占位符被指定的参数值所取代。在查询时,结果字段将被映射到对象。
Hibernate: 在JDBC上提供一层封装,同时提供完善的透明持久化;为应用程序增加O/R映射的语义,但又不脱离底层的关系数据库
WebServices与Apache SOAP, AXIS
WebServices:
² UDDI
² SOAP
² WSDL
5. 开发方式
开源软件和工具的并不是“银弹”
Frederick Brooks的在一篇题为“没有银弹”的论文中驳斥了“相信软件中存在某种特殊的工具或技术,可以在生产率,缺陷减少,可靠性和简易性等方面带来极大的变化”的错误认识。
现代项目的主要特点是什么? 客户不知道要什么,变更频繁
开发方法
随着我们所开发的软件项目越来越复杂,传统的瀑布型开发流程不断地暴露出以下
问题:
²