j2ee笔记(编辑修改稿)

j2ee笔记(编辑修改稿)内容摘要：

享的数据。 基于 J2EE 的 Web 服务的核心构架： RMI 1. RMIIIOP 2. RMI 是在 java 中使用 remote method invocation 的最初的方法， RMI 使用 包 RMI－ IIOP 是 RMI 的一个特殊版本， RMI－ IIOP 可以和 CORBA 兼容， RMIIIOP 使用 JAF(Java活动构架 ) 开发者可以使用 JAF来决定任意一块数据的类型、封装对数据的访 问、寻找合适的操作、实例化相关的 bean来执行这些操作等。 例如， JavaMail就是使用 JAF根据 MIME类型来决定实例化那一个对象。 EJB 1. EJB 组件实现代码的限制 EJB组件的约束 EJB的开发者并不需要在 EJB的组件实现代码中编写系统级的服务， EJB提供商 /开发 者需知道并且严格地遵守一些限制，这些限制与开发稳定的和可移植的 EJB组件的利益有 关。 以下是你应该回避使用的一些 Java特色，并且在你的 EJB组件的实现代码中要严格限 制它们的使用： static，非 final 字段。 建议你在 EJB 组件中把所有的 static 字段都声明为final 型的。 这样可以保证前后一致的运行期语义，使得 EJB 容器有可以在多个 Java虚拟机之间分发组件实例的灵活性。 避免这个问题，你就可以使 EJB容器灵活的在多个 Java虚拟机之间分发组件实例。 AWT函数完成键盘的输入和显示输出。 约束它的原因是服务器方的商业组件意味着提供商业功能而不包括用户界面和键盘的 I/O功能。 / 操作。 EJB商业组件意味着使用资源管理器如 JDBC来存储和检索数据而不是使用文件系统 API。 同时，部署工具提供了在部署描述器（ descriptor）中存储环境实体，以至于 EJB组件可以通过环境命名上下文用一种标准的方法进行环境实体查询。 所以，使用文件系统的需求基本上是被排除了。 socket连接，或者用 socket进行多路发送。 EJB组件并不意味着提供网络 socket 服务器功能，但是，这个体系结构使得 EJB 组件可以作为 socket 客户或是 RMI客户并且可以和容器所管理的环境外面的代码进行通 讯。 API查询 EJB 组件由于安全规则所不能访问的类。 这个约束加强了 Java 平台的安全性。 ，设置或创建一个新的安全管理器，停止 Java虚拟机，改变输入、输出和出错流。 这个约束加强了安全性同时保留了 EJB容器管理运行环境的能力。 socket工厂被 URL39。 s ServerSocket,Socket和 Stream handler使用。 避免这个特点，可以加强安全性同时保留了 EJB容器管理运行环境的能力。 、停止 和管理线程。 这个约束消除了与 EJB容器管理死锁、线程 和并发问题的责任相冲突的可能性。 通过限制使用 10－ 16几个特点，你的目标是堵上一个潜在的安全漏洞：。 Java一般角色所不能访问的包和类。 （策略、安全、提供者、签名者和实体）。 Java序列化特点中的细分类和对象替代。 this引用指针作为一个参数或者作为返回值返回 this引用指针。 你必须使用 SessionContext或 EntityContext中的 getEJBObject()的结果。 Java2平台的安全策略 以上所列的特点事实上正是 Java编程语言和 Java2标准版中的标准的、强有力的特色。 EJB 容器允许从 J2SE中使用一些或全部的受限制的特色，尽管对于 EJB组件是不可用的，但需通过 J2SE的安全机制来使用而不是通过直接使用 J2SE的 API。 Java2 平台为 的 EJB 容器所制定的安全策略定义了安全许可集，这些许可在 EJB 组件的编程限制中出现。 通过这个策略，定义了一些许可诸如：,以便加强先前所列出的编程限制。 许多 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容器 /服务器目前在 它们的部署工具中都提供了比标准权限或多或少的许可权限，这些并不是。 理解这些约束 EJB容器是 EJB组件生存和执行的运行期环境， EJB 容器为 EJB组件实例提供了一些服务如：事务管理、安全持久化、资源访问、客户端连接。 EJB容器也负责 EJB组件实例整个生命期的管理、扩展问题以及并发处理。 所以， EJB组件就这样寄居在一个被管理的执行环境中－－即 EJB容器。 因为 EJB容器完全负责 EJB组件的生命期、并发处理、资源访问、安全等等，所以与容器本身的锁定和并发管 理相冲突的可能性就需要消除，许多限制都需要使用来填上潜在的安全漏洞。 除了与 EJB容器责任与安全冲突的问题， EJB组件还意味着仅仅聚焦于商务逻辑，它依赖于 EJB容器所提供的服务而不是自己来直接解决底层的系统层的问题。 可能的问题 通常， EJB组件在容器之间的移植不可避免地与如下问题相关： EJB容器中没有得到加强。 为了保证 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的引用等等都要付出相当大的代价。 因此应该避免多余的 ： 将这些引用定义为实例变量。 从 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完全匹配。 对于 Nonprepared Statement,数据和 Statement本身作为一个字符串传递，这样由于前后调用的数据不同而不能匹配，就导致无法使用这种优化。 而对于 prepared Statement,数据和 Statement 是分开传递给数据库的，这样 Statement 就可以和 cache 中已编译的Statement进行匹配。 Statement就不必每次都进行编译操作。 从而使用该优化属性。 这项技术在一些小型的数据库访问中能够减少 Statement将近 90%的执行时间。 法则 6： 完全关闭所有的 Statement 在编写 BMP 的数据库访问代码时，记住一定要在数据库访问调用之后关闭 Statement,因为每个打开的 Statement对应于数据库中的一个打开的游标。 Security 1．加密 对称加密 （ 1）分组密码 （ 2）流密码 常用的对称加密算法： DES和 TripleDE。