《Effective.Enterprise.Java中文版》知识点摘要

《Effective.Enterprise.Java中文版》本书最重要的部分是：理解企业级计算技术中的常规问题和使用企业级JAVA平台技术来处理这些问题。.

语言和API也许会发生变化，但是你将会理解：构建良好架构所要考虑的问题；有那些通信方式可供选择；如何选择状态存储的位置；各式各样的安全问题等等这些思想性的东西不会变。

资源管理：线程、数据库连接、套接字、文件，所有这些资源比堆内存来说要更难于管理。他们的是生命周期存活于JAVA虚拟机之外，并且需要以一种对并发使用来说友好的方式来被获取和被释放。

企业计算的十大谬误

参考P23

Web应用是一系列资源，比如servlet、jsp、模型类、工具类、以及静态资源（HTML、图像、声音文件等），它们共同地相互协作以提供所需功能。Web应用采用单一的.war文件部署，所以不可能出现：只部署了部分应用或应用的各个部件之间的版本不匹配。

当你为企业级应用和系统规划基本流程和设计的时候，牢记以下项中包含的建议，你就能向优雅的目标迈进：建立一个能够对高性能、高扩展性的企业级系统提供支撑的架构。

第1项：优先采用构件作为开发、部署和重用的核心元素。

第2项：跨越构件边界优先采用松耦合。

第3项：区分逻辑层和物理层。

第4项：数据和处理程序要尽可能靠近。

第5项：牢记标识引起的竞争。

第6项：使用“挂钩点”来注入优化、定制或新功能。

第7项：面对故障时要健壮。

第8项：定义性能和可扩展性目标。

第9项：只在事务性处理中使用EJB。

第10项：先测量性能，再进行优化。

80/20规则，它是计算机科学领域里最知名的规律之一，其最常见的形式有：20%的代码使用了80%的系统资源，20%的代码占用了80%的运行时间，20%的代码占用了80%的内存，80%的需求文档只覆盖了20%的必要工作等等。

第11项：认清“提供商中立”的成本。

第12项：内置监控功能。

“心跳”进程监控错误与保存日志信息。

在不运行调试器的情况下，要调试serlet或EJB时，日志信息越多越好。

第13项：内置管理支持。

第14项：部署要尽可能简单。

第15项：理解你所做的通信选择。

进程通信方式：RPC和消息传送；远程方法调用（RMI）；公用对象请求代理程序架构（CORBA）；Servlet(servlet与xml有效负载结合直接进入Web Sservice领域);Java消息服务（JMS）(JMS与xml有效负载结合将你带入Web Sservice领域)；Jini（最显著的思想是自我修复网络和服务发现）；JXTA；用于XML的Java API（JAX—RPC）；用于XML消息传递的Java API（JAXM）。

上面中任何一个都能最终完成这项工作——将数据从机器A转移到机器B。很明显决策必须根植于某种事物，如果你的系统通信要发生在特定环境之上，请考虑下面的问题：

1）、你需要跨越防火墙的通信吗？防火墙他们不允许在任意TCP/IP端口上有进入的流量，而这正是RMI和CORBA都要使用的。

2）、你需要同步通信吗？如果你的通信模式大多是请求——响应模式，RPC肯定上首选的通信模式。

3）、你需要能够和任何平台进行通信吗？包括那些你并不很了解的平台？Web服务可以在所有平台之间创建一个“中间地带”，因为XML的无处不在。

第16项：仔细考虑你的查找。

在分布式系统中有多种形式的透明：访问（隐藏数据表示的不同，以及一个资源如何被访问）、位置（隐藏一个资源被定位在哪里）、迁移（隐藏一个资源可以被移动到另一位置）、重定位（隐藏一个资源可以在运行时移动到另一位置）、复制（隐藏一个资源的复制）、并发（隐藏一个资源可以被多个竞争用户分享）、失败（隐藏一个资源的失败和恢复）、持久性（隐藏一个软件资源是在内存中还是在硬盘上）。

第17项：识别网络访问的代价。

第18项：优选上下文完整的通信风格。

第19项：优选数据驱动的通信而不是行为驱动的通信。

第20项：避免为远程服务请求去等待响应。

第21项：考虑构件的划分以避免任何一台机器负载过重。

分布式系统、DNS

第22项：为了开放集成而考虑使用Web服务。

XML+HTTP

第23项：大批量地传送数据。

传送的块状数据要足够大以适应远程调用的开销。不要一次传送一个，而是大批量传送：以完整的对象块，或者对象集的形式。这正是IBM/BEA的服务数据对象（Service Data Object）解决方案的基本思想，并且可以论证这只比过程优先的持久层差一点。

批量地传送数据也有一些局限性——不断地在网络上传送大量数据并不多次往返好多少，因为你现在正在吸干网络带宽，并强制通信层花费相当大的力气来编组、发送、接收、以及反编组数据。你还要基于客户端将怎样使用（或不使用）某一个特大的数据项，来判断它是按引用传送还是按值传送更好；尤其要注意集合和可序列化对象。

第24项：考虑定制你自己的通信代理。

第25项：保持简洁。

代码保持简洁

第26项：优先采用规则引擎去处理复杂状态的评估和执行。

规则引擎通常服务于两个目的：（1）以最好的方式捕获业务规则（2）允许修改这些规则而不需要重新编码Java代码本身。

任何书写规则引擎能够理解的“规则语言”，有几种不同的实现：一种是开源的实现，叫做drools，可以从http;//www.codehaus.org上获得；BEA也包含了一种实现，并将其作为WebLogic平台的一部分，ILOG也在销售一种用来整合其它服务器的第三方的引擎。JSR94定义了标准的API用于连接规则引擎；它的参考实现叫做Java专家系统外壳，可以免费用于非赢利目的。

第27项：优先为隐含的非原子性错误场景采用事务性处理。

第28项：区分用户事务和系统事务。

第29项：最小化锁窗口

作为一条规则，在被同步的区域内，你应该尽可能少的操作。

第30项：当持有锁时不要让步给在构件之外的控制。

为了你自己，在执行任何构件外的通信之前，请确保所有的锁是释放的。

第31项：理解EJB的事务关联。

第32项：优先使用本地事务而不是分布式事务。

第33项：为了更好的可扩展性而考虑使用乐观的并发机制。

第34项：为了显式的并发控制而考虑使用悲观的并发机制。

第35项：考虑使用较低的隔离级别以获得更大的事务吞吐量。

第36项：面临回滚时使用保存点来保留部分工作。