巴西亚（Roland Barcia），高级技术研究人员，IBM Software Service for WebSphere的Web 2.0首席架构师，已发表了40多篇关于JavaⅢ持久性、Ajax、REST、JavaServer Faces以及消息传递技术等方面的文章和论文，在各种平台的中间件系统实施方面积累了1 0年的经验。
　　Geoffrey Hambrick，IBM Software Services for WebSphere Enablement Team的杰出工程师，分布式对象技术领域的先驱者，参与制定各种标准，是IBM developerWorks。专栏the EJB Advocate的作家。
　　Kyle Brown，IBM Software Services and SuPpo rt的杰出工程师，曾与人合著过多本畅销书，其中包括Java Programming with IBM WebSphere and Enterprise Integration Patterns——书。Kyle是模式方面的知名专家，担任PLOP（Pattern Languages of Programs）会议的前任主席。
　　Robert Peterson，IBM Software Service for WebSphere的高级管理顾问，往返于世界各地，为未来的IBM软件系统实施战略性和概念性的验证项目。他出版了大量的技术书籍和论文，经常在各种会议上发表演讲，拥有多项企业系统的美国专利。
　　Kulvir Singh Bhogal，IBM Software Service for WebSphere的高级管理顾问，主管制定和实施WebSphere为中心的SOA解决方案。他在很多技术领域中申请了共100多项专利，在JavaPro Manazine，lBM developerWorks， OReilly Media，Java Developers Journal等多家出版刊物撰写文章。

　　《IBM最佳实践：Java企业级持久化技术指南》由IBM的5位资深专家合著而成，全书分为两部分。第1部为第1～4章，第1～3章分别讲述了持久化技术的发展历史、高层需求对选择持久化技术的影响以及如何根据企业应用的需求来设计持久数据的模式，第4章介绍了一种比较不同持久化技术的方法并给出一份调查问卷。第2部分为第5～10章，从技术背景、架构概况、编程模型、ORM功能支持、调优选项和公共范例开发6方面详细地介绍了JDBC、iBATIS、Hibernate、Open.JPA和puteQuery这5种持久性框架，并就实践过程中可能遇到的问题给出各种建议，以供读者参考。
　　《IBM最佳实践：Java企业级持久化技术指南》内容丰富，紧跟技术前进的步伐，非常适合.Java开发人员学习使用，同时也是项日经理、系统架构师以及测试人员深入学习Java企业开发知识的必备参考书。

　　但是，依靠开源社区有存在风险，尤其是那些“一人”项目，或者是支持项目的社区突然消失这类情况。现实情形是，当一种新的方法赢取了社区的人心时，许多看似受欢迎的标准就逐渐消亡了。例如，已经有了两个版本的实体Enterprise JavaBeans组件为应用程序提供ORM框架，但不幸的是，“压错了宝”会导致在企业级持久性方法上的支持者的大量流失
　　2.2.4 供应商、许可协议和支持
　　衡量活跃社区的另一个基准是，该技术是否有市场？特别是，有多少供应商提供（和支持）这一框架？对于参与某一特定技术的供应商或者开源社区来说，通常的情况是“人越多，越开心”，因为没有人希望被锁定到一个单一来源或者（也许更糟的）不受支持的框架上。背后有大软件厂商可以依靠的、提供“收费的技术支持”的开源社区通常要比其他社区做得更好。例如，JBoss拥有Hibernate，BEA支持Open JPA——当细想是充满活力的社区吸引了供应商还是刚好反过来这一问题的时候，我们就处于一个典型的考虑鸡和蛋谁先谁后的处境中。无论如何，这些社区绝对是强大的、活跃的社区。
　　大部分的持久性技术或遵循商业许可协议，或遵循开源的许可协议。使用了商业软件许可协议的，用户需要支付费用来获得软件的使用授权。许可协议定义了一些条款和条件，在这些条款和条件的规定下，用户可以或者不可以使用这一软件。例如，一些商业数据库软件许可协议规定了运行它们的机器的处理器数量。至关重要的是，企业必须密切留意他们已经接受的许可协议，因为违反这些协议的代价相当的高。
　　如果持久性技术由商业公司支持，则需要考虑该商业提供者是否对提供的支持进行收费。还有，必须考虑（即使可能性微乎其微）这个商业提供者停止运营的可能性。许多企业往往基于问责制而选择商业公司，如果在持久性框架中存在错误，企业通常希望立刻有人来修复。
　　使用一些开源解决方案，对代码的修复和更新的要求有可能因为很少或者根本没有责任追究规定而显得“仁慈”一些。因此，企业必须寄希望于他们自己的开发人员能够修正任何错误，或者有开源社区的成员能够解决手边的问题。然而，如果没有把所做的改动放回原先的源代码中，这种许可协议可能会限制你做出这种改动。

第1部分 持久性的一个问题
第1章 对象关系映射简史
1.1 对象关系阻抗失配
1.2 Java史前课程
1.2.1 Delphi
1.2.2 RogueWaveDBTools.h++
1.2.3 NeXTDbKit
1.2.4 TopLinkforSmalltalk
1.2.5 IBMObjectExtender
1.3 第一代Java解决方案
1.3.1 JDBC1.0和2.0
1.3.2 Java的TopLink
1.3.3 EJB1.0
1.3.4 VisualAgePersistenceBuilder
1.3.5 EJB2.0
1.4 开源及下一代
1.4.1 Hibernate
1.4.2 iBAIS
1.5 吸收对象数据库的反主流文化
1.5.1 ODMG
1.5.2 JDO
1.5.3 JPA
1.6 面向服务架构及之后
1.6.1 信息作为服务
1.6.2 pureQuery和ProjectZero
1.7 小结
1.8 参考文献

第2章 高层需求和持久性
2.1 一些“必要的”背景
2.1.1 了解利益相关者
2.1.2 不同的人有不同的需求
2.2 管理人员和业务需求
2.2.1 硬件和软件的依赖
2.2.2 标准的支持
2.2.3 开源和社区驱动的活动
2.2.4 供应商、许可协议和支持
2.2.5 知识产权的考虑
2.2.6 可用的技术人员
2.2.7 有效的培训和指导
2.2.8 开发和管理工具
2.2.9 构建还是购买
2.3 IT负责人和企业级品质的解决方案
2.3.1 功能性和业务流程
2.3.2 可靠性和事务请求
2.3.3 可用性和用户会话
2.3.4.有效性和运行时资源
2.3.5 可维护性和应用组件
2.3.6 可移植性和标准平台
2.3.7 互操作性和企业级品质的解决方案
2.4 小结
2.5 参考资料

第3章 设计持久对象服务
3.1 一些基本概念
3.1.1 模式语言
3.1.2 领域模型模式
3.2 领域建模最佳实践
3.2.1 选择某种建模符号来沟通必要细节
3.2.2 项目利益相关者参与创建和修改领域模型
3.2.3 领域模型不是设计模型
3.2.4 领域模型并不总是必需的
3.2.5 基于变化的规划
3.3 公共的ORM范例的价值
3.3.1 领域模型
3.3.2 数据库模式
3.3.3 数据库约束
3.3.4 数据库规范化方法
3.3.5 服务接口
3.3.6 单元测试用例
3.4 再谈对象关系映射阻抗失配
3.4.1 关联.
3.4.2 组合
3.4.3 包容
3.4.4 封装
3.4.5 继承
3.4.6 多态性.
3.4.7 对象标识
3.4.8 对象导航
3.5 对象关系映射方法
3.5.1 自顶而下
3.5.2 自底而上
3.5.3 中间对接
3.6 可考虑的其他模式
3.6.1 元数据映射、延迟加载和工作单元
3.6.2 分布式外观和数据传输对象
3.7 小结.
3.8 参考资料

第4章 如何评估可选项
4.1 同型比较
4.1.1 能够体现好、更好和最好的语境
4.1.2 建立独立的标准
4.1.3 制订清单并检查两次
4.1.4 保持清单真实
4.2 企业级持久性
4.2.1 一种规格并非处处适用
4.2.2 不问是否，而问什么与为何
4.2.3 细节就是问题所在
4.3 一个可用的评估模板
4.3.1 背景
4.3.2 架构概况
4.3.3 编程模型
4.3.4 0RM功能支持
4.3.5 调优选项
4.3.6 公共范例的开发过程
4.4 充分利用你的经验
4.4.1 尽早并经常使用调查问卷
4.4.2 记住历史以免重蹈覆辙
4.5 小结
4.6 参考资料

第2部分 同型比较
第5章JDBC
5.1 背景
5.1.1 框架类型
5.1.2 历史
5.2 层次架构概况
5.2.1 标准遵守
5.2.2 平台要求
5.2.3 其他依赖
5.2.4 供应商和许可协议
5.2.5 现有文献
5.3 编程模型
……
第6章 Apachei BATIS
第7章 Hibernate Core
第8章 Apache OpenJPA
第9章 pureQuery和ProjectZero
第10章 将理论付诸实践
附录A 安装公共范例