J2EE架构分析

J2EE架构是当前主流的架构之一,目前大多数企业采用J2EE技术的结构设计与解决方案。J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台,J2EE降低了开发多层应用的费用和复杂性,同时提供对现有应用程序集成强有力支持,完全支持Enterprise JavaBeans,有良好的向导支持打包和部署应用,添加目录支持,增强了安全机制,提高了性能。

高效的开发: J2EE允许公司把一些通用的、很繁琐的服务端任务交给中间件供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上,相应地缩短了开发时间。高级中间件供应商提供以下这些复杂的中间件服务:

状态管理服务 -- 让开发人员写更少的代码,不用关心如何管理状态,这样能够更快地完成程序开发。

持续性服务 -- 让开发人员不用对数据访问逻辑进行编码就能编写应用程序,能生成更轻巧,与数据库无关的应用程序,这种应用程序更易于开发与维护。

分布式共享数据对象CACHE服务 -- 让开发人员编制高性能的系统,极大提高整体部署的伸缩性。

支持异构环境: J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。J2EE标准也允许客户订购与J2EE兼容的第三方的现成的组件,把他们部署到异构环境中,节省了由自己制订整个方案所需的费用。

可伸缩性: 企业必须要选择一种服务器端平台,这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于J2EE平台的应用程序可被部署到各种操作系统上。例如可被部署到高端UNIX与大型机系统,这种系统单机可支持64至256个处理器。J2EE领域的供应商提供了更为广泛的负载平衡策略。能消除系统中的瓶颈,允许多台服务器集成部署。这种部署可达数千个处理器,实现可高度伸缩的系统,满足未来商业应用的需要。

J2EE使用多层的分布式应用模型,应用逻辑按功能划分为组件,各个应用组件根据他们所在的层分布在不同的机器上。传统的J2EE多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层,以下是 J2EE 典型的四层结构:

运行在客户端机器上的客户层组件

运行在J2EE服务器上的Web层组件

运行在J2EE服务器上的业务逻辑层组件

运行在EIS服务器上的企业信息系统(Enterprise information system)层软件

通常认为,J2EE平台就广泛的认为是这个架构,运行在J2EE服务器上的EJB容器可以认为是此结构的核心,EJB容器管理着所有EJB的执行,以及EJB的生命周期,并且为EJB提供所有系统级的服务。EJB组件则负责接受,处理WEB容器的客户请求和连接提供整个企业使用的数据,服务的EIS层。

此“经典”架构中,所有的数据访问都要通过entity bean,业务对象都是带远程接口的无状态session bean,运行在EJB容器中。EJB中包含了各种服务(比如声明式的事务管理),而且提供了一个共享的中间层,可支持可支持各种类型的J2EE客户端。但结构中应用性能和开发开销的负担很重,一些负载来在于EJB,而很大还是与分布式架构的特性有关。此外为了分布化,牺牲了OO原则,并且难以测试,因为业务逻辑通常编写在EJB的实现类中,而这些类完全依赖于EJB容器的。

此“经典”架构的一种改进,便是把远程EJB替换为本地EJB,实现了架构的重用,解决了分布化的种种问题。但架构还是相当的复杂。EJB的很多负担还是存在,从EJB中获得益处反而不多。

所以随着企业级应用开发的不断复杂,对架构设计的要求也会提出新的要求:

架构简单,但功能强大。

架构可以通过配置WEB容器集群来达到横向扩展。

在不同的应用服务器之间具有高移植性。

便于在应用服务器之外进行业务对象的单元测试,而且,一些集成测试甚至可以让一些轻量级容器(如Junit)来完成。

为了解决经典架构中有EJB引起的一系列问题以及满足不断发展的企业应用,提出了非EJB架构的“轻量级容器”。轻量级容器与EJB架构都是有容器管理业务服务对象,然后再围绕着这个服务层组织整个架构。但是业务对象不是运行在EJB容器中,而是运行在“轻量级容器”中。轻量级容器并没有和J2EE绑定,所以它既可以运行在WEB容器里,也可以在一个标准应用程序中运行,如必要也可以运行在EJB容器中。这个容器也没有和servlet API绑定?D?D这一点与MVC结构的WEB框架不同。轻量级容器的启动开销很小,而且无需EJB的部署。

轻量级容器提供了一种管理、定位业务对象的办法。用不着JNDI寻址、定制服务器之类的额外辅助;轻量级容器为应用对象提供注册服务。其较之EJB容器而言,不仅功能强大,而且避免了容器强制业务对象采用特定的接口,最低程度的降低了侵入性,实现了效果极佳的架构重用。

轻量级容器中所有的Java类都运行在同一个虚拟机中。

WEB层是由MVC框架提供的(Struts或WebWork,或Spring架构的MVC结构)

业务对象是POJO,运行在轻量级容器里。AOP的拦截机制能够增强业务对象,从而实现企业级服务。与EJB容器不同,业务对象不依赖于容器的API,所以这些对象在容器外也可以使用,更利于单元测试。业务对象仅仅通过接口来访问,当更改具体业务对象的实现类后,业务对象无需修改。实现了面向接口编程。

数据访问机制可以通过轻量级的O/R Mapping,该层能提供透明的持久化,该持久层实现了对数据访问方式JDBC的轻量级封装。

时间: 2024-09-13 10:20:48

J2EE架构分析的相关文章

基于J2EE架构的企业应用开发新思维:Web开发的困境

1前言 在企业级的应用系统开发领域,J2EE架构现在已经被普遍接受了.虽然它并未完全兑现刚刚出现时的种种美好许诺,跨平台,分布式,易于开发维护等等,但J2EE的广泛普及,已经是一个不争的事实. 虽然J2EE已经非常普及,但从技术上来讲,它本身还是存在很多缺陷的,比较突出的缺点,就是开发效率低,维护更加复杂,许多项目组都陷入其中不可自拔.本文将就造成这一现象的原因进行初步探讨,并在此基础上提出自己的解决思路. 本文讨论的范围仅限于采用B/S开发企业的应用系统,不涉及网站类型的应用开发.讨论的技术方

J2EE架构学习者的6个最佳实践

j2ee|架构 虽然许多文章曾经讨论过J2EE最佳实践.那么,为什么我还要再写一篇文章呢?本文究竟与以前的文章有何不同或者说比其他文章好在哪呢? 首先,本文的目标读者是正在从事技术工作的架构师.为了避免浪费大家的才智,我会避免讲述一些陈腐的最佳实践,例如"日常构建(build daily)"."测试一切(test everything)"和"经常集成( integrate often). 任何具有称职架构师的项目都有分工明确的.定义良好的团队结构.他们还为

J2EE架构的6个最佳实践

j2ee|架构 虽然许多文章曾经讨论过J2EE最佳实践.那么,为什么我还要再写一篇文章呢?本文究竟与以前的文章有何不同或者说比其他文章好在哪呢? 首先,本文的目标读者是正在从事技术工作的架构师.为了避免浪费大家的才智,我会避免讲述一些陈腐的最佳实践,例如"日常构建(build daily)"."测试一切(test everything)"和"经常集成( integrate often). 任何具有称职架构师的项目都有分工明确的.定义良好的团队结构.他们还为

Thrift的TProtocol类体系原理及源码详解:类继承架构分析

这部分相关的类主要实现与协议相关的内容,这里说的协议是指对数据传输格式封装的协 议,实现不同的协议来适合不同场景下的数据传输,因为在不同的场景下不同协议对于数据 传输来说效率有很大的差别.下面是这个部分相关类的类关系图: 由以上类图可以发现所有的协议类都从TProtocol类直接或间接继承,每一个协议 类都有一个对应的生产对象工厂(协议工厂).TProtocol是一个抽象的类,不能直接使用的 ,它有一个直接子类默认实现了所有方法(空实现),如果我们需要定义自己的数据传输协 议可以直接从这个类继承

基于J2EE架构的企业应用开发新思维:Web应用以谁为中心

基于J2EE架构的企业应用开发新思维:Web应用以谁为中心?浏览器?服务器 企业Web应用,指的是企业内部使用B/S架构搭建的企业信息系统,用户一般局限在企业内部,为了适应企业某个业务流程而设计开发使用的系统. 出于跨地域部署升级的考虑,一般采用B/S模式进行开发,避免在每个客户端安装配置的麻烦. 一般情况下,前台浏览器特指IE浏览器,前台操作系统选择Windows操作系统. 非Windows操作系统的客户机与非IE的浏览器不在本文讨论范围之内. 本文主要讨论以J2ee架构为基础的Web应用,其

android. mvc,mvp,mvvm架构分析

问题描述 android. mvc,mvp,mvvm架构分析 android现在流行三种架构,mvc,mvp,mvvm网上介绍的文档很多都介绍的比较浅,最重要的是没有完整的比较大的项目结合分析, 解决方案 本质上来说,mvc mvp mvvm是差不多的东西,只是在model,viewmodel和businessmodel的职责划分上略有不同.而且在"完整的比较大的项目",其实根本不能教条使用教科书上的某一种模式."介绍的文档很多都介绍的比较浅"恰恰说明了这一点--把

请问基于云架构的J2EE架构应该怎么做?

问题描述 如题,请问基于云架构的J2EE架构应该怎么做?与普通的J2EE架构的区别是应该理解为架构上的不同还是理解为业务逻辑编码实现的不同?谢谢大家! 解决方案 J2EE本身是接口规范,定义的大多为接口协议.基于云架构的J2EE架构语义表达不准确.云技术分为硬件云和软件云,主要指分布式计算.云架构也是针对云技术的系统架构.跟J2EE没什么关系.依托J2EE的技术规范,可以实现云技术.解决方案二:1.面向SOA架构,独立的组件和生命周期,寻址.服务等都是不定的2.存储时考虑的事情蛮多的3.J2EE

MSSQL - 架构分析 - 从SQL Server 2017发布看SQL Server架构的演变

title: MSSQL - 架构分析 - 从SQL Server 2017发布看SQL Server架构的演变 author: 风移 摘要 美国时间2017年10月2日,微软正式发布了最新一代可以运行在Linux平台的数据库SQL Server 2017.SQL Server 2017给用户带来了一系列的新功能特性的同时,也体现了微软关于自家关系型数据库平台建设方面的最新设计与思考.这篇文章旨在介绍SQL Server 2017新特性,以及微软是如何从架构层面的演进来快速实现Linux平台的S

面向服务的云制造系统架构分析

面向服务的云制造系统架构分析 康玲 吴华 王时龙 周杰 为了解决当前云制造尚缺应用模式的问题,根据云制造全生命周期智慧制造.按需动态构建及多粒度服务等特点,提出了基于Agent的云制造系统5层架构.基于面向服务的思想,建立了云制造OWLS本体模型,通过本体映射.推理机.匹配器完成服务请求.发布和绑定流程,提出了一种面向云制造服务的OWLS本体扩展框架和Web语义化描述方法,为云制造服务匹配奠定了理论基础.构建了基于Agent的云制造服务协商机制,通过Agent分工.合作.竞争及协商实现云制造