J2EE平台多层体系架构

传统B/S开发模式历程
浏览器 浏览器 浏览器
Web 服务器 应用服务器
界面逻辑 业务逻辑
数据层
数据层
数据层




3层体系结构 界面逻辑/业务逻辑统一在系统主 机上；系统升级、实施、部署方 便 可以跨平台访问数据库，实现数 据共享 一致的用户界面交互方式。 有些产品实现面向部件的复用能 力 常用工具: Asp , 普通JavaBean
Java 命名联编方式
真正的面向命名联编方式 A) Java程序编译成目标文件后，与系统地址无关； 通过名称找到过程所引用的变量或方法。 B) 系统开发初期，可以按系统定义空的框架结构供其他开发者使用；待开发完毕后， 再发布到系统上，而不需要和其他模块一起联编。 C) 只与java 路径名称有关，与系统物理目录无关；在J2EE 架构中，甚至与对象运 行所在的主机无关。 该技术所带来的优势 A) 各种的功能模块无须联编，只需要定义模块框架，即可在共同发布后使用。便于 各种业务模块分工合作、集群开发，代码或版权保密。 B) 可以方便的实现系统模块的部件化，从而达到产品的可重用能力。 C) 便于部件的部署；部件的部署可以在本机，也可以在J2EE架构的异地主机。 D) 实现面向功能单点级别的升级或修正。任何一个功能模块修改后，无需整个系统 联编，既可使用。

如何紧跟系统平台日异月新的升级换代。
系统管理员关心的问题

系统健壮性问题
应用主机系统Down机了，怎么办？

系统安全
如何保证系统不被非法使用?

如何改进系统运行效率
复杂的应用、数量庞大的用户，如何控制系统资源的耗费？ 传统方式下，系统资源的耗费随着用户数量的递增而递增……

系统软件的更新
应用软件更新后，如何让数量庞大的前端用户也更新？

如何复用以前开发的软件部件或产品？
A) 面向过程代码级的复用。 B) 面向初级部件级的复用。

如何满足用户的性能要求?
系统响应能力与用户数的增加、安全要求、动态均衡、系统强壮性要求……. 很多需要自己开发。

开始系统实施，要跑遍所有的业务点安装。
C/S开发模式历程


2层体系结构 2.5层体系结构 3层体系结构
目标代码与系统平台无关

Java 虚拟机 可以在不同的系统软件、不同的硬件平台运行。( 2 PlatForm ) 系统平台的变化，不会影响已经投资开发的应用软件。 如：硬件系统、操作系统、数据库系统。
模板式的类继承方法
传统的面向对象的方式;如 C++ , Delphi BaseClass Data1,Data2 Method1, Method2 继承 重载 操作的是基类 BaseClas 的属性、方法
J2EE 平台多层体系架构
Java 2 PlatForm Enterprise Edition
信息部门主管关心的问题

信息孤岛问题。
不同的部门有不同的应用系统，使用传统的开发工具，无法实现信息的共享互用。 如何实现不同系统间信息的互用？

如何保护系统的投资？
业务在不断地发展，系统在不断地升级，单位在不断地投资… … 在传统的开发方式下，除了部分模块、函数能够在升级产品中利用来，其他大部分要推倒重做， 需要重新投资完成以前投资的内容，造成极大的浪费。 如何保护以前的投资，使以前开发的应用产品能平滑地在新系统中使用？
系统偶合模型发展历程




面向过程、代码的系统紧偶合 需要与系统联编，与系统一起打包 接口不标准而且复杂，需要知道过程或代码接口 产品复用能力低 面向组件级的系统紧偶合 需要与系统联编，并需要准确知道组件部署所在的位置 接口不一定标准而且复杂，需要知道组件的应用接口 产品复用能力较高 面向部件的系统松偶合 不需要了解部件部署的位置 接口不一定标准，需要知道部件的应用接口 产品复用能力高 面向服务的系统无关联松偶合 不需要了解服务部署的位置 应用接口标准化；不需要知道服务的具体应用接口 产品复用能力高
ExtendClass 对象 V_extend 强制转换为基类
ExtendClass 对象 V_extend 强制转换为基类
操作 (BaseClass) V_extend 中的重载属性或方法
操作 (BaseClass) V_extend 中的重载属性或方法
模板式的类继承方法
A) 可以制定统一的业务处理接 口标准；实现不同业务系统 间无逢的信息共享。 B) 可以方便的实现不同业务的 流水化处理作业。 C) 通过接口的标准化，真正面 向部件的产品复用能力；保 护系统原来的投资。
Web包容器—Web 请求
Java 虚拟运行环境 一个Http请求启动一个线程 Web 服务的提供者 A) 打包Http 请求，组成标准的 Java HttpRequest 对象 B) 根据Http 请求地址，路由寻找 对应 的 Serverlet 类或Jsp Web 部署描述器

浏览器 1 Web 包容器 浏览器 2 HttpRequest 界面逻辑类 2 界面逻辑类 1

J2EE 系统结构

Java 2 Platform Enterprise Edition 是一些列技术规范以及成熟的组件或部件的总和 在Java 语言的基础上；通过一系列框架基本类，规定一些商业部件的编 程规范，以及一些成熟的商用部件
J2EE的总体结构
客户 应用逻辑 Web包容器
JDBC (X)HTML/ XML HTTP(S) Servlets JSPs 标记库
基类
定义接口模板标准：busiStand
扩展类
业 务
业 务
业 务
可以按统一的接口标准 busiStand 执行
A
逻 辑 类
B
逻 辑 类
C
逻 辑 类
面向命名的系统联编


传统工具连编方式：面向地址 A) 变量：编译联编完成后，通过地址访问变量中存储的内容 B) 过程或方法：联编完成后，也是转换成地址的方式，供其他过程调用。 C)联编系统中任何一个模块发生变化，都需要重新联编，以重新确定地 址。 动态连接库 A) 通过命名的方式供其他过程调用。 B) 通过字符串的方式供过程调用，不参与系统编译，无法事先发现错误。 C) 动态连接库调用接口繁杂；仍然需要调用者重新确定系统地址后，再 执行。 D) 动态连接库是以库的方式提供命名连编。
怎么又要下载更新？ 系统又不能用了
传统工具往往需要在客户端配置参数或安装驱动程序，如果前端用户环境发生变化，可能导致 系统无法正常使用。

系统太慢了
当用户数量增多，系统负载变大，慢
开发商关心的问题

如何解决成本问题？
传统方式，要求开发人员的技术比较全面，从界面、前端开发工具、数据库工具…… 成本比较高。
数据
RDMS
JavaMail
RMI/IIOP JTA JNDI JavaMail JAF
J2EE应用 服务器
邮件服务器
JMS JDBC
Applet
RMI
Java 应用程序
EJB包容器
客户应用 程序 会话 Beans 实体 Beans IIOP
CORBA 服务器
RMI/IIOP JTA JNDI
JavaMail JAF
JMS JDBC
JNห้องสมุดไป่ตู้I
目录服务
JMS
消息队列
Web包容器

客户
界面逻辑
应用逻辑
JAF

Web包容器
(X)HTML/ XML HTTP(S) Servlets JSPs 标记库 RMI/IIOP JavaMail JMS JDBC JTA Applet JNDI


Java 虚拟机环境，单进程，多线程 运行环境 Web 服务的提供者，管理者 标准规范 HttpServerlet 规范 Jsp 规范 提供组件 JAF RMI/IIOP JavaMail JMS JDBC JTA JNDI 传统的Java Web 应用程序所在地 Tomcat等

如何保证质量
传统方式，每个开发人员都可能涉及到软件系统的各个层次，要求每个开发人员都要关心、注 意各个环节的技术细节，质量隐患点太多了。

如何保证开发进度
传统方式，各种业务模块都需要自己开发

如何满足用户对其他系统中的信息处理需求？
A) 需要开发与该系统相近的处理代码；工作量太大了。 B) 对其他系统的业务、实现方式不了解；直接操作外部系统，风险太大了。 C) 每个外部系统的接口都不一样，都要分别编写，太难了。
面向模板的 Java 类继承方法 BaseClass Data1,Data2 Method1, Method2 继承 重载
ExtendClass Data1,Data2 Method1, Method2
ExtendClass Data1,Data2 Method1, Method2 操作的仍然 ExtendClass 的属性、方法

如何减少系统的投资？
复杂的应用、数量庞大的系统用户，需要昂贵的系统硬件来支撑… …. 如何改善系统购价，以期达到最少的投资？

如何面对瀑涨的应用要求？
应用在不断地添加、完善，处理不断地变得复杂，系统应用人员在不断地增 加…… 主机系统已经变得不堪重负。是更换更加昂贵的主机设备，还是添加一些比较廉 价的主机系统，由系统动态均衡负载？ 在传统的方式下，只能通过更换更加昂贵的主机系统。
•
信息孤岛问题 直接操作不同系统的数据 没有标准的接口方式 • 可重用性: 简单部件或过程，没有标准 • 没有资源管理，无法满 足复杂及大用户量的应 用要求。
J2EE 多层体系架构


J2EE 技术基础 J2EE 概述 J2EE 带来的优势
J2EE 基础：Java 的技术特点

目标代码与系统硬件平台无关 模板式的类继承方法 面向命名的系统联编 其他优势 面向对象的编程方式 准C ++ 语法结构；解决地址管理问题 众多厂家支持；统一版本标准 IBM WebSphere; WebLogic ; Oracle OC4J Sun 公司统一标准。
2层、2.5层体系结构
界面 业务逻辑 界面 业务逻辑 界面 业务逻辑
界面
界面
界面
数据库服务器
业务逻辑 数据库层



随着用户数增加，系统资源耗费成几何级数增加，而且很多资源耗费呈空闲浪费。 部署不不方便 A) 系统实施问题 B)界面要求更新问题 C) 业务逻辑更新问题 D) 系统负载问题 E) 系统健壮性问题 产品可复用能力带来的投资保护问题 A) 面向过程代码级的复用 B) 更换开发商，可复用能力基本=0 信息孤岛问题 开发商产品难题

C/S 3 层体系架构
界面 界面 界面
中间件
业务逻辑/系统资源管理
数据层
数据层
数据层
系统部署问题 • 优点 系统实施、界面逻辑更改、客户端环 A) 系统资源管理(连接池) 境变化 B) 业务逻辑可重用程度比较高 C) 有些产品可以在业务逻辑层完成不 信息孤岛问题 同系统的信息共享 直接操作不同系统的数据,没有标准的接 D) 跨平台信息共享 口方式，获取外系统的信息 可重用性:面向简单部件或过程
浏览器 3
HttpRespon se
界面逻辑类 3

Serverlet, Jsp
Web包容器---Jsp 规范


提供了纯Html 与 java 相结合的界面逻辑编程方式 例子
<%@ page contentType="text/html;charset=GBK"%> <%@ page import="fzeys.http.*"%> <%@ page import="fzeys.service.*"%> <% HttpRequest V_HttpRequest = new HttpRequest( request , response ); ServiceResult V_ServiceResult = ServiceManager.httpInterface( "BookManager.AddBookTrans" , V_HttpRequest ) ; if( V_ServiceResult.hasError() ) { System.out.println( "Result Has Error"); out.println( "Error: <br>" + V_ServiceResult.getErrorMessage()) ; return ; } System.out.println( "Result Has no Error"); if( V_HttpRequest.getParameter("Add") != null ) { System.out.println( "Redirect:"); response.sendRedirect("book_edit.jsp?bookno=" + V_HttpRequest.getParameter("BookNo")); return ; } %> <HTML> <HEAD> <TITLE></TITLE>
系统用户关心的问题

面对这么多的应用系统，怎么办？
一种应用系统一套软件，电脑桌面上的应用系统越来越多了。 不同的系统有不同的界面，不同的操作方式，需要不断的学习，命苦啊… … 不同的系统要记住不同的登录口令，真是命苦… … 不同的系统信息在各自的系统中展现，没法统一起来使用，还要手工计算，烦……