S
snjat
Unregistered / Unconfirmed
GUEST, unregistred user!
EJB
1. 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组件还意味着仅仅聚焦于商务逻辑，它依赖于EJB容器所提供的服务而不是自己来直接解决底层的系统层的问题。
可能的问题
通常，EJB组件在容器之间的移植不可避免地与如下问题相关：
1.它需要依靠的受限制的特点在特定EJB容器中没有得到加强。
2.它需要依靠的非标准的服务从容器中可获得。
为了保证EJB组件的可移植性和一致的行为，你应该使用一个具有与Java2平台安全
策略集相一致的策略集的容器来测试EJB组件，并且其加强了前述的编程限制。
总结
EJB组件开发者应该知道这些推荐的关于EJB组件的编程限制，明白它们的重要性，并且从组件的稳定性和可移植性利益方面考虑来遵循它们。因为这些编程限制能阻止你使用标准的Java语言的特点，违背了这些编程限制在编译时不会知道，并且加强这些限制也不是EJB容器的责任。所有这些原因都使你应很小心地遵守这些编程限制，这些限制在组件的合同中已经成为了一个条款，并且它们对于建造可靠的、可移植的组件是非常重要的。
2. 优化EJB
entity bean为在应用程序和设计中描述持久化商业对象（persistent business objec ts）提供了一个清晰的模型。在java对象模型中，简单对象通常都是以一种简单的方式进行处理但是，很多商业对象所需要的事务化的持久性管理没有得到实现。entity bean将持久化机制封装在容器提供的服务里，并且隐藏了所有的复杂性。entity bean允许应用程序操纵他们就像处理一个一般的java对象应用。除了从调用代码中隐藏持久化的形式和机制外，entity bean还允许EJB容器对对象的持久化进行优化，保证数据存储具有开放性，灵活性，以及可部署性。在一些基于EJB技术的项目中，广泛的使用OO技术导致了对entity bean的大量使用，SUN的工程师们已经积累了很多使用entity Bean的经验，这篇文章就详细阐述的这些卡发经验：
*探索各种优化方法
*提供性能优化和提高适用性的法则和建议
*讨论如何避免一些教训。
法则1：只要可以，尽量使用CMP
CMP方式不仅减少了编码的工作量，而且在Container中以及container产生的数据库访问代码中包括了许多优化的可能。Container可以访问内存缓冲中的bean,这就允许它可以监视缓冲中的任何变化。这样的话就在事物没有提交之前，如果缓存的数据没有变化就不用写到数据库中。就可以避免许多不必要的数据库写操作。另外一个优化是在调用find方法的时候。通常情况下find方法需要进行以下数据库操作：
查找数据库中的纪录并且获得主键
将纪录数据装入缓存
CMP允许将这两步操作优化为一步就可以搞定。[具体怎么做我也没弄明白，原文没有具体阐述]
法则2：写代码时尽量保证对BMP和CMP都支持
许多情况下，EJB的开发者可能无法控制他们写的bean怎么样被部署，以及使用的container是不是支持CMP.
一个有效的解决方案是，将商业逻辑的编码完全和持久化机制分离。再CMP类中实现商业逻辑，然后再编写一个BMP类，用该类继承CMP类。这样的话，所有的商业逻辑都在CMP类中，而持久化机制在BMP中实现。[我觉得这种情况在实际工作中很少遇到，但是作者解决问题的思路值得学习]
法则3：把ejbStore中的数据库访问减小到最少。
如果使用BMP,设置一个缓存数据改变标志dirty非常有用。所有改变数据库中底层数据的操作，都要设置dirty,而在ejbStore（）中，首先检测dirty的值，如果dirty的值没有改变，表明目前数据库中的数据与缓存的一致，就不必进行数据库操作了，反之，就要把缓存数据写入数据库。
法则4：总是将从lookup和find中获得的引用进行缓存。（cache）
引用缓存对session bean和entity bean 都是适用的。
通过JNDI lookup获得EJB资源。比如DataSource,bean的引用等等都要付出相当大的代价。因此应该避免多余的lookup.可以这样做：
将这些引用定义为实例变量。
从setEntityContext(session Bean使用setSessionContext)方法查找他们。SetEntityContext方法对于一个bean实例只执行一次，所有的相关引用都在这一次中进行查找，这样查找的代价就不是那么昂贵了。应该避免在其他方法中查找引用。尤其是访问数据库的方法：ejbLoad()和ejbStore(),如果在这些频繁调用的方法中进行DataSource的查找，势必造成时间的浪费。
调用其他entity bean的finder方法也是一种重量级的调用。多次调用finder()方法的代价非常高。如果这种引用不适合放在setEntityContext这样的初始化时执行的方法中执行，就应该在适当的时候缓存finder的执行结果。只是要注意的是，如果这个引用只对当前的entity有效，你就需要在bean从缓冲池中取出来代表另外一个实体时清除掉这些引用。，这些操作应该在ejbActivate（）中进行。
法则5:总是使用prepare statements
这条优化法则适用于所有访问关系数据库的操作。
数据库在处理每一个SQL Statement的时候，执行前都要对Statement进行编译。一些数据库具有缓存statement和statement的编译后形式的功能。数据库可以把新的Statement和缓存中的进行匹配。然而，如果要使用这一优化特性，新的Statement要必须和缓存中的Statement完全匹配。
对于Non-prepared Statement,数据和Statement本身作为一个字符串传递，这样由于前后调用的数据不同而不能匹配，就导致无法使用这种优化。而对于prepared Statement,数据和Statement是分开传递给数据库的，这样Statement就可以和cache中已编译的Statement进行匹配。Statement就不必每次都进行编译操作。从而使用该优化属性。
这项技术在一些小型的数据库访问中能够减少Statement将近90%的执行时间。
法则6：完全关闭所有的Statement
在编写BMP的数据库访问代码时，记住一定要在数据库访问调用之后关闭Statement,因为每个打开的Statement对应于数据库中的一个打开的游标。
1. 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组件还意味着仅仅聚焦于商务逻辑，它依赖于EJB容器所提供的服务而不是自己来直接解决底层的系统层的问题。
可能的问题
通常，EJB组件在容器之间的移植不可避免地与如下问题相关：
1.它需要依靠的受限制的特点在特定EJB容器中没有得到加强。
2.它需要依靠的非标准的服务从容器中可获得。
为了保证EJB组件的可移植性和一致的行为，你应该使用一个具有与Java2平台安全
策略集相一致的策略集的容器来测试EJB组件，并且其加强了前述的编程限制。
总结
EJB组件开发者应该知道这些推荐的关于EJB组件的编程限制，明白它们的重要性，并且从组件的稳定性和可移植性利益方面考虑来遵循它们。因为这些编程限制能阻止你使用标准的Java语言的特点，违背了这些编程限制在编译时不会知道，并且加强这些限制也不是EJB容器的责任。所有这些原因都使你应很小心地遵守这些编程限制，这些限制在组件的合同中已经成为了一个条款，并且它们对于建造可靠的、可移植的组件是非常重要的。
2. 优化EJB
entity bean为在应用程序和设计中描述持久化商业对象（persistent business objec ts）提供了一个清晰的模型。在java对象模型中，简单对象通常都是以一种简单的方式进行处理但是，很多商业对象所需要的事务化的持久性管理没有得到实现。entity bean将持久化机制封装在容器提供的服务里，并且隐藏了所有的复杂性。entity bean允许应用程序操纵他们就像处理一个一般的java对象应用。除了从调用代码中隐藏持久化的形式和机制外，entity bean还允许EJB容器对对象的持久化进行优化，保证数据存储具有开放性，灵活性，以及可部署性。在一些基于EJB技术的项目中，广泛的使用OO技术导致了对entity bean的大量使用，SUN的工程师们已经积累了很多使用entity Bean的经验，这篇文章就详细阐述的这些卡发经验：
*探索各种优化方法
*提供性能优化和提高适用性的法则和建议
*讨论如何避免一些教训。
法则1：只要可以，尽量使用CMP
CMP方式不仅减少了编码的工作量，而且在Container中以及container产生的数据库访问代码中包括了许多优化的可能。Container可以访问内存缓冲中的bean,这就允许它可以监视缓冲中的任何变化。这样的话就在事物没有提交之前，如果缓存的数据没有变化就不用写到数据库中。就可以避免许多不必要的数据库写操作。另外一个优化是在调用find方法的时候。通常情况下find方法需要进行以下数据库操作：
查找数据库中的纪录并且获得主键
将纪录数据装入缓存
CMP允许将这两步操作优化为一步就可以搞定。[具体怎么做我也没弄明白，原文没有具体阐述]
法则2：写代码时尽量保证对BMP和CMP都支持
许多情况下，EJB的开发者可能无法控制他们写的bean怎么样被部署，以及使用的container是不是支持CMP.
一个有效的解决方案是，将商业逻辑的编码完全和持久化机制分离。再CMP类中实现商业逻辑，然后再编写一个BMP类，用该类继承CMP类。这样的话，所有的商业逻辑都在CMP类中，而持久化机制在BMP中实现。[我觉得这种情况在实际工作中很少遇到，但是作者解决问题的思路值得学习]
法则3：把ejbStore中的数据库访问减小到最少。
如果使用BMP,设置一个缓存数据改变标志dirty非常有用。所有改变数据库中底层数据的操作，都要设置dirty,而在ejbStore（）中，首先检测dirty的值，如果dirty的值没有改变，表明目前数据库中的数据与缓存的一致，就不必进行数据库操作了，反之，就要把缓存数据写入数据库。
法则4：总是将从lookup和find中获得的引用进行缓存。（cache）
引用缓存对session bean和entity bean 都是适用的。
通过JNDI lookup获得EJB资源。比如DataSource,bean的引用等等都要付出相当大的代价。因此应该避免多余的lookup.可以这样做：
将这些引用定义为实例变量。
从setEntityContext(session Bean使用setSessionContext)方法查找他们。SetEntityContext方法对于一个bean实例只执行一次，所有的相关引用都在这一次中进行查找，这样查找的代价就不是那么昂贵了。应该避免在其他方法中查找引用。尤其是访问数据库的方法：ejbLoad()和ejbStore(),如果在这些频繁调用的方法中进行DataSource的查找，势必造成时间的浪费。
调用其他entity bean的finder方法也是一种重量级的调用。多次调用finder()方法的代价非常高。如果这种引用不适合放在setEntityContext这样的初始化时执行的方法中执行，就应该在适当的时候缓存finder的执行结果。只是要注意的是，如果这个引用只对当前的entity有效，你就需要在bean从缓冲池中取出来代表另外一个实体时清除掉这些引用。，这些操作应该在ejbActivate（）中进行。
法则5:总是使用prepare statements
这条优化法则适用于所有访问关系数据库的操作。
数据库在处理每一个SQL Statement的时候，执行前都要对Statement进行编译。一些数据库具有缓存statement和statement的编译后形式的功能。数据库可以把新的Statement和缓存中的进行匹配。然而，如果要使用这一优化特性，新的Statement要必须和缓存中的Statement完全匹配。
对于Non-prepared Statement,数据和Statement本身作为一个字符串传递，这样由于前后调用的数据不同而不能匹配，就导致无法使用这种优化。而对于prepared Statement,数据和Statement是分开传递给数据库的，这样Statement就可以和cache中已编译的Statement进行匹配。Statement就不必每次都进行编译操作。从而使用该优化属性。
这项技术在一些小型的数据库访问中能够减少Statement将近90%的执行时间。
法则6：完全关闭所有的Statement
在编写BMP的数据库访问代码时，记住一定要在数据库访问调用之后关闭Statement,因为每个打开的Statement对应于数据库中的一个打开的游标。