logo资料库

JavaEE 6 规范中文版.pdf

第1页 / 共122页
第2页 / 共122页
第3页 / 共122页
第4页 / 共122页
第5页 / 共122页
第6页 / 共122页
第7页 / 共122页
第8页 / 共122页
资料共122页,剩余部分请下载后查看
Java EE 6 规范 第 1 章 引 言 今天的企业需要扩大自己的影响, 缩减自己的成本, 并且提高自己与客户,雇员,供货商之间沟通的效率。 通常, 提供这类服务的应用程序必须结合现存的企业信息系统(EIS),具备新的业务功能为更广泛的用户群提 供服务。这些服务要求具有: •高可用性, 以满足今天商业全球化的需求 •安全性, 以保护用户的隐私和维护企业的安全 •可靠性和可伸缩性, 以确保业务被准确及时地处理 大多数情况下,企业服务由多层应用程序实现。中间层整合了现存的 EIS,具备新服务的业务功能和数据。 成熟的 Web 技术用来提供用户层服务,简化业务访问的复杂性,并且消除或大大减少对用户的管理和培训。 JavaTM 平台企业版(JavaTM EE) 降低了开发多层次企业级服务的成本和复杂性。Java EE 应用程序可以快速 地部署和强化,使企业轻松地应对竞争压力。 Java EE 方案可以实现上述目标,这需要定义一个标准的架构,以下是其组成元素: •Java EE 平台 - 一个托管 Java EE 应用程序的标准平台。 •Java EE 兼容性测试套件 - 兼容性测试套件用于检验 Java EE 平台产品是否符合 Java EE 平台标准。 •Java EE 可参考的实现- 一个可参考的实现是一个 Java EE 应用程序原型,提供一套可行的 Java EE 平台定义。 •Java EE 蓝图 - 一套开发多层次瘦客户端服务的最佳实践。 本文档描述了 Java EE 平台规范。它定义了一个 Java EE 平台产品必须达到的标准。 1.1 感谢 本规范是多人协作的成果。Vlada Matena 撰写了第一个草案以及事务管理和命名的章节。 Sekhar Vajjhala, Kevin Osborn,和 Ron Monzillo 撰写了安全的章节。Hans Hrasna 撰写了应用程序组装和部署的章节。 Seth White 撰写了 JDBC API 标准。Jim Inscore, Eric Jendrock,和 Beth Stearns 提供了编辑上的帮助。Shel Finkelstein, Mark Hapner, Danny Coward, Tom Kincaid,和 Tony Ng 对多次草案提供了反馈。当然,本规范的 形成和确立来自同我们行业伙伴的会谈和反馈。 1.2 版本 1.3 的感谢 本规范 1.3 版的成长离不开与 1.2 版合作伙伴的探讨,以及那些随后在 1.2 最终发布版中加入的合作伙伴。 版本 1.3 在 Java Community Process(JCP)下创建,标号为 JSR-058。JSR-058 专家组中的代表来自下面的公司 和组织: Allaire, BEA Systems, Bluestone Software, Borland, Bull S.A., Exoffice, Fujitsu Limited, GemStone Systems, Inc., IBM, Inline Software, IONA Technologies, iPlanet, jGuru.com, Orion Application Server, Persistence, POET Software, SilverStream, Sun, and Sybase。另外,很多帮助过先前版本的朋友继续在为当 前版本提供帮助,比如 Jon Ellis 和 Ram Jeyaraman。Alfred Towell 为这个版本提供了编辑上重要支持。 1.3 版本 1.4 的感谢
本规范 1.4 版创建在 Java Community Process(JCP)下,标号为 JSR-151。JSR-151 专家组包含了下面的 成员: Larry W. Allen (SilverStream Software), Karl Avedal (Individual), Charlton Barreto (Borland Software Corporation), Edward Cobb (BEA), Alan Davies (SeeBeyond Technology Corporation), Sreeram Duvvuru (iPlanet), B.J. Fesq (Individual), Mark Field (Macromedia), Mark Hapner (Sun Microsystems, Inc.), Pierce Hickey (IONA), Hemant Khandelwal (Pramati Technologies), Jim Knutson (IBM), Elika S. Kohen (Individual), Ramesh Loganathan (Pramati Technologies), Jasen Minton (Oracle Corporation), Jeff Mischkinsky (Oracle Corporation), Richard Monson-Haefel (Individual), Sean Neville (Macromedia), Bill Shannon (Sun Microsystems, Inc.), Simon Tuffs (Lutris Technologies), Jeffrey Wang (Persistence Software, Inc.)和 Ingo Zenz (SAP AG)。我在 Sun 公司的同事提供了宝贵的援助: Umit Yalcinalp 将部署描述符 转向了 XML Schema; Tony Ng 和 Sanjeev Krishnan 为事务标准提供了帮助; Jonathan Bruce 为 JDBC 标准提 供了帮助; Suzette Pelouch, Eric Jendrock 和 Ian Evans 提供了编辑上的支持。也感谢所有外部的评论,包括 Jeff Estefan (Adecco Technical Services)。 1.4 版本 5 的感谢 本规范的版本 5 创建在 (原来被称为版本 1.5) Java Commuinity Process(JCP)下,标号为 JSR-244。JSR- 244 专家组包含了下面的成员: Kilinc Alkan (Individual), Rama Murthy Amar Pratap (Individual), Charlton Barreto (Individual), Michael Bechauf (SAP AG), Florent Benoit (INRIA), Bill Burke (JBoss, Inc.), Muralidharan Chandrasekaran (Individual), Yongmin Chen (Novell, Inc.), Jun Ho Cho (TmaxSoft), Ed Cobb (BEA), Ugo Corda (SeeBeyond Technology Corporation), Scott Crawford (Individual), Arulazi Dhesiaseelan (Hewlett-Packard Company), Bill Dudney (Individual), Francois Exertier (INRIA), Jeff Genender (The Apache Software Foundation), Evan Ireland (Sybase, Inc.), Vishy Kasar (Borland Software Corporation), Michael Keith (Orcale Corporation), Wonseok Kim (TmaxSoft, Inc.), Jim Knutson (IBM), Elika Kohen (Individual), Felipe Leme (Individual), Geir Magnusson Jr. (The Apache Software Foundation), Scott Marlow (Novell, Inc.), Jasen Minton (Oracle Corporation), Jishnu Mitra (Borland Software Corp), David Morandi (E.piphany), Nathan Pahucki (Novell, Inc.), David Morandi (E.piphany, Inc.), Ricardo Morin (Intel Corporation), Nathan Pahucki (Novell, Inc.), Matt Raible (Individual), Dirk Reinshagen (Individual), Narinder Sahota (Cap Gemini), Suneet Shah (Individual), Bill Shannon (Sun Microsystems, Inc.), Rajiv Shivane (Pramati Technologies), Scott Stark (Jboss, Inc), Hani Suleiman (Ironflare AB), Kresten Krab Thorup (Trifork), Ashish Kumar Tiwari (Individual), Sivasundaram Umapathy (Individual), Steve Weston (Cap Gemini), Seth White (BEA Systems)和 Umit Yalcinalp (SAP AG)。再次, 我 在 Sun 公司的同事提供了宝贵的援助: Roberto Chinnici 为依赖注入的很多相关问题提供了对草案的建议。 1.5 版本 6 的感谢 本规范的版本 6 创建在 Java Commuinity Process(JCP)下,标号为 JSR-316。引领此规范 JSR-316 专家组 的是 Bill Shannon (Sun Microsystems, Inc.)和 Roberto Chinnici (Sun Microsystems, Inc.)。此专家组包含了 下面的成员: Florent Benoit (Inria), Adam Bien (Individual), David Blevins (Individual), Bill Burke (Red Hat Middleware LLC), Larry Cable (BEA Systems), Bongjae Chang (Tmax Soft, Inc.), Rejeev Divakaran (Individual), Francois Exertier (Inria), Jeff Genender (Individual), Antonio Goncalves (Individual), Jason Greene (Red Hat Middleware LLC), Gang Huang (Peking University), Rod Johnson (SpringSource), Werner Keil (Individual), Michael Keith (Oracle), Wonseok Kim (Tmax Soft, Inc.), Jim Knutson (IBM), Elika S. Kohen (Individual), Peter Kristiansson (Ericsson AB), Changshin Lee (NCsoft Corporation), Felipe Leme (Individual), Ming Li (TongTech Ltd.), Vladimir Pavlov (SAP AG), Dhanji R. Prasanna (Google), Reza Rahman (Individual), Rajiv Shivane (Pramati Technologies), Hani Suleiman (Individual)。
第二章 平台概述 本章是 JavaTM 平台企业版(Java EETM)的概述。 2.1 体系结构 图 2-1 展示了 Java EE 平台体系结构中各元素间的既定关系。注意,此图展示的是元素间的逻辑关系,它并 不代表这些元素在物理上的划分方式(不同的机器,进程,地址空间或虚拟机)。 每个独立矩形上半部分标明的容器是 Java EE 运行时环境,它为应用程序组件提供了必要的服务。这些服务 基于矩形下半部分所列出的技术。例如, “Application Client Container”(应用程序客户端容器) 为应用程序客 户端提供了链接 JMS 的接口,其它服务也是如此。所有这些服务会在后续章节详细描述。 这些箭头表示,必须提供对 Java EE 平台对应部分的访问。应用程序客户端容器为应用程序客户端提供了直 接访问数据库的环境。这是通过连接数据库系统的 Java API(JDBCTM API)来实现。类似地,Web 容器为 JSP 页 面和 Servlet,EJB 容器为企业 Bean 也提供了对数据库的访问. 正如图中所示,JavaTM 平台标准版(Java SE)API 由 Java SE 运行时环境提供,各种类型应用程序组件都基 于这些 API。 图 2-1 Java EE 体系结构图 下面的章节描述了每种 Java EE 平台元素的标准。 2.2 Profile(自定义规范) Java EE 6 规范提出了”Profile (自定义规范)”的概念。 Profile 描绘了 Java EE 平台针对应用程序特定类的配置。 Profiles 不是一个新的概念,也不是 Java EE platform 特有的。“Java Community Process Document 2.6)”(Java 社区进程文档 2.6)对 Profile 给出了如下定义: “一种规范,它参考了某个平台版本的规范,并附加零 个或多个其它的 JCP 规范(它们尚未成为平台版本规范的组成部分)。它必须包含来自参考平台的 API,但必须符 合那个平台定义的引用规则。其它引进的规范必须在完全符合规则的前提下被引进。”
所有 Java EE Profile 共享一套公共特征,例如命名和资源注入,打包规则,安全标准等等。这就保证了 “Java EE 平台”旗下的所有产品的一致性。这也确保了熟悉某一 Profile 或整个平台的开发者可以很容易地适应 其它的 Profile,避免了技能和经验上的过度差异。 相对于上面概括的基本功能,Profile 可以自由包含这个平台的任何技术,它的平台规范中提供了适用于这 些技术的所有规则,可以单独使用也可以组合使用。 最后要强调的是,如果 Profile 只包含逐点技术,它们将比哪些有很少或没有接入点的 API 包多一点。作为 代替,这里采用的 Profile 的定义应保证,每当本规范定义了技术组合的标准,这些标准会在所有基于 Java EE Profile 的产品中兑现。 举一个具体的例子, 让我们思考一下在 Servlet 容器中事务的使用。在孤立状态下,Servlet 规范和 JTA 规范 都没有为可移植的应用程序定义一个完整的编程模型。通过开拓自己的一套标准来结合 Servlet 和 JTA,这种规 范就可以弥补这一缺陷。所有基于此 Profile 并包含了这两种技术的 Java EE 产品都必须满足这些条件, 这就给应 用程序开发者提供了一个更完整的编程模型,并为所有相关的 Java EE Profile 共享。 一个独立的规范--Java EE 6 Web Profile 规范,定义了 Java EE Web Profile,它是 Java EE 6 平台的第一 项 Profile。 可以依据 JCP 制定的规则和当前规范包含的规则来定义附加的 Profile。特别是,一项 Profile 的确立必须提 交一项 Java Specification Request(JSR),并在完成时公布自己的计划,它应无视平台自身或其它 Profile 在此 时发生的任何修订。这确保了在定义和发布一项新的 Profile 或更新已有版本时拥有最大灵活性。 根据上面给出的 Profile 定义,一项 Profile 最终可以成为这个平台适当的子集或者超集,也可以与它在某一 范围上部分重叠。这种灵活性保证了未来的 Profile 所覆盖的功能将远远超过这个平台规范最初的设想。 正如前面的段落所描述的,建立新的 Profile 是一项意义深远的任务。决定创建一项 Profile 时应该重视它潜 在的不利因素,尤其是条件的分裂和开发者的困惑。一般而言,要建立一项 Profile,需要开发者自然地支持,并 且充分衡量应用程序能否从中获益。也推荐 Profile 在它自己的兴趣范围中扩展功能,尽量避免相互重叠或竞争 的 Profile 出现。Profile 可以使用 Java EE 6 的平台特征,诸如可选的组件,可扩展性和修剪流程,以更好地实 现他们预定的目标。 2.3 应用程序组件 Java EE 运行时环境定义了 Java EE 产品必须支持的 4 种应用程序组件类型: 应用程序客户端是 Java 编程语言程序,它通常是执行在个人电脑上的图形用户界面(GUI)程序。应用程序客 户端提供一种类似于本地应用程序的用户体验,并且能够访问 Java EE 中间层的所有功能。 Applet 是运行在 Web 浏览器中的一种特殊的 GUI 组件,但它也可以运行在其它的支持 Applet 编程模式的 应用程序或设备上。Applet 可以用来为 Java EE 应用程序提供强有力的用户界面(简易的 HTML 页面也能用来为 Java EE 应用程序提供有限的用户界面) Servlet, JSP 页面, JSF 应用程序, 过滤器和 Web 事件监听器通常运行在 Web 容器中,并且可以响应来自 Web 客户端的 HTTP 请求。Servlets, JSP 页面, JSF 应用程序以及过滤器可以用来生成 HTML 页面,作为应用程 序的用户界面。也可以用它们生成供其它应用程序组件使用的 XML 或其它格式的数据。一种特殊的 Servlet 使用 SOAP/HTTP 协议为 Web 服务提供支持。Servlet, 由 JSP 技术或 JSF 技术生成的页面,Web 过滤器和 Web 事件 监听器在本规范中统称为“Web 组件”。Web 应用程序由 Web 组件和其它数据(如 HTML 页面)组成。Web 组 件运行在 Web 容器中。Web 服务器包含一个 Web 容器以及协议,安全等其它方面的支持,符合 Java EE 规范的 要求。
Enterprise JavaBeans(EJB)组件运行在一个支持事务的环境中接受管理。企业 Bean 通常包含 Java EE 应用 程序的业务逻辑。企业 Bean 可以使用 SOAP/HTTP 协议直接提供 Web 服务。 2.3.1 Java EE 服务器为应用程序组件提供支持 Java EE 服务器为符合标准的应用程序组件提供部署,管理和运行的支持。根据它们所以依赖的 Java EE 服 务器,应用程序组件可以分成 3 类: •部署,管理和运行在 Java EE 服务器上的组件。这类组件包括 Web 组件和 EJB 组件。请查看这些 组件各自的规范。 •部署和管理在 Java EE 服务器上,但是被加载到客户机上运行的组件。这类组件包括诸如 HTML 页面和嵌入 THML 页面的 Applet 这样 Web 的资源。 •部署和管理没有完全定义在本规范中的组件。应用程序客户端就属于这种类型。本规范的未来版 本可能会更完整地定义应用程序客户端的部署和管理。请查看 EE.10, “应用程序客户端”中对应用程序 客户端的描述。 2.4 容器 容器为 Java EE 应用程序组件提供了运行时支持。容器提供了一份从底层 Java EE API 到应用程序组件的联 合视图。Java EE 应用程序组件不能直接地与其它 Java EE 应用程序组件交互。它们通过容器的协议和方法来达成 它们之间以及它们与平台服务之间的交互。在应用程序组件和 Java EE 服务之间插入一个容器,这允许该容器透 明地为组件注入必须的服务,例如声明式事务管理,安全检查,资源池和状态管理。 一个标准的 Java EE 产品会为每个应用程序组件类型提供一个容器: 应用程序客户端容器,Applet 容器, Web 组件容器, 企业 Bean 容器。 2.4.1 容器的标准 本规范要求容器提供一个由 JavaTM 平台标准版规范 v6 (Java SE)定义的 JavaTM 兼容性运行时环境。 Applet 容器可以使用 Java 插件产品来提供这个环境,或者是使用本地环境。提供 JDKTM 1.1 API 的 Applet 容器 超出了本规范的范围。 容器工具必须识别部署应用程序组件的打包文件格式。 容器由 Java EE 产品供应商提供。请查看 2.11.1,“Java EE 产品供应商”中对产品供应商角色的描述。 本规范定义了一套标准服务,每个 Java EE 产品必须提供支持。后面会对这些标准服务进行描述。Java EE 容器提供了访问这些服务的 API,供应用程序组件使用。本规范也描述了用连接器扩展 Java EE 服务的标准方法, 以结合其它的非 Java EE 应用程序系统,例如大型机系统和 ERP 系统。 2.4.2 Java EE 服务器 Java EE 容器是底层服务器的组成部分。Java EE 产品供应商通常使用现有的事务处理框架结合 Java SE 技 术来实现 Java EE 服务器端功能。Java EE 客户端功能通常构建于 Java SE 技术。 2.5 资源适配器 资源适配器是一个系统级的组件,它通常实现了对外部资源管理器的网络连接。资源适配器能够扩展 Java EE 平台的功能。这只需要实现一个 Java EE 标准服务 API(例如 JDBCTM 驱动程序),或者定义并实现一个能连接 到外部应用程序系统的资源适配器就可以达到。资源适配器也可以提供完整的本地或本地资源的服务。资源适配 器接口通过 Java EE 服务供应商接口(Java EE SPI)来连接 Java EE 平台。使用 Java EE SPI 连接到 Java EE 平台的 资源适配器可以和所有的 Java EE 产品协同工作。
2.6 数据库 Java EE 平台需要数据库来存储业务数据,通过 JDBC API 进行访问。可以从 Web 组件,企业 Bean 和应用 程序客户端组件连接到数据库。不需要从 Applet 连接到数据库。 2.7 Java EE 标准服务 Java EE 标准服务包括下述服务(后面的章节会进行更详细地描述)。一些标准服务实际上由 Java SE 提供。 2.7.1 HTTP HTTP 客户端 API 定义在 java.net 包中。HTTP 服务器端 API 由 Servlet, JSP 和 JSF 接口定义,以及被那些 是 Java EE 平台组成部分的 Web 服务支持。 2.7.2 HTTPS 支持 HTTP 协议的客户端和服务器端 API 也同样支持带 SSL 协议的 HTTP 协议。 2.7.3 JavaTM Transaction API (JTA) Java 事务 API 由两部分组成: •一个应用程序级的边界划分接口,容器和应用程序组件用它来划分事务边界。 •一个介于事务管理器和资源管理器之间的 Java EE SPI 级接口。 2.7.4 RMI-IIOP RMI-IIOP 由 API 组成,这些 API 允许使用不依赖于底层协议的 RMI 风格编程。作为那些 API 的实现,它同 时支持 Java SE 本地 RMI 协议和 CORBA IIOP 协议。通过支持 IIOP 协议,Java EE 应用程序就可以使用 RMI- IIOP 来访问 CORBA 服务,并且该应用程序兼容 RMI 编程约束(请查看 RMI-IIOP 的详细说明)。这样的 CORBA 服务通常由 Java EE 产品之外的组件定义,一般存在于以前遗留下来的系统中。只要求 Java EE 应用程序客户端 可以使用 RMI-IIOP API 来直接定义它们自己的 CORBA 服务。通常这样的 CORBA 对象用于在访问其它的 CORBA 对象时进行回调。 当访问 EJB 组件时,Java EE 应用程序必须使用 RMI-IIOP API,特别是 javax.rmi.PortableRemoteObject 类的 narrow 方法,正如 EJB 规范所描述的。这些企业 Bean 可以独立于协议。需要注意的是,当使用依赖注入 代替 JNDI 就行查找时,通常不需要使用 narrow 方法; 在注入对象引用之前,容器会为应用程序执行 narrow 方 法。Java EE 产品必须能够使用 IIOP 协议输出和访问企业 Bean,这在 EJB 规范中被明确规定。对 IIOP 协议的支 持使 Java EE 产品之间的交互成为可能,不过,Java EE 产品也可以使用其它的协议。 2.7.5 Java IDL 通过使用 IIOP 协议,Java IDL 允许 Java EE 应用程序组件调用外部的 CORBA 对象。这些 CORBA 对象可 以用任何语言编写,并且通常存在于 Java EE 产品外部。Java EE 应用程序可以使用 Java IDL 来担当 CORBA 服 务的客户端,但是只有 Java EE 应用程序客户端可以直接使用 Java IDL 提供 CORBA 服务。 2.7.6 JDBCTM API JDBC API 是用来连接关系数据库系统的 API。JDBC API 有两个部分: 一个是应用程序组件用来访问数据库 的应用级接口,另一个是 JDBC 驱动接口。不要求 Java EE 产品对 JDBC 驱动接口提供支持。JDBC 驱动应该被打 包成一个资源适配器,通过使用连接器 API 的能力来连接 Java EE 产品。JDBC API 包含在了 Java SE 中, 但是本 规范包含了对 JDBC 设备驱动的额外标准。 2.7.7 JavaTM Persistence API(JPA)
Java 持久化 API 是用于持久化和对象/关系映射管理的标准 API。通过使用一个 Java 域模型来管理关系型数 据库,本规范为应用程序开发者提供了一种对象/关系映射功能。Java EE 必须对 Java 持久化 API 提供支持。它也 可以用在 Java SE 环境中。 2.7.8 JavaTM Message Service (JMS) Java 消息服务是用于消息发送的标准 API,它支持可靠的“点对点”消息发送和“发布-订阅”模型。本规 范要求 JMS 供应商同时实现“点对点”消息发送和”发布/订阅”型消息发送。 2.7.9 Java Naming and Directory InterfaceTM (JNDI) JNDI API 是用于命名和目录访问的标准 API。它有两个部分: 一个是应用程序组件用来访问命名和目录服务 的应用程序级接口,另一个是用于连接命名和目录服务供应商的服务供应商接口。JNDI API 包含在 Java SE 中, 但是本规范为它定义了额外的标准。 2.7.10 JavaMailTM 许多互联网应用程序需要发送邮件的功能,因此 Java EE 平台包含了 JavaMail API 以及相应的 JavaMail 服 务供应商 API,使应用程序组件可以发送互联网邮件。JavaMail API 有两个部分: 一个是应用程序组件用于发送 邮件的应用程序级接口,另一个是 Java EE SPI 级的服务供应商接口。 2.7.11 JavaBeansTM Activation Framework (JAF) JAF API 提供了一个框架来处理不同 MIME 类型的数据,它们源于不同的格式和位置。JavaMail API 使用 了 JAF API。JAF API 包含在 Java SE 中,因此它可以被 Java EE 应用程序使用。 2.7.12 XML 处理 JavaTM API for XML Processing (JAXP)支持工业标准化的 SAX 和 DOM API,用以解析 XML 文档,也支 持 XSLT 转换引擎。 Streaming API for XML (StAX)为 XML 提供了一种“拉式解析”型的 API。JAXP 和 StAX API 都包含在 Java SE 中,因此它们可以被 Java EE 应用程序使用。 2.7.13 Java EETM 连接器体系结构 连接器体系结构是一种 Java EE SPI,它允许将资源适配器插入到任何 Java EE 产品中,这个资源适配器支 持对 EIS 的访问。连接器体系结构定义了一套标准的介于 Java EE 服务器和资源适配器之间的系统级协议。这些 协议包括: •连接管理协议,它让 Java EE 服务器将“连接”集中到底层 EIS 中,然后让应用程序组件与 EIS 连 接。这种方式营造出了一种可伸缩的应用程序环境,它能支持大规模客户端对 EIS 系统的访问。 •事务管理器和 EIS 之间的事务管理协议,它支持对 EIS 资源管理器的事务型访问。这个协议让 Java EE 服务器使用事务管理器来管理跨多个资源管理器的事务。这个协议也支持 EIS 资源管理器内部管理的 事务,而不需要牵连外部的事务管理器。 •安全协议,它实现了对 EIS 的安全访问。这个协议为安全的应用程序环境提供支持,它减少了对 EIS 的安全威胁并保护了 EIS 管理的重要信息资源。 •线程管理协议,它允许资源适配器将工作委托给其它的线程,并允许应用程序服务器管理线程池。 通过工作线程,资源适配器可以控制安全上下文和事务上下文。 •消息传递协议,它允许资源适配器将消息传递到消息驱动 Bean,此 Bean 不依赖于特定的消息格 式,消息语义和传递消息的底层结构。这个协议也充当标准消息提供方即插即用协议,它允许通过资源 适配器将消息提供方插入到任何 Java EE 服务器中。
•事务传递协议,它允许资源适配器将一个被导入的事务上下文传递给 Java EE 服务器,使得服务器 和任意应用程序组件的交互成为被导入的事务的组成部分。这个协议维护了被导入事务的 ACID(atomicity, consistency, isolation, durability)属性。 •可选协议,它提供了一个介于应用程序和资源适配器之间的通用命令接口。 2.7.14 安全服务 JavaTM Authentication and Authorization Service (JAAS)使服务能够基于用户进行验证和实施访问控制。 它实现了一个 Java 版的标准的的 Plugable Authentication Module (PAM)框架,并支持基于用户的授权。 JavaTM Authorization Service Provider Contract for Containers (JACC) 定义了 Java EE 应用程序服务器和授 权服务提供方之间的协议,允许将自定义的授权服务提供方插入任何 Java EE 产品中。 2.7.15 Web 服务 Java EE 为 Web 服务的客户端和终端提供了完整的支持。一些 Java 技术协同为 Web 服务提供支持。通过 使用 SOAP/HTTP 协议,Java API for XML Web Services (JAX-WS)和 Java API for XML-based RPC (JAX- RPC)都能为 Web 服务的调用提供了支持。新的 JAX-WS 是支持 Web 服务的首选 API,它出现在 JAX-RPC 之后。 JAX-WS 提供了更广泛的 Web 服务功能,并提供对多重“绑定-协议”的支持。当使用绑定于 HTTP 协议的 SOAP1.1 协议时,JAX-WS 和 JAX-RPC 完全可以协同工作,但要受到 WS-I 基本概要规范的约束。 JAX-WS 和 Java Architecture for XML Binding (JAXB)定义了 Java 类和用于 SOAP 调用的 XML 之间的映 射,并且对 XML Schema 提供了 100%的支持。SOAP with Attachments API for Java (SAAJ) 对操作低层 SOAP 消息提供支持。Java EE 规范中的 Web 服务标准完整地定义了 Web 服务的客户端和终端在 Java EE 中的 部署,以及使用企业 Bean 的 Web 服务终端的实现。Web 服务元数据规范定义了相应的 Java 语言注解来简化 Web 服务的开发。Java API for XML Registries (JAXR) 使客户端可以访问 XML 注册服务器。 Java API for RESTful Web Services (JAX-RS)对使用 REST 风格的 Web 服务提供了支持。RESTful Web 服务更符合 Web 的设计风格,并且常常更易于使用多种编程语言对其进行访问。JAX-RS 提供了一个简单的高层 API 来写入这样的 Web 服务,以及一个低层 API 来控制 Web 服务交互中的所有细节。 2.7.16 管理 Java 2 平台企业版管理规范中定义了一种 API,通过一种特殊的管理型企业 Bean 来管理 Java EE 服务器。 JavaTM Management Extensions (JMX) API 也提供了一些管理上的支持。 2.7.17 部署 Java 2 平台企业版部署规范中定义了部署工具和 Java EE 产品之间的协议。Java EE 产品提供了运行在部署 工具上的插入式组件,它允许部署工具将应用程序部署到 Java EE 产品中。 部署工具提供了插入式组件可以使用的服务。
分享到:
收藏