摘要：J2EE架构怎样理解？J2EE架构分析J2EE架构是当前主流的架构之一，目前大多数企业采用J2EE技术的结构设计与解决方案。J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可...

J2EE架构怎样理解？

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类都运行在同一个虚拟机中...

J2EE架构

模型-视图-控制结构是交互式应用程序广泛使用的一种体系结构。

它有效地在存储和展示数据的对象中区分功能模块以降低它们之间的连接度，这种体系结构将传统的输入、处理和输入模型转化为图形显示的用户交互模型，或者换一种说法，是多层次的We商业应用；MVC体系结构具有三个层面：模型（Model）、视图（View）和控制（Contolle），每个层面有其各自的功能作用，MVC体系结构如下： 模型层负责表达和访问商业数据，执行商业逻辑和操作。

也就是说，这一层就是现实生活中功能的软件模拟；在模型层变化的时候，它将通知视图层并提供后者访问自身状态的能力，同时控制层也可以访问其功能函数以完成相关的任务。

视图层负责显示模型层的内容。

它从模型层取得数据并指定这些数据如何被显示出来。

在模型层变化的时候，它将自动更新。

另外视图层也会将用户的输入传送给控制器。

编辑特别推荐： 指点一下：到底该不该去考JAVA认证？ Java认证权威问答精华集 控制层负责定义应用程序的行为。

它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作；在一个图形界面中，常见的用户输入包括点击按钮和菜单选择。

在We应用中，它包括对We层的HTTP GET和POST的请求；控制层可以基于用户的交互和模型层的操作结果来选择下一个可以显示的视图，一个应用程序通常会基于一组相关功能设定一个控制层的模块，甚至一些应用程序会根据不同的用户类型具有不同的控制层设定，这主要是由于不同用户的视图交互和选择也是不同的。

在模型层、视图层和控制层之间划分责任可以减少代码的重复度，并使应用程序维护起来更简单。

同时由于数据和商务逻辑的分开，在新的数据源加入和数据显示变化的时候，数据处理也会变得更简单。

软件架构设计和企业架构模式之间的关系是什么？

一般而言，架构有两个要素：它是一个软件系统从整体到部分的最高层次的划分。

一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。

详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。

所谓架构元素，也就是组成系统的核心＂砖瓦＂，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。

在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。

显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。

建筑设计基本上包含两点，一是建筑风格，二是建筑模式。

独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。

正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：·可靠性（Reliable）。

软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

·安全行（Secure）。

软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

·可扩展性（Scalable）。

软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。

只有这样，才能适应用户的市场扩展得可能性。

·可定制化（Customizable）。

同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

·可扩展性（Extensible）。

在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展

谁有物流管理软件 基于J2EE架构的

MVC主要适用于交互式的We应用，尤其是存在大量页面及多次客户访问及数据显示；相比较而言，一个工作流体系结构更多应用于过程控制和较少交互的情况下；除了体系结构外，J2EE的设计模式对我们解决应用系统的设计也有很大的帮助。

一、J2EE的模型-视图-控制（MVC）体系结构 模型-视图-控制结构是交互式应用程序广泛使用的一种体系结构。

它有效地在存储和展示数据的对象中区分功能模块以降低它们之间的连接度，这种体系结构将传统的输入、处理和输入模型转化为图形显示的用户交互模型，或者换一种说法，是多层次的We商业应用；MVC体系结构具有三个层面：模型（Model）、视图（View）和控制（Contolle），每个层面有其各自的功能作用，MVC体系结构如下： MVC 体系结构 模型层负责表达和访问商业数据，执行商业逻辑和操作。

也就是说，这一层就是现实生活中功能的软件模拟；在模型层变化的时候，它将通知视图层并提供后者访问自身状态的能力，同时控制层也可以访问其功能函数以完成相关的任务。

视图层负责显示模型层的内容。

它从模型层取得数据并指定这些数据如何被显示出来。

在模型层变化的时候，它将自动更新。

另外视图层也会将用户的输入传送给控制器。

控制层负责定义应用程序的行为。

它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作；在一个图形界面中，常见的用户输入包括点击按钮和菜单选择。

在We应用中，它包括对We层的HTTP GET和POST的请求；控制层可以基于用户的交互和模型层的操作结果来选择下一个可以显示的视图，一个应用程序通常会基于一组相关功能设定一个控制层的模块，甚至一些应用程序会根据不同的用户类型具有不同的控制层设定，这主要是由于不同用户的视图交互和选择也是不同的。

在模型层、视图层和控制层之间划分责任可以减少代码的重复度，并使应用程序维护起来更简单。

同时由于数据和商务逻辑的分开，在新的数据源加入和数据显示变化的时候，数据处理也会变得更简单。

二、J2EE设计模式 一个设计模式描述了对于特定设计问题被验证的解决方案，它综合了所有开发者对这个问题所在领域的知识和见解；同时也是对于常见问题的可重用方案，它们一般适用于单个问题，但是组织在一起就可以提供整个企业系统的解决方案。

什么是J2EE,什么是J2EE的架构,为什么要用J2EE进行企业级开发

【J2EE 体系结构简介】J2EE是针对web服务、业务对象、数据访问和消息传送的一组规范。

这组应用编程接口（API）确定了web应用与驻留它们的服务器之间的通信方式。

J2EE注重两件事，一是建立标准，使web应用的部署与服务器无关；二是使服务器能控制组件的生命周期和其它资源，以便能够处理扩展、并发、事务处理管理和安全性等问题。

J2EE平台为设计、开发、安装和部署企业应用提供基于组件的方法。

这种方法不但能降低成本，还能快速跟踪设计和实施。

J2EE平台能提供多层分布式应用模型，重复利用组件，提供统一安全模式，并灵活地控制事务处理。

借助J2EE，不但能更快地将客户解决方案推向市场，还能使基于J2EE组件、不依赖于平台的解决方案不被锁定到任何厂商的产品和API上。

J2EE规范定义了以下几种组件：1、应用客户端组件； 2、Enterprise JavaBeans 组件；3、Servlets 和Java Server Pages(JSP) 组件（也称为web组件）；4、 小应用程序 （Applet） 。

多层分布式应用模型意味着应用逻辑将根据功能分成几个部分，用户可以在相同或不同的服务器上安装由不同应用组件组成的J2EE应用。

应用组件的安装位置取决于应用组件在多层J2EE环境中属于哪一层。

A、客户端层 可以是在客户端层内运行的浏览器、基于Java的程序或者其它web型编程环境——在公司防火墙内部和外部。

B、应用服务器层 一般情况下，此层包含支持客户端请求的表示逻辑和业务逻辑 。

表示层由显示HTML页面的JSP页面和servlets实现。

业务逻辑通过RMI对象和EJB实现。

EJB依靠Container实现事务处理、生命周期和状态管理、资源池、安全等问题，简言之， Container就是EJB依赖执行的运行环境。

C、后端层 此层是现有应用和数据仓库的组合，也称为企业信息系统（EIS）层，因为它可以包含企业资源规划（ERP）、大型主机事务处理、数据库系统及其它遗留下来的信 息系统等许多系统。

...

用什么工具画 软件架构设计图

UIDesigner是腾讯用户研究与体验设计部（CDC）设计研发的一款设计类软件，打造一款可以让设计师统一平台和团队协作的平台型设计工具，经过1.0和2.0版本的经验沉淀，我们决定对3.0版本进行全新的架构设计。

开发一个软件系统，前期的架构设计承载着整个软件的设计思想和关键决策，可以说是重中之重。

根据软件架构设计思想，关注分割和交互，好的架构必须使每个关注点相互分离。

我们进行了最基本的需求分析，得出两个关注点：一是工具，二是设计绘图，关系如图1所示。

得到最基本的两个关注点后，接着将提取关键需求（包括：关键功能需求、关键质量需求和关键商业需求），根据两个关注点进行架构的细化设计。

一、关注点——工具 这里我们结合UIDesigner的实际需求，提取出属于“工具”范畴的关键功能需求、关键质量需求和关键商业需求。

首先，“工具”的关键功能需求，必须包括：磁盘文件读写、异常捕捉、日志记录、安全性管理；非工具所必须，但是UIDesigner本身所要求的，包括：配置管理、缓存管理、线程服务、服务器和客户端通讯管理、国际化服务。

其次，“工具”的关键质量需求，质量需求包括开发期质量需求和运行期质量需求两部分，经过分析和权衡，UIDesigner的性能主要取决于设计绘图，而稳定性、可扩展性和可维护性才是决定“工具”本身发展的质量需求，因此，对“工具”的质量需求设计将以稳定性、可扩展性和可维护性为主。

最后，“工具”的关键商业需求，因为UIDesigner本身并没有很复杂的业务需求，因此关键商业需求是在设计流程的优化和规范上得到体现，这方面的设计已经属于高层模块和使用流程的设计，对架构的影响非常小，可以暂时性的忽略。

经过关键需求的提取，我们得到了“工具”的设计目标——可以提供通用功能（关键功能需求）的高稳定性、扩展性和维护性的客户端应用。

根据此目标，我们采取了DI(Dependency-Injection)和MVP(Model-View-Presenter)结合的架构，概念架构设计如图2所示。

...