Java 版 (精华区)

发信人: rhine (有雨无风), 信区: Java
标  题: EJB的编程限制
发信站: 哈工大紫丁香 (2001年03月08日07:57:20 星期四), 站内信件

EJB的编程限制

Enterprise JavaBeans(EJB)是一个开发和部署分布式服务器端的、带事务处理的
、安全的商业组件的规范和结构。EJB的体系结构是J2EE的基础和核心，J2EE定义
了整个标准的应用开发体系结构和一个部署环境。在这个体系结构中，应用开发者
的注意力集中在封装商业逻辑和商业规则上，一切与基础结构服务相关的问题和底
层分配问题都由应用程序容器或服务器来处理。 

     甚至，从属于事务、持久化、安全等等方面的应用组件的运行时属性都可以
使用高度灵活的声明方法在部署的环境中定制。这个体系结构定义了一个容器和一
个服务器模型－－容器是应用组件生存和执行的环境，而这个容器却又寄居在一个
服务器之中。J2EE平台提供了一个简化的开发模型，它具有工业强度的可扩展性、
支持合理的集成和灵活的部署，与开发商和应用服务器无关，这一切使得一些专用
的应用服务器和专用的分布式对象框架变得古旧了。 

    EJB的角色和责任 

    EJB规范定义了几个标准的角色和责任者，如下： 

    1.EJB服务器提供商提供的应用服务器应是一个在分布式事务处理、系统服务
等方面的专家。 

    2.EJB容器提供商提供EJB组件实例运行环境和部署工具。EJB 服务器/容器提
供商是典型的操作系统开发商、数据库开发商或者是应用服务器开发商。EJB的服
务器和EJB的容器应是同一个开发商提供，因为无论是在现在的EJB1.1规范（最终
版）还是EJB2.0公共草稿版（正在修改）中都没有定义两者之间的接口。 

    3.Bean的提供商或者EJB开发者开发的EJB组件都包涵商业逻辑及商业功能。
EJB开发者提供的每一个EJB组件都应满足以下条件：EJB的实现中应包括所有必须
有的组件－容器合同方法（Contract method），如：ejbCreate(),ejbRemove()等
等和一些商业方法（business method）；Home接口；Remote接口；如需要还应有
帮助类。Home接口为创建、删除和查找EJB实例的方法提供签名，Remote接口定义
了商业方法的签名。 

    4.应用程序组装器把一些由Bean提供商开发的EJB组件组装成一个完整的J2EE
应用程序。 

    5.部署器在应用程序部署的目标产品环境中是专家，它在应用服务器中安装应
用组件并配置它们的事务、持久化和安全方面。这样你就可以管理复杂的问题了，
诸如：事务处理、并发处理、持久化以及安全。 

    6.系统管理者负责服务器的配置和管理、运行监控和负载平衡。 

    7.应用程序的用户界面开发者负责用户界面和表示逻辑。 

    这篇文章的焦点集中在Bean提供商/EJB开发者方面和EJB组件实现代码的限制
方面。 

    EJB组件的约束  

    EJB的开发者并不需要在EJB的组件实现代码中编写系统级的服务，EJB提供商
/开发者需知道并且严格地遵守一些限制，这些限制与开发稳定的和可移植的EJB组
件的利益有关。 

    以下是你应该回避使用的一些Java特色，并且在你的EJB组件的实现代码中要
严格限制它们的使用： 

    1.使用static，非final 字段。建议你在EJB组件中把所有的static字段都声
明为final型的。这样可以保证前后一致的运行期语义，使得EJB容器有可以在多个
Java虚拟机之间分发组件实例的灵活性。 

    2.使用线程同步原语来同步多个组件实例的运行。避免这个问题，你就可以使
EJB容器灵活的在多个Java虚拟机之间分发组件实例。 

    3.使用AWT函数完成键盘的输入和显示输出。约束它的原因是服务器方的商业
组件意味着提供商业功能而不包括用户界面和键盘的I/O功能。 

    4.使用文件访问/java.io 操作。EJB商业组件意味着使用资源管理器如JDBC来
存储和检索数据而不是使用文件系统API。同时，部署工具提供了在部署描述器（
descriptor）中存储环境实体，以至于EJB组件可以通过环境命名上下文用一种标
准的方法进行环境实体查询。所以，使用文件系统的需求基本上是被排除了。 

    5.监听和接收socket连接，或者用socket进行多路发送。EJB组件并不意味着
提供网络socket服务器功能，但是，这个体系结构使得EJB组件可以作为socket客
户或是RMI客户并且可以和容器所管理的环境外面的代码进行通讯。 

    6.使用映象API查询EJB组件由于安全规则所不能访问的类。这个约束加强了
Java平台的安全性。 

    7.欲创建或获得一个类的加载器，设置或创建一个新的安全管理器，停止
Java虚拟机，改变输入、输出和出错流。这个约束加强了安全性同时保留了EJB容
器管理运行环境的能力。 

    8.设置socket工厂被URL's ServerSocket,Socket和Stream handler使用。避
免这个特点，可以加强安全性同时保留了EJB容器管理运行环境的能力。 

    9.使用任何方法启动、停止和管理线程。这个约束消除了与EJB容器管理死锁
、线程和并发问题的责任相冲突的可能性。 

    通过限制使用10－16几个特点，你的目标是堵上一个潜在的安全漏洞： 

    10.直接读写文件描述符。 

    11.为一段特定的代码获得安全策略信息。 

    12.加载原始的类库。 

    13.访问Java一般角色所不能访问的包和类。 

    14.在包中定义一个类。 

    15.访问或修改安全配置对象（策略、安全、提供者、签名者和实体）。 

    16.使用Java序列化特点中的细分类和对象替代。 

    17.传递this引用指针作为一个参数或者作为返回值返回this引用指针。你必
须使用SessionContext或EntityContext中的getEJBObject()的结果。 

    Java2平台的安全策略 

    以上所列的特点事实上正是Java编程语言和Java2标准版中的标准的、强有力
的特色。EJB容器允许从J2SE中使用一些或全部的受限制的特色，尽管对于EJB组件
是不可用的，但需通过J2SE的安全机制来使用而不是通过直接使用J2SE的API。 

    Java2平台为EJB1.1规范中的EJB容器所制定的安全策略定义了安全许可集，这
些许可在EJB组件的编程限制中出现。通过这个策略，定义了一些许可诸如：
java.io.FilePermission,java.net.NetPermission,java.io.reflect.
ReflectPermission, 
java.lang.security.SecurityPermission,以便加强先前所列出的编程限制。 

    许多EJB容器没有加强这些限制，他们希望EJB组件开发者能遵守这些编程限制
或者是带有冒险想法违背了这些限制。违背这些限制的EJB组件，比标准方法依赖
过多或过少的安全许可，都将很少能在多个EJB容器间移植。另外，代码中都将隐
藏着一些不确定的、难以预测的问题。所有这些都足以使EJB组件开发者应该知道
这些编程限制，同时也应该认真地遵守它们。 

    任何违背了这些编程限制的EJB组件的实现代码在编译时都不能检查出来，因
为这些特点都是Java语言和J2SE中不可缺少的部分。 

    对于EJB组件的这些限制同样适用于EJB组件所使用的帮助/访问（
helper/access）类，J2EE应用程序使用Java文档（jar）文件格式打包到一个带.
ear（代表Enterprise Archive）扩展名的文件中，这个ear文件对于发送给文件部
署器来说是标准的格式。ear文件中包括在一个或多个ejb－jar文件中的EJB组件，
还可能有ejb－jar所依赖的库文件。所有ear文件中的代码都是经过深思熟虑开发
的应用程序并且都遵守编程限制和访问许可集。 

    未来版本的规范可能会指定通过部署工具来定制安全许可的能力，通过这种方
法指定了一个合法的组件应授予的许可权限，也指定了一个标准方法的需求：如从
文件系统中读文件应有哪些要求。一些EJB容器/服务器目前在它们的部署工具中都
提供了比标准权限或多或少的许可权限，这些并不是EJB1.1规范中所需要的。 

    理解这些约束 

    EJB容器是EJB组件生存和执行的运行期环境，EJB容器为EJB组件实例提供了一
些服务如：事务管理、安全持久化、资源访问、客户端连接。EJB容器也负责EJB组
件实例整个生命期的管理、扩展问题以及并发处理。所以，EJB组件就这样寄居在
一个被管理的执行环境中－－即EJB容器。 

    EJB容器也是EJB组件和外部世界的中间者，它提供了客户连接服务来允许应用
程序客户访问和使用EJB组件所提供的功能，EJB容器通过bean的Remote和Home接口
介入每一个对EJB对象方法的调用。 

    EJB容器也是EJB组件和访问其它各种资源和服务的中间人，因为EJB容器介入
应用组件和J2EE服务，它可以透明地引入组件部署描述符所定义的服务，如：事务
管理、安全、持久化、并发处理和状态管理。 

    资源就是一个封装了访问资源管理器的对象，因为一个资源工厂就是一个用来
建造资源的对象。例如，一个JDBC连接代表一个实现了java.sql.Connection接口
的对象，它是用来提供访问数据库管理系统的资源，并且实现了javax.sql.
DataSource接口的对象是一个这样JDBC连接的资源工厂。同样，定义了许多获得
JMS、JavaMail以及URL连接的资源工厂，目前除此之外没有其它的资源工厂了。 


   （J2EE连接体系结构，目前正在修改，将期盼着包括J2EE未来版本的规范，这
个连接体系结构定义了标准的资源适配器和依附于连接、事务、安全管理的合同，
所以应用服务器将以标准和统一的方式插入各种企业信息系统，包括ERP（如SAP 
R/3），主框架事务处理系统和数据库系统。 

    因为EJB容器完全负责EJB组件的生命期、并发处理、资源访问、安全等等，所
以与容器本身的锁定和并发管理相冲突的可能性就需要消除，许多限制都需要使用
来填上潜在的安全漏洞。除了与EJB容器责任与安全冲突的问题，EJB组件还意味着
仅仅聚焦于商务逻辑，它依赖于EJB容器所提供的服务而不是自己来直接解决底层
的系统层的问题。 

    可能的问题 

    通常，EJB组件在容器之间的移植不可避免地与如下问题相关： 

    1.它需要依靠的受限制的特点在特定EJB容器中没有得到加强。 

    2.它需要依靠的非标准的服务从容器中可获得。 

    为了保证EJB组件的可移植性和一致的行为，你应该使用一个具有与Java2平台
安全策略集相一致的策略集的容器来测试EJB组件，并且其加强了前述的编程限制
。 

    总结 

    EJB组件开发者应该知道这些推荐的关于EJB组件的编程限制，明白它们的重要
性，并且从组件的稳定性和可移植性利益方面考虑来遵循它们。因为这些编程限制
能阻止你使用标准的Java语言的特点，违背了这些编程限制在编译时不会知道，并
且加强这些限制也不是EJB容器的责任。所有这些原因都使你应很小心地遵守这些
编程限制，这些限制在组件的合同中已经成为了一个条款，并且它们对于建造可靠
的、可移植的组件是非常重要的。
 

 

--
           海纳百川，
                   有容乃大，
                           壁立千尺，
                                   无欲则刚。    

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: dip.hit.edu.cn]