• 1. 应 用 服 务 器1
  • 2. 人们必须 不断地 提取 软件的共性成份 屏蔽 系统低层的复杂度 从而 在高层保持复杂度的相对稳定 2
  • 3. 内 容 一、动因 二、产生基础 三、结构与功能 四、现状与未来3
  • 4. 一、动因操作系统数据库管理系统应用服务管理系统(应用服务器)4
  • 5. 初始状态:硬件 + 程序程序的共性(稳定)成分:计算资源管理操作系统应用程序产生了:分离出了:软件硬件操作系统5
  • 6. 初始状态:硬件 + 操作系统 + 应用程序程序的共性(稳定)成分:数据管理产生了:数据库管理系统分离出了:应用软件操作系统操作系统数据存储文件数据库管理系统应用程序6
  • 7. 程序的共性(稳定)成分:网络资源管理产生了:应用服务器分离出了:业务逻辑(构件)初始状态:硬件 + 操作系统 + 数据库管理系统 +应用软件7
  • 8. 二、产生基础1、中间件在操作系统与应用系统之间的一层软件 为分布式应用的开发、部署、运行与管理提供支持 (1)终端仿真/屏幕转换中间件 用以实现 客户机图形用户接口 与 已有的字符接口方式的服务器应用程序的互操作 (2)数据访问中间件 为了建立数据应用资源互操作的模式 对异构环境下的数据库实现联接或文件系统实现联接的中间件 (3)远程过程调用中间件 程序员方便地编写客户端应用程序 调用位于远端服务器上的过程8
  • 9. (4)面向消息中间件 用来 屏蔽各种平台及协议之间的特性 进行相互通信 实现应用程序之间的协同 (5)事务(交易)中间件 在分布、异构环境下 提供保证交易完整性和数据完整性的一种环境平台 (6)对象中间件 在分布、异构的网络计算环境中 将各种分布对象有机地结合在一起 完成 系统的快速集成 实现 对象重用9
  • 10. 2、网络软件总体结构 OMG 的 OMA 微软 的 DNA SUN 的 J2EEOSF 的 DCE10
  • 11. (1)OMA 世界上最大的计算机工业联盟、非赢利性组织 于1989年4月由8个公司发起 目前有800多家成员 全职工作人员只有20人左右 自身不做标准制订和开发工作 仅提供一种组织和机制 支持OMG成员 进行 交流、合作 制订 技术规范 开发 符合标准的商用产品两个重要的基石: 面向对象方法 商业可用性OMG:11
  • 12. OMG的组织结构Board of Directors(BOD)Platform Technology Committee(PTC)Domain Technology Committee(DTC)Architecture Board(AB)Task Force(TF)Special Interest Groups(SIG)Task Force(TF)Task Force(TF)Special Interest Groups(SIG)Special Interest Groups(SIG)……12
  • 13. OMG技术采纳过程:RFIRFPSpecification Specification Specification everyonePart of membersTF起草 DTC或 PTC发行TF起草 AB评审 DTC或 PTC发行…TF评估、推荐 AB评审 DTC或 PTC批准BOD批准13
  • 14. 总线计算机硬件中的模块及互联方式:14
  • 15. Object Request BrokerObject ServicesApplication InterfacesDomain InterfacesCommon FacilitiesOMA:Object Management Architecture15
  • 16. ORB:“Object interoperate bus”Object Request BrokerORB CoreORB CoreORB Core16
  • 17. 17
  • 18. Services:“Abstractions for Classic System-Programming Functionality”Object Request BrokerTradingEventsSecurityNamingLifecycleTrans- actionsPersis- tence18
  • 19. Facilities:“High Level Services: Domain Specific and Generic”Object Request BrokerSystem Mgt.FinanceComp. Doc.TelecomBus. ObjectHealth -careManuf.19
  • 20. (2)DNA20
  • 21. 21
  • 22. Presentation Level22
  • 23. DNA 提供多种表示服务 开发者可以根据具体情况选择最佳方案 HTML Scripting DHTML Components Win32 API 以支持丰富的界面与客户环境 从手持无线设备到高端工作站23
  • 24. Business Logic Level24
  • 25. Component Services 基于互操作模型 Component Object Model(COM) 增强分布处理功能 Microsoft Transaction Server (MTS) 目前已发展为COM+ 通过降低为利用底层系统服务而编写的代码量 使开发分布式应用系统更为 快速 容易 廉价25
  • 26. COM+ 服务包括新的或增强的服务包括: Bring your own transaction. COM 构件可以参与由非COM+ 事务处理环境管理的事务 只要它支持Transaction Internet Protocol (TIP) Load balancing. 基于构件的应用程序可以以客户透明的方式 在应用程序群中分布工作负载 In-memory database. 内存数据库是一个事务性数据库系统 用以支持对数据的快速访问26
  • 27. Queued components. 异步执行在网络环境下是不可避免的 队列可以对异步执行提供良好支持 Event notification. COM+ 事件是同时支持单播/多播、发布/订阅的事件机制 允许多个客户“订阅”由各种服务器“发布”的事件 Expanded security. 支持基于角色的安全与处理访问许可安全 COM+ 增加了方法级安全 Centralized administration. Component Services Explorer提供了一致的管理模型 减少了部署、管理及监控 n层的应用程序27
  • 28. Messaging Services Microsoft Message Queue Server 提供 松耦合、可靠的通讯服务 通过实现 push 风格的商务事件方便了应用系统的集成 在不可靠、代价低的网络上建立起可靠的应用系统 Microsoft Message Queue Server 还提供了 与其它消息队列产品的无缝连接 例如:IBM’s MQSeries等 28
  • 29. Web Application Services Internet Information Server (IIS) 可用于 开发基于Web的商务应用系统 这样的系统便于扩展、便于部署 作为IIS技术之一的Active Server Pages(ASP) 具有 语言中立 编译省缺 的特点 是服务器端脚本环境 用于创建、运行动态且交互的Web服务器应用程序 利用ASP脚本及其它协调构件构造的应用程序 可以与现有的系统、应用程序及数据协同工作29
  • 30. Data Level30
  • 31. Universal Data Access 提供对各种信息资源的高性能访问 包括关系、非关系数据 提供独立于工具与语言的编程接口 Universal Data Access 基于开放的工业规范 得到了工业界及数据库厂商的广泛支持 31
  • 32. DNA中基于Universal Data Access的框架包含两层: 在系统层: OLE DB 定义了一个基于构件的体系结构 封装了各种数据库管理系统服务 OLE DB 不对数据源进行约束 在应用层: ActiveX Data Objects (ADO) 提供了高层接口 使开发者可以从任何编程语言访问数据 在每一层: eXtensible Markup Language (XML)使开发者 可以在应用程序客户之间进行 描述、交付、交换结构化数据 XML 也可以在服务器之间进行结构化数据的传送32
  • 33. (3) J2EEJava™ 2 Platform Enterprise Edition(1.2) JAVA: Language Runtime(virtual machine) Platform : J2SE J2EE J2ME 背景33
  • 34. JavaTM 2 Platform, Standard Edition (J2SETM) J2SE 为构造并部署网络为核心的企业应用系统 提供一个完整的、安全的基础 其范围从PC桌面到工作组服务器 J2SE 包括: Java 2 (SDK), Standard Edition Java 2 Runtime Environment, Standard Edition34
  • 35. JavaTM 2 Platform, Enterprise Edition(J2EETM) J2EE是Java 2平台的一个完整版本 将业务紧要(Mission Critical)的企业应用系统 推向任何 web 浏览器 J2EE将SUN公司的多种技术集成到一个体系结构中 并提供了一种应用程序编程模型、兼容性测试套件 以降低开发网络软件的复杂性与代价35
  • 36. JavaTM 2 Platform, Micro Edition (J2METM) J2ME是端到端(end-to-end)的Java 技术 适于正在增长的消费类与嵌入式市场 J2ME 是一个被高度优化的运行环境 以下列消费类产品为目标: pagers cellular phones screenphones digital set-top boxes 以及 car navigation systems 36
  • 37. 总体结构37
  • 38. J2EE 支持4类构件: Application clients Applets Servlets and JSP pages Enterprise JavaBeans 包含的构件38
  • 39. 容器为应用构件提供了运行态支持 在J2EE服务与应用构件之间增加一个服务器 使得容器可以透明地利用构件的部署信息( deployment descriptors )获取J2EE服务提供的功能 例如:事务管理、安全检查、资源缓冲、以及状态管理等 一个典型的 J2EE 产品为每一类的构件提供一种容器: application client container applet container web component container 以及 enterprise bean container构件容器39
  • 40. 一个资源管理驱动器(驱动器)是一个系统级软件构件实现与外部资源管理器的网络连接 一个驱动器能够扩展J2EE平台的功能 途径为: 实现J2EE的一个标准服务接口 API (例如 JDBC driver) 为一个外部应用系统的连接器( connector ) 定义并实现一个资源管理器驱动器资源管理器驱动器40
  • 41. J2EE 平台包含可以通过JDBC API访问的数据库 用于存储业务数据 数据库 可以从 web components enterprise beans 以及 application client components 访问 但不可以从 applets访问数据库41
  • 42. J2EE 标准服务HTTP HTTPS JTA RMI-IIOP JavaIDL JDBC JMS JNDI JavaMail JAF Connector JAXP JAAS …42
  • 43. HTTP HTTP client-side API 由 java.net package 定义 HTTP server-side API 由 servlet and JSP 接口定义 HTTPS 支持HTTP的上述接口同样支持基于SSL协议的HTTP43
  • 44. Java Transaction API (JTA) Java Transaction API 包括两部分: 应用级接口,容器与应用构件用它来声名事务边界 J2EE SPI级接口,事务管理器与资源管理器之间的接口 SPI:service provider interface44
  • 45. RMI-IIOP 组成RMI-IIOP 的APIs 包括: 独立于底层协议的 RMI风格的编程接口 上述API的实现,支持 J2SE RMI protocol (JRMP) 及 CORBA IIOP J2EE 应用系统可以使用RMI-IIOP(在IIOP协议的支持下)访问与RMI编程约束兼容的 CORBA services45
  • 46. JavaIDL JavaIDL 使得J2EE 应用构件可以利用IIOP调用外部的CORBA 对象 这些 CORBA 对象可以用任何语言编写 运行在 J2EE 之外 J2EE 应用程序可以使用JavaIDL 角色为CORBA services的客户 46
  • 47. JDBC JDBC API 是与数据库连接的 APIJava Message Service (JMS) JMS是支持可靠的点对点( point-to-point ) 与 发布-订阅(publish-subscribe)消息模型 的标准API 47
  • 48. JNDI JNDI API 是命名与目录访问的标准接口,用于定位构件 包含两部分: 应用构件访问命名与目录服务时使用的应用级接口(API) 提供增加命名与目录服务时使用的服务提供接口 (SPI)48
  • 49. JavaMail 许多Internet 应用程序需要发送email的能力 因此J2EE 平台包含 JavaMail API 及JavaMail SPI 使得应用构件能够发送Internet mailJavaBeans Activation Framework (JAF) JavaMail API 所使用的一种功能49
  • 50. Java API for XML Parsing (JAXP) JAXP 为工业标准 SAX 与 DOM 提供支持 以 parsing XML 文档 SAX:The Simple API for XML event-based API DOM:Document Object Model tree-based API 50
  • 51. J2EE Connector Architecture Connector architecture 是将访问EIS(Enterprise Information Systems )的资源适配器插装到任何J2EE产品中的 J2EE SPI Connector architecture 定义了J2EE 服务器与资源适配器之间的系统级合约(Contract) 包括: J2EE与外部资源的连接管理合约 事务管理器与EIS的事务管理合约 访问EIS的安全管理合约51
  • 52. Java Authentication and Authorization Service (JAAS) JAAS 提供用户认证及授权服务 JAAS 提供了 PAM (Pluggable Authentication Module) 框架标准的Java版实现 并扩展了支持基于用户授权的访问控制结构52
  • 53. 目前被广泛接受的体系: OMA DNA J2EE 不同的应用服务器支持不同的体系 尽管存在一些不同: (1)概念不一致 (2)风格不一致 (3)服务不一致 (4)应用领域不一致 但它们在功能、结构上存在较大相似之处三、应用服务器的结构与功能53
  • 54. 应用服务器的纵向位置操作系统应用应用服务器54
  • 55. 应用服务器的横向位置应用服务器数据库服务器因特网浏览器浏览器浏览器应用层系统层显示代码逻辑代码数据55
  • 56. 应用服务器的功能 构件运行环境 应用服务器一般通过构件容器为构件提供基本的运行环境 具体功能包括: 管理构件的生命周期 管理构件的实例 管理构件的元信息等提供构件运行环境 提供互操作机制 提供公共服务 公共服务构件互操作56
  • 57. 互操作机制 这是针对分布性、异构性所提供的功能 所有的应用服务器皆提供了很强的高层通信服务 以屏蔽 节点的物理特性 以及各节点在处理器、操作系统等方面的异构性 具体功能包括: 业务层与表示层之间的通信 业务层与数据层(含遗留系统)之间的通信 业务层内部公共服务与应用层之间的通信 以及业务层内部构件之间的通信 等等 57
  • 58. 公共服务 应用服务器提供的主要公共服务包括: 查找服务 事务服务 安全服务 以及: 消息服务、集群服务、目录服务、日志服务、邮件服务等 对于面向领域的应用服务器 还可以提供更多的与领域业务密切相关的领域公共服务58
  • 59. 应用服务器的结构名空间 管理事务 管理安全 管理数据 访问Web 访问构件管理器负载 管理事件 管理业务逻辑操作系统59
  • 60. 构件容器:公共服务:构件:60
  • 61. 应用服务器解决的问题体系结构 负载均衡 高可靠性 数据库连接池 分布会话管理 嵌入对象 开发方法 高速缓存机制61
  • 62. 体系结构 应用服务器应当具备的首要特性是至少三个层次的服务器端体系结构。所有的应用请求,都将通过请求接收层,一般就是Web服务器,转给应用处理层中的应用服务器处理。应用服务器是独立的进程,对业务进行处理,并进行事务管理,将其中的所有数据操作转给第三层,也就是数据处理层的数据库服务器。在一定的情况下,也可以转给后面的其他系统。应用服务器体系结构的核心在一般的Web服务器和数据库服务器之间,增加专门的应用服务器来完成业务处理,而不是象第二阶段的方法一样,直接从Web服务器访问数据库服务器。 62
  • 63. 负载均衡 使用应用服务器体系结构,增加了一层,使系统的复杂度大大增加,但是这也带来很多的好处。最基本的好处就是给系统带来了可扩展的性能。当用户建立自己最初的系统时,无法精确预计未来的系统规模。如果一开始设计的系统规模很小,那么就无法适应可能出现的未来大规模发展。如果已开始设计的规模很大,那么很有可能会造成投资的浪费。在这种情况下,用户的最佳选择是可以先建立一个小规模的系统,而在系统规模扩大时,可以方便地进行扩充,不需要进行应用的重新开发和调整等高风险性的操作。应用服务器体系结构就可以满足用户的这种要求。所有的应用服务器系统,都具有负载均衡的能力,即将用户发来的请求,恰当地分配给各个应用服务器,使大家可以分别负担系统的负载。通过使用负载均衡,用户在扩大系统时,可以仅仅增加几台新的服务器,安装应用服务器软件,进行恰当的配置即可,无需对应用进行任何修改,这样就满足了可扩展性能的要求。 63
  • 64. 应用服务器实现负载均衡的方法很多,但各有利弊。首先是负载分配算法。当前主要的负载分配算法有两种。一种是精确的负载分配,即系统存在一个分配器,在收到请求时,先询问分配器,找到一个合适的请求,再交给合适的应用服务器进行处理。另一种是基于统计的负载分配,即在收到请求时,根据预先设置的权值,按概率,直接分配给后面的各个应用服务器。精确的算法可以保证不出现某些应用服务器很忙,而有些没事干的情况,但是每个请求需要两次通信才完成,所需的时间较长。基于统计的分配,由于需要预先对各个应用服务器的负载进行估计,很难做到非常准确,所以可能造成分配不均,但是其优点是只需一次通信,处理速度较快。在应用服务器本身的实现上,又有基于进程和基于线程这两种方式。基于进程的方式是指预先生成所有的应用服务器进程,在收到请求时,由某个应用服务器进程来完成所有的处理。而基于线程的方式是指在每台计算机上只建立很少的应用服务器进程,在收到请求时,临时生成一个线程来完成处理。基于进程的方式由于不需要任何创建线程的操作,所以速度较快。但是由于每个进程所占用的资源比每个线程的要多,所以同样一台计算机上可以同时运行的进程数比线程数要少,因此其并行处理能力要弱于基于线程的方式。 64
  • 65. 高可靠性 应用服务器是一种特定形式的分布式系统,而分布式系统最重要的特征之一是建立高可靠性的系统。在应用服务器领域,我们一般说的可靠性是指错误容忍和错误恢复两个特性。错误容忍是指在发生一定的错误,包括硬件错误、软件错误和网络错误的情况下,系统对外仍然可以正常工作。这里所说的一定的错误,对于大多数应用服务器系统,是指至少还有一台应用服务器还在工作。错误容忍有两个等级,一个比较初步的等级是发生错误时正在处理的请求将不能被正确处理,当然用户可以重发请求,此外可能由另一个正常的服务器处理完成。比较完善的等级是将这些处理了一部分的请求转给其他服务器来继续处理,用户端感觉不到任何区别。当然,这个等级提供的服务较好,但是一般是以性能和复杂度为代价的,各个应用可以根据自己的特点,选择某个错误容忍等级。在发现错误和容忍错误的前提下,更加完善的应用服务器还可以进行错误恢复,即错误发生后,如果经过自动或手工的处理,错误被排除了,那么这些应用服务器应当可以恢复工作,继续为用户提供服务。这方面的技术与提供高可用性的技术相关。 65
  • 66. 数据库连接池 众所周知,数据库处理往往是整个业务处理中最耗时的步骤。而在各种数据库操作的步骤中,数据库的连接和释放往往又特别耗时。在应用服务器系统中,一般都采用数据库连接池(Connection Pool)的技术,即在系统初起,或者初次使用时,完成数据库的连接,而后不再释放此连接,而是在处理后面的请求时,反复使用这些已经建立的连接。这种方式可以大大减少数据库的处理时间,有利于提高系统的整体性能,因此被广泛地应用在各种应用服务器产品中。 66
  • 67. 分布会话管理 由于标准的HTTP请求是每个请求一个连接的,为了方便用户使用,系统一般都会利用Cookie、IP地址识别等技术来实现会话管理。例如在用户登录后,记住用户的基本信息等。在单服务器的情况下,会话管理是比较容易实现的,但是在多服务器时,存在会话信息的存放地点问题。当前一般的解决方法有两种。 一种是在每个服务器上保存自己的会话信息,这样,我们进行负载分配时,必须是基于会话的,而不是基于请求的,不然会造成会话信息的不一致。另一种是专门建立一个会话服务器,利用它进行会话信息的保存。这样做可以方便负载分配算法,易于进行错误容忍。但是其缺点是增加一次网络通信的时间,使处理速度减慢。 67
  • 68. 嵌入对象 在应用服务器中,一般都提供嵌入对象,以便完成各种底层的功能,并实现与其他系统的连接。但是各个应用服务器之间在嵌入对象方面的差别很大。主要在对象放置的位置和对象接口上。应用服务器中的嵌入对象,一般可以放置在应用服务器上,也可以放置在应用服务器后端。放在应用服务器上,可以使对象访问成为本地的访问,不需要进行任何网络通信,性能较好,但是这些对象在各个应用服务器上会同时存在,因此,不能实现对象的长期内部状态。放置在应用服务器上时,我们又有两种实现,一种是全对称的,即各个应用服务器上都安装所有的对象,另一种是非对称的,有些对象只安装于某些服务器上,这样做还需要负载分配程序的配合。如果将嵌入对象放在应用服务器后端,实际上就又增加了一个层次,即嵌入对象层,使整个系统变成四层。这样做会增加网络通信,降低性能,但是对象的设计将比较灵活,而且可以使用各种现有的对象连接接口。当前已经成为标准的对象访问接口主要是CORBA和DCOM。CORBA是由OMG(Object Management Group)定义的标准接口,在国外已经被广泛地应用,包括EJB等都使用CORBA标准,而DCOM是Microsoft定义的标准,可以直接连接ActiveX控件。当前也有一些应用服务器有自己独有的对象访问接口。 68
  • 69. 开发方法 应用服务器的开发方法和第二阶段的开发方法类似,一般都是以某种服务器端脚本语言为主要的开发语言。这些语言一般都是将我们经常使用的某种语言,或某些语言的特性,以嵌入页面的方式使用。为了便于开发,有些应用服务器还提供开发版的服务器,以便进行各种调试工作。为了能够最好地方便用户的开发,各个应用服务器一般还提供自己的集成开发环境,将本地编辑、上传、项目管理和调试工具等集中在一起,使开发工作在一个界面内全部完成。还有一些开发环境同时提供后台系统的开发环境,以便同时进行开发管理。此外,还有一些产品内置一些代码的自动生成器,数据库设计辅助工具等,例如ORM(Object Relationship Mapping)等。 69
  • 70. 高速缓存机制 为了达到最佳的性能,许多应用服务器都采用了高速缓存机制。在应用服务器中使用高速缓存一般包括两个地方,即页面的缓存和数据库的缓存。页面的缓存是指将特定的URL对应的页面在缓存中予以记录,以便在未来再次访问同一个URL时,直接使用。这里的缓存可以达到最佳的缓存性能,任何后面的操作都不需要进行了,只需将缓存读出,然后输出即可。但是,由于大多数URL对应的页面中,往往都有少量需要变动的信息,这些页面不能使用这种方法进行缓存。数据库的缓存是指系统对数据库的访问结果进行缓存,这样,相同的SQL再次去访问数据库时,就不需要进行真正的数据库操作,而只需读取缓存即可。这种缓存能够达到良好效果的前提是系统的主要开销在于数据库访问。由于系统依然需要进行有关页面生成等工作,所以缓存效果不如页面缓存,但是适用面比较广。 70
  • 71. J2EE技术J2EE是美国Sun公司推出的一种全新概念的模型,与传统的互联网应用程序模型相比有着不可比拟的优势。当今许多企业都需要扩展他们的业务范围,降低自身经营成本,缩短他们和客户之间 的响应时间,这就需要存在一种简捷,快速的服务于企业,合作伙伴和雇员之间。 典型的说,提供这些服务的应用软件必须同企业信息系统(EIS)相结合,并提供新的能向更为广阔的用户提供的服务。 71
  • 72. 这些服务要具备以下的特点:  a. 高可用性:来满足现在的全球商业环境  b. 安全性:保护用户的隐私和企业数据的安全  c. 可依赖性和可扩展性:保证商业交易的正确和迅捷  72
  • 73. 通常这些服务是由分布的应用程序组成的,包括前端数据端和后端数据源以及它们之间的一层或几层,这些中间层提供了把商业功能和数据与EIS相结合的功能。这些中间层把客户端从复杂的商业逻辑中分离出来,利用成熟的INTERNET技术使用户在管理上所花费的时间最小化。 J2EE正式降低了开发这种中间层服务的成本和复杂程度,因而使得服务可以被快速的展开,并能够更轻松的面对竞争中的压力。 73
  • 74. J2EE通过定义一种标准的结构来实现它的优势,如下:  a. J2EE Application Programming Model ----一种用于开发多层次,瘦型客户用户程  序的标准设计模型  b. J2EE Platform----一个标准的平台,用来整合J2EE的应用程序,指定一系列的  接口和方法  c. J2EE Compatibility Test Suite----一套兼容测试组件,用来检测产品是否同J2EE 平台兼容  d. J2EE Reference Implementation----用来示范J2EE的能力  74
  • 75. J2EE平台的企业应用系统结构 HTTP ClientAppletClient ApplicationApplication ServerWeb ContainerEJB ContainerServletsJSPsSession EJBsEntity EJBsDBMSCORBAJava AppJMS ServerWeb ServiceDirtection Service RMI/IIOP JNDI JTA JDBC JMSJavaMailSOAP75
  • 76. EJB技术 Enterprise JavaBeans(EJB)是J2EE平台下的组件体系结构。EJB规范定义了四种类型的组件对象:stateless session beans, stateful session beans, entity beans, message-driven beans。也为组件开发者提供了需要实现的三种接口:REMOTE接口interface javax.eib.EJBObject extends java.rmi.Remote,HOME接口interface javax.eib.EJBHome extends java.rmi.Remote,BEAN实现接口interface iavax.eib.SessionBean extends javax.ejb.EnterpriseBean和interface iavax.eib.EntityBean extends javax.ejb.EnterpriseBean。 76
  • 77. 完整的EJB组件的开发、部署、和使用过程(以WEBLOGIC为例) (1) 开发人员开发一个或多个EJB组件,要实现Home Interface,Remote Interface,Bean Implementation。这些EJB组件要符合EJB规范。 (2)    编写XML格式的部署描述文件,包括EJB规范规定的部署描述文件和与EJB容器开发商有关的部署描述文件。部署描述文件定义了EJB组件的工作方式,以及容器的行为。 (3)    将完成的EJB文件与部署描述文件打包成一个 .JAR。 (4)     利用开发商提供的容器生成工具生成与容器相关的文件,包括Home Interface,Remote Interface的实现文件以及它们的stubs/skeletons文件。 77
  • 78. (5)       打包好的 .JAR文件需要部署在服务器上。 (6)       生成并激活每个EJB组件对应的Container。 (7)       生成每个EJB组件中Home对象的skeleton, skeleton作为由Home Interface所定义方法的调用的监听者。 (8)       在Container激活后,应用服务器将Home对象的stub绑定在JNDI树上。Home对象的stub是轻量级和可序列化的,可以由远端的客户下载。当执行EJB的撤消部署步骤后,Home对象的stub从JNDI树上被清除。Home对象的stub可以被多个用户并发地下载和使用。 78
  • 79. (9)       客户端与应用服务器的JNDI树相连接,通过JNDI树可以定位所有其上的Home对象的stub。 (10)       客户端下载Home对象的stub的一个拷贝. (11)       客户端调用stub中的由Home Interface所定义的方法,例如create(0,find()。Stub通过RMI通讯机制与服务器端的skeleton相连接,由skeleton转发方法调用至Home对象。 (12)       Home对象创建或加载EJB对象,以及EJB对象的remote skeleton和remote stub,并且从Container instance pool中得到一个EJB Instance与EJB对象相关联。具体的创建或加载由Home对象所属的Container来实现。 (13)       remote stub返回给客户端。 (14)客户端获得了remote stub,就可以调用EJB组件中定义的方法。Stub通过RMI通讯机制与服务器端的skeleton相连接,由skeleton转发方法调用至EJB对象。EJB对象与Container instance pool中的一个EJB Instance相关联。调用的方法在EJB Instance中真正被执行。执行结果沿原路线返回。 79
  • 80. EJB容器/服务器提供的服务 隐含的分布式事务处理管理 事务处理服务通过JAVA事务处理API(JTA)调用来实现,可以使组件在分布式环境中执行健壮的和可确定的操作。 隐含的安全服务 安全性是多层体系结构部署中首要考虑的问题,J2EE提供了强大的安全服务,通过它可以授权和鉴别用户,保证未授权用户不能进行操作。EJB将这种服务称为透明安全机制,保证了组件可以在不需要进行安全API接口编程的同时,获得很好的安全性。 80
  • 81. 隐含的资源管理和组件生存期管理 EJB服务器为组件提供隐含的资源管理服务, 例如线程、Socket和数据库连接。服务器也同样管理着组件自己的生存期,保证在需要的时候,EJB服务器可以重新使用组件。 隐含的持久性服务 持久性服务是任何需要长期数据持久性服务部署的基本要求。EJB服务器自动将持久性对象数据持久性服务到底层的持久性服务介质中,在需要使用时再提取这些数据。 隐含的远程访问能力 EJB产品可以自动的将单独的、不具备网络功能的组件转换为分布式网络组件。 隐含的多用户支持 EJB服务器自动处理用户的并发请求。EJB服务器提供内建的线程支持,在需要的时候将组件实例化多个拷贝,然后将用户请求发给这些实例拷贝。 隐含的透明组件定位服务 通过这种服务,组件的客户端就可以方便地寻找到组件的位置。 81
  • 82. 除了这些隐含服务,EJB服务器还提供很多显示服务。如:命名和目录服务,让组件能够在网络中定位;部署工具,将组件部属到EJB服务器中,并在必要的时候进行定制。 EJB服务器还提供一些超出基本要求,具有实际意义,但不是EJB规范中所规定的服务,如:智能化负载平衡、透明的灾难处理、服务器群集、与现有系统集成的连接器等。 82
  • 83. RMI分布式计算系统要求运行在不同地址空间不同主机上的对象互相调用。各种分布式系统都有自己的调用协议,如CORBA的IIOP(Internet InterORB Protocol), MTS的DCOM。那么EJB组件呢? 83
  • 84. 在Java里提供了完整的sockets通讯接口,但sockets要求客户端和服务端必须进行应用级协议的编码交换数据,采用sockets是非常麻烦的。 一个代替Sockets的协议是RPC(Remote Procedure Call), 它抽象出了通讯接口用于过程调用,使得编程者调用一个远程过程和调用本地过程同样方便。RPC 系统采用XDR来编码远程调用的参数和返回值。 但RPC 并不支持对象,而EJB构造的是完全面向对象的分布式系统,所以,面向对象的远程调用RMI(Remote Method Invocation)成为必然选择。 84
  • 85. 采用RMI,调用远程对象和调用本地对象同样方便。RMI采用JRMP(Java Remote Method Protocol)通讯协议,是构建在TCP/IP协议上的一种远程调用方法。 RMI 采用stubs 和 skeletons 来进行远程对象(remote object)的通讯。stub 充当远程对象的客户端代理,有着和远程对象相同的远程接口,远程对象的调用实际是通过调用该对象的客户端代理对象stub来完成的。 85
  • 86. RMI体系结构客户调用远程对象上的方法Stub远程引用层 TCP远程对象Skeleton远程引用层 TCP86
  • 87. Stub每个远程对象都包含一个代理对象stub,当运行在本地Java虚拟机上的程序调用运行在远程Java虚拟机上的对象方法时,它首先在本地创建该对象的代理对象stub, 然后调用代理对象上匹配的方法,代理对象会作如下工作: 与远程对象所在的虚拟机建立连接 打包(marshal)参数并发送到远程虚拟机 等待执行结果 解包(unmarshal)返回值或返回的错误 返回调用结果给调用程序 stub 对象负责调用参数和返回值的流化(serialization)、打包解包,以及网络层的通讯过程。 87
  • 88. Skeleton每一个远程对象同时也包含一个skeleton对象,skeleton运行在远程对象所在的虚拟机上,接受来自stub对象的调用。当skeleton接收到来自stub对象的调用请求后,skeleton会作如下工作: 解包stub传来的参数 调用远程对象匹配的方法 打包返回值或错误发送给stub对象 远程对象的stub和skeleton对象都是由rmic编译工具产生的。 88
  • 89. RMI-IIOP RMI能够很好解决Java语言中分布式对象的调用问题,但RMI不是一个标准的调用协议,所以RMI不能调用非Java语言编写的对象。 IIOP(Internet Inter-ORB Protocol)是CORBA的通讯协议。CORBA是由OMG(Object Management Group)组织定义的一种分布式组件标准,通过和各种编程语言相匹配的IDL(Interface Definition Language),CORBA可以作到和语言无关,也就是说,用不同编程语言编写的CORBA对象可以互相调用。 JavaIDL定义了Java语言到CORBA之间的匹配,通过JavaIDL,用Java语言编写的应用程序可以和任何CORBA对象通讯。 RMI-IIOP结合了RMI的易用性和CORBA/IIOP的语言无关性,通过RMI-IIOP,RMI对象可以采用IIOP协议和CORBA对象通讯。RMI-IIOP对RMI的调用参数作了一些很轻微的限制,在调用CORBA对象时,必须遵循这些限制。JDK1.3已经提供对RMI-IIOP的支持。89
  • 90. Apusic Application Server对RMI-IIOP的支持 Apusic Application Server目前采用RMI,对RMI-IIOP的支持正在开发中,预计不久即会推出完全支持RMI-IIOP的新版本。90
  • 91. RMI API 规范 java.rmi 包 java.rmi.dgc 包 java.rmi.registry 包 java.rmi.server 包 java.rmi.activation 包 91
  • 92. RMI 工具 rmic - Java RMI Stub 编译器 - (for Windows) (for Solaris) rmiregistry - Java 远程对象注册 - (for Windows) (for Solaris) rmid - Java RMI 激活系统守护进程 - (for Windows) (for Solaris) 92
  • 93. 远程方法调用 (RMI) 有几项新的增强功能。远程对象激活可以支持远程对象的持久引用,并可通过这些引用提供对自动对象激活的支持。自定义套接字工厂允许远程对象指定 RMI(Remote Method Invocation,远程方法调用)对该对象进行远程调用时所用的协议。使用自定义套接字工厂可支持进行安全传送(例如 SSL(Secure Socket Layer,安全套接字层))的 RMI。 次要的 API(Application Programming Interface,应用程序接口)功能增强允许如下操作:不导出远程对象,获得对象实现的 stub 程序, 从 stub 程序获得本地对象实现,以及从指定端口导出对象。 93
  • 94. JMS技术 JMS(Java Message Service )是J2EE平台中消息中间件的规范,它制定了J2EE平台下消息中间件的模型与API。JMS的作用就像是一个智能的交换机,用于路由分布式应用中各应用组件和处理过程中的消息。 94
  • 95. JMS支持两种消息传递模式: Many producers can serialize messages to multiple receivers in a queue. QueueSenderQueueSender Distribution Queue Queue Manager ServerMessages are delivered to a single clientQueueReceiverQueueReceiverQueueReceiver95
  • 96. Publishing and subscribing to a topic decouples producers from consumers Topic PublisherTopic Publisher Topic Topic Manager ServerMessages are delivered to every clientTopic SubscriberTopic SubscriberTopic Subscriber96
  • 97. JMS技术的优点 JMS支持异步的消息传递方式,使消息的发送者与接收者不必保持同步。消息的发送者发送消息属于异步方式,消息发送至JMS服务器后,消息生产者又可以发送另外的消息,不必等到消息接收者接收到消息。消息的接收者接收消息可以使用两种方式:同步消息接收者使用receive()方法,询问JMS是否有新消息给自己。在消息到来之前,receive()方法将一直等待并处于封锁状态。异步消息接收者使用receiver的setMessageListener()方法传递一个实现了javax.jms.MessageListener接口的对象,产生新的线程用于接收消息,MessageListener对象的onMessage()函数负责处理接收到的消息。所以客户端程序并不会封锁而等待消息的到来。 JMS提供消息的可靠性支持,JMS可以持久地存储消息。一旦服务器崩溃不会造成消息丢失,客户机断开和重新连接服务器后不影响原来的工作。 97
  • 98. Message Driven Bean 消息Bean是EJB和JMS的集成产品。消息Bean也存在于EJB容器中,可以利用容器提供事务、安全、并发控制等服务。消息Bean不直接与客户机进行交互,只是一个JMS消息的监听器,客户机把消息发送至JMS目的之后,JMS服务器与EJB容器相互配合,把消息传递至消息Bean。消息Bean没有本地和远程接口,它实现了javax.ejb.MessageDrivenBean和javax.jms.MessageListener接口。 98
  • 99. 四、应用服务器的现状与未来根据开发组织的背景,可以将现有的应用服务器产品进行如下划分: 中间件厂商开发的产品 例如:BEA公司开发的WebLogic IONA公司开发的iPortal ApplicationServer等 数据库厂商开发的产品 例如:Oracle公司开发的 Oracle 9i Application Server等 操作系统厂商开发的产品 例如:IBM公司开发的Websphere SUN开发的SUN ONE Application Server Microsoft公司开发的以MTS为核心的系统 开发工具厂商开发的产品 例如:Inprise公司开发的Borland Application Server等现状:99
  • 100. 其它大量由独立开发组织完成的产品 例如:JBOSS组织开发的Jboss OpenEJB组织开发的OpenEjb Ironflare AB开发的Orion Macromedia开发的JRUN 等等 国内在应用服务器的研究与开发上也取得了显著的进展 国家863计划支持了若干与应用服务器密切相关的项目 北京大学自行开发的PKUAS 在支持在线演化、支持多互操作协议等方面具有明显特色 金蝶公司发布了Apusic 东方通公司发布了TongWeb 等等 100
  • 101. 未来:尽管应用服务器处于不断发展之中 与应用软件相比它仍然是相对稳定的 这是系统软件所具有的一般特性 尽管新技术、新需求令人应接不暇 但几乎所有的系统都需要系统软件的支持 新技术的出现 会对系统软件提出新的需求 并进行适当的扩展、调整 但这些变化不会改变系统软件的基本功能 新技术、新需求的出现不会替代应用服务器 不仅如此,它们的实现通常需要应用服务器的支持101
  • 102. 问 题 为什么需要应用服务器? 应用服务器有哪些诞生基础? 应用服务器具有什么功能? 应用服务器具有什么结构? 102