CSDN博客

img cx0998

J2EE设计模式分析与实践——J2EE技术新论

发表于2003/7/2 23:13:00  1115人阅读

 

第二章 J2EE技术新论

第一节 J2EE技术的整体观                                                          

现代软件逐渐流行起来的研究方法首先必从所谓体系结构看起。这种看法颇有道理:从整体着眼可以看得清楚、有居高临下的感觉,不但看得远,而且可以看得清晰。看得清楚意指一个东西,如J2EE,他里面到底有那些东西,有了体系结构图,可以一目了然。所谓看得远,可以从体系结构中看开去,能够从体系上自然地与其他技术体系比较,看出这种体系的优点体现在哪里、缺点又表现在哪里、今后发展的方向应该在哪里;所谓看得清晰,意指一个体系结构中各种元素彼此之间的交错众和、文理经脉能够一目了然,比清楚又进了一层。所以无论是初学者,还是资深的体系架构师,他们有一个共同特点就是一定喜欢看体系结构图。J2EE首先是个有机的整体,她以J2SE为基础,包含13种主要技术,请看其结构图:

 

 

(1)

上面可以看到J2EE平台的整体结构,他的大部分核心技术也有标明:JDBC, EJB, RMI, JSP, JAVA SERVLETS, XML, JMS, JTS, JTA, JAVAMAIL 和 JAF。其实J2EE本上由一整套服务(SERVICES)、应用程序接口(APIS)和协议构成,它对开发基于WEB的多层应用提供了功能支持。J2EE还要求描述在何时、何处需要使用这些技术。当然,知道这些不同的技术之间是如何交互的是理解J2EE而必须的。

过去,二层化应用 -- 通常被称为CLIENT/SERVER应用 -- 是大家谈论的最多的。在很多情况下,服务器提供的唯一服务就是数据库服务。在这种解决方案中,客户端程序负责数据访问、实现业务逻辑、用合适的样式显示结果、弹出预设的用户界面、接受用户输入等。CLIENT/SERVER结构通常在第一次部署的时候比较容易,但难于升级或改进,而且经常基于某种专有的协议—通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。更重要的是,在WEB时代,二层化应用通常不能体现出很好的伸缩性,因而很难适应INTERNET的要求。

SUN设计J2EE的部分起因就是想解决二层化结构的缺陷。于是,J2EE定义了一套标准来简化N层企业级应用的开发。它定义了一套标准化的组件,并为这些组件提供了完整的服务。J2EE还自动为应用程序处理了很多实现细节,如安全、多线程等。

J2EE开发N层应用包括将二层化结构中的不同层面切分成许多层。一个N层化应用能够为以下的每种服务提供一个分开的层:

  显示:在一个典型的WEB应用中,客户端机器上运行的浏览器负责实现用户界面。当然终端类型可以多种多样。

  表示层: 尽管浏览器可以完成某些动态内容显示,但为了兼容不同的浏览器,这些动态生成工作应该放在WEB服务器端进行,使用JSP、SERVLETS,或者XML(可扩展标记语言)和(可扩展样式表语言)。

  业务层:业务逻辑适合用SESSION EJBS(后面将介绍)来实现。

数据访问:数据访问适合用ENTITY EJBS(后面将介绍)和JDBC来实现。 同后台系统的集成可能需要用到许多不同的技术,至于何种最佳需要根据后台系统的特征而定。

为什么有这么多的层?事实上,多层方式可以使企业级应用具有很强的伸缩性,它允许每层专注于特定的角色。例如,让WEB服务器负责提供页面,应用服务器处理应用逻辑,而数据库服务器提供数据库服务。

由于J2EE建立在JAVA2平台标准版(J2SE)的基础上,所以具备了J2SE的所有优点和功能。包括“编写一次,到处可用”的可移植性、通过JDBC访问数据库、同原有企业资源进行交互的CORBA技术,以及一个经过验证的安全模型。在这些基础上,J2EE又增加了对EJB(企业级JAVA组件)、JAVA SERVLETS、JAVA服务器页面(JSPS)和XML技术的支持。  

有了上面的介绍,如果不纠缠于细节技术的实现(这样才有架构师的气魄),脑子里应该就有了如下的J2EE体系结构图:所有实现J2EE规范的Application Server都必须完成完全的web Container与EJB Container功能。有关Application Server 的选择和比较在下文有更详细的介绍。

(图2)

第二节 J2EE技术的模式观

在学习了Java后学习J2EE,一般人都会有这样的感觉:入门很容易,但是要向前进一步似乎像赶鸭子上架,很难。原因在哪里?本质上说,是没有理解J2EE,不知道他里面到底体现了什么,仅仅知道他的组成部分虽然是必须的,但是却不是足够的。我们需要用一种全新的眼光来审视这种祥和的技术,可以这么说,本质上J2EE是一种框架结构,框架就是骨架的意思。他不同于我们学习的Java语言,我们在学习Java语言时候用的是API,那是工具箱。而J2EE不同,它的应用领域是一开始就定义好了的,所谓Java Two Enterprise Edition,就是说让Java用于企业领域。既然领域定好了,它就自然可以定义一套在这一领域不变的架构。如它定义了JTA、JDBC和EJB可以用来处理企业的事务要求、大量的数据库操作需求等。企业一般要用到邮件订阅、消息处理,可以使用J2EE技术里有机结合的JMS,企业安全性要求比较高,J2EE提供系统的安全解决方案,它定义了JAAS等。实际上,各种技术是一个整体并且可伸缩,每个J2EE应用都是按照其体系结构提供有机的J2EE技术组装。例如表示层技术典型的可以用JSP作配件,非典型的可以用WAP作配件,不管怎样他们都是J2EE的脸面;业务层技术典型的可以是EJB,非典型的可以是servlet甚至JSP,这些才是业务处理逻辑的核心技术,往往安全性等要求很高;资源层连接典型的是JDBC,非典型的用JDBC-ODBC等。从上面可以看到,J2EE在设计上就是框架结构导向的技术――只不过这种框架结构有极强的伸缩性和可扩展性。框架结构意味着一种思想的实现,大的方面J2EE广泛应用于企业计算,据信国外1998年后出现的门户大多采用J2EE技术。模式为在框架内构成高效的内容提供支持。广义上J2EE还是MVC模式的一种实现。上图中客户端得到View,中间层是Controller,后台则是Model。所以,在企业应用这种情境下,J2EE可以采取不同的适合情境应用的解决方案(使用各种套件)。不变的东西已经定义好了,变化的则交由程序员来处理。有人也许会想起.Net,实际上她也是一套框架结构,可以说成是“超级(抄袭)模式”应用框架结构:-:)。

下面我们用模式的眼光来审视J2EE架构的特点(注意并不是每个框架都有这样的特点的,J2EE灵活性做到了最大):

首先,灵活性。灵活性意指这种结构或模式是不依赖于任何实际应用,应该与操作系统、应用程序无关。提供独立的结构,可以提供最大的重用。

其次,可扩展性。新技术的发展是很快的。试想一个基于现有J2EE技术的应用,如果哪天JDO被引入规范,这种应用还是基于“J2EE”的吗?即J2EE的扩展会不会影响已有的应用的问题。可扩展性的应用架构是不会影响已有的应用的。J2EE的分层实现思想提供了各种技术的平滑过渡。

再次,可伸缩性。对于集群应用,这种功能要求体系的一览无余。迄今为止,除了在操作系统级集群能作的比较好外,在应用级恐怕只有J2EE能够很好的做到这一点了。

然后,可配置性。应用本身是变化的,因为需求随着人员的调用、业务的增长在不断变化。这样在配置应用时就需要有一定的灵活性。例如资源的访问控制,以前只有少许几个WEB资源,可以提供给大多数人访问;随着业务的扩展,新的业务不断增加,业务逻辑自然增加,这种资源的控制就需要一套灵活的机制来做调配。在J2EE中XML文件可以提供这种灵活的控制。

最后,安全性。进来由于网络环境的改善,网络应用呈爆炸式增长。在网络上一个基本的问题就是安全。一个安全的应用应该提供统一的用户访问控制即提供单入口点。J2EE天生为网络环境而诞生。J2EE模式中前端控制器等可以实现要求的安全控制。

0 0

相关博文

我的热门文章

img
取 消
img