Java2平台的安全策略
以上所列的特点事实上正是Java编程语言和Java2标准版中的标准的、强有力的特色。EJB容器允许从J2SE中使用一些或全部的受限制的特色，尽管对于EJB组件是不可用的，但需通过J2SE的安全机制来使用而不是通过直接使用J2SE的API。
Java2平台为EJB1.1规范中的EJB容器所制定的安全策略定义了安全许可集，这些许可在EJB组件的编程限制中出现。通过这个策略，定义了一些许可诸如：java.io.FilePermission，java.net. NetPermission，java.io.reflect.ReflectPermissionjava. 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容器的责任。
所有这些原因都使你应很小心地遵守这些编程限制，这些限制在组件的合同中已经成为了一个条款，并且它们对于建造可靠的、可移植的组件是非常重要的。
