Java 对象持久性：联盟状态

在这个虚拟座谈中，InfoQ.com 和 ODBMS.org 的编辑（Floyd Marinescu 和 Roberto V. Zicari）向一些杰出的持久性解决方案的架构师咨询了他们对于目前 Java 社区中持久性联盟现状的一些看法。

与会人员：

• Mike Keith：JPA 1.0 合作规范制定者，Oracle Toplink 及 Java 持久技术架构师
• Ted Neward：独立咨询师，常常发表关于 ORM 和持久性主题的博文。
• Carl Rosenberger：db4objects 的主要架构师，也是开源可嵌入对象数据库的主要构架师
• Craig Russell： Java 数据对象 (JDO) JSR 的规范领导者，Glassfish 之前的 Sun 应用服务器中实体 bean 引擎的架构师

问题:

• “阻抗失配问题（impedance mismatch problem）”目前仍然存在吗？
• 从您所见的业界使用情况来看，针对新项目您是怎样为各种持久性选项定位的？
• 在您看来，这些现存的解决方案有怎样的优缺点？
• 您认为对象关系映射适合用来解决“对象持久性”问题吗？如果是，为什么？如果不是？又是为什么？
• 您认为关系数据库系统适合用来解决“对象持久性”问题吗？如果是，为什么？如果不是，又是为什么？
• 您认为对象数据库系统适合用来解决“对象持久性”问题吗？如果是，请解释一下认为是的原因；如果不是，又是为什么？
• 在最近的一年内，您希望在对象持久性领域有什么新研究、新发展?
• 假设在过去的十年间，您拥有足够强大的力量来影响这些年间技术的发展，那么现如今什么样的经典项目能被用来作为持久性机制？请解释一下原因?
• 关于这个论题，还有什么需要补充的吗?

问题一: “阻抗失配问题（impedance mismatch problem）”目前仍然存在吗？

Mike Keith：对象模型只要被用来从关系数据库中读取或者写入数据，就会出现阻抗失配问题。如果没有任何策略、技术或工具作为辅助来解决失配、或者失配导致玄乎其玄的设计和极为糟糕的性能的话，阻抗失配确确实实是个棘手的问题。单单由于失配的天性，很多方案常常都无可避免地引发这种情况。技术和工具能够起到很大的作用，也能满足大部分应用程序的需求，但它们还是无法彻底扭转乾坤。

Ted Neward：完全正确。只要数据的暂时和持续形态互不相同（比如这样进退维谷的窘境——我们试图将暂时数据表示为对象的形式，然后将它存入到关系型持续数据库），我们就会遇到阻抗失配问题。从对象到关系，从对象到层级 /XML，从层级（hierarchical）到关系，它们都会引起阻抗失配问题，并且最终都面临同样的基本问题：互不相配（pounding round things into square or triangular holes）。其中一个解决方案是将这些不同的“形态”包含到我们的工具中，例如将集合作为一级概念添加到编程语言中，使得处理数据库中的数据集合来的更加容易，但是这个方案到这里也止步不前了。

Carl Rosenberger：不尽其然，除非你是受到关系数据库的阻挠。让我们来看一下关于采用两种特定语言——Java 和 SQL 的观点：

在 Java 中，你可以通过编写短小精炼、通读易懂的方法而得到非常高的工作效率。而关系数据库中，没有导航（navigation ）这个概念，所以你不得不对表结构熟知于心才能从数据库中得到任何你所需要的数据。假设你想查找到某个雇员老板的薪资，通过 Java 和具有代码自动补全功能的 IDE，你可以在几秒钟内编写出下列代码：

employee.department().manager().salary();使用 SQL 的话，你可能得花几分钟时间写出 SQL 语句来完成同样的任务……

SELECT e2.salary FROM<br id="niud"></br> employee e1, employee e2, department,<br></br> WHERE<br></br> e1.id = current_employee_id<br></br> AND<br></br> e1.department = department.id<br></br> AND<br></br> department.manager = e2.id……但是，你能肯定其中的语法正确吗？你能肯定你没有混淆指向 employee 表的两个引用吗？

在必须使用 Java 和 SQL 来编写应用程序的时候，你会因为这两种截然不同语言间的接口而损失开发时间、质量、效率以及性能。

维护这两种不同的代码是原先所需工作的两倍，并且对重构和敏捷过程产生负面困扰。

但如果你在开发过程中一路都坚持采用对象技术的话，就不会遇到阻抗失配问题。

Craig Russell：这取决于你的业务领域和语言。如果你使用的是 C++，采用多继承将领域模块化，那么你需要做很多工作才能将领域对象存储到关系数据库中。

最重要的一个因素是，你是否尝试使用 Java 领域对象来表现数据库中的已有数据，或者你是否尝试采用数据库来存储 Java 领域对象。在前一种情况下，大部分关系模式可以很好地用 Java 领域对象来表现。但如若你试图将 Java 领域对象存储到关系数据库中去的话，引发失配的可能性会更大一些。

在这种情况下，还是有几个领域会产生阻抗失配。例如，在关系模式下对 Collection 建模就比较困难。在 ODMG 中，我们可以建立一个 Bag 模型，这和 Java Collection 在逻辑上是等价的。但在 Java Collection 框架中，没有实质的类来表达正确的 Bag 语义。最相近的是 ArrayList，但在持久化 ArrayList 的时候，需要人工创建一些额外的信息（处理复制意味着在数据库中引入一个人工的数据列或者使用没有主键的表）。

阻抗失配的另一个领域是继承。尽管很多关系模式实际都包含一个鉴别列，用来区分一个子类与另一个子类的数据行，但是关系模式仍然不能和 Java 概念完全符合。这一技术出现较早，现有大多数对象关系映射解决方案都采用了这个方法。

问题二：从您所见的业界使用情况来看，针对新项目您是怎样为各种持久性选项定位的？

Mike Keith：假定大部分项目都需要关系数据库来存储数据，那么关于持久性的需求最后大都归结为三种类型之一。尽管总是有一些边界情况和微小变化，但这三种类型足以包容主流持久化 Java 对象的应用：

1. JDBC——数量众多的开发者出于各种各样的原因仍然依赖于 JDBC。他们可能不需要或不想要映射层，也可能是他们的雇主不允许他们使用映射层。无论出于什么原因，JDBC 仍然是个可行的选项，并且如果出于正确的理由、以恰当的方式使用的话，它可以是一些应用程序非常合适的选择。
2. 轻量级与定制框架——有时候，需要硬编码 SQL 的人们会发现如果他们在其代码上增加一个“瘦”层的话，可以提高代码的可读性和可维护性。对于这些应用程序，一个简单的 JDBC 框架，或一个适合应用程序开发和编程实践的自产（home-grown）解决方案就很适用。
3. ORM——一个对象关系映射工具，它包括一个映射元数据模型来指示如何将对象状态存储到数据库中，以及如何从数据库中查询。很多人都很喜欢 ORM 技术，并使用这一技术来满足自己的需求。Java 持久性 API（JPA）是在 Java EE 和非企业 Java 环境中的标准 ORM API。

SOA 的流行带来了一类应用程序，它们仅需要将 Java 对象发送到一个 XML sink。该 Sink 最终可能表现为 web 服务端口、BPEL 过程、或待处理队列的形式。映射对象到 XML 的功能由 JAXB 和 SDO 等标准解决，一些类似于 Eclipse Persistence Services 的项目实现了所有这些标准，并且在此基础上加入了更多的功能。

Ted Neward：很明显，我们有很多选择，每项选择都有它自己的优缺点。Mike 很好地总结了其中三个核心选项，在此之上，我还想在添加几点：

1. 存储过程（Stored procedures），我们将所有的存储和读取逻辑（有时候是以数据为中心的业务逻辑）以数据库的可执行代码中，任何应用程序——无论是以 Java、C++、C#或 Ruby 实现的应用程序——都将受到同样的中心逻辑所支配。它们经常直接与 JDBC/ 调用级接口方法相结合，或者与 O/R-M 相结合，以简化对 sproc（存储过程）的调用及获取结果。
2. 对象数据库（OODBMS），将实际对象本身存储到数据库中，Carl 会对该项技术进行具体的描述。

当然，还有很多上述方式的混合方式，但通常是这么划分的。

Carl Rosenberger：当人们说到数据库的时候，他们常常指的是服务于很多不同的用户、不同的应用程序、以及不同的程序语言的企业级数据库。这些遗留数据库在将来很长一段时间仍需采用 SQL。

不久的将来，我们将会有 50 亿移动电话而只有 20 亿台个人电脑。这些移动设备上（以及设备数据库上）的应用程序市场将会远远超过个人电脑的市场。

对于移动设备上的数据库，它们的共性是：

• 它们仅服务于一种程序语言；
• 没有控制访问的 DBA；
• 用户并不手动向设备输入特别的查询。

如果这些设备上的应用程序是用面向对象语言实现的话，还有什么理由去使用关系数据库或 SQL 呢？

我觉得没有什么理由了。

微软对于 LINQ 有很高的评价：它们摆脱了 SQL，并将数据库访问作为一个程序语言的整体概念来推广。

这是新项目的未来，理由很简单，因为这是开发和维护代码最有效的方式。

随着 LINQ 逐渐被接受，函数式语言的概念将会作为数据库查询的主流标准被接受。

对于能够亲历一个对象数据库的开发，我感到非常高兴。对于我们来说，非常有意思的是：LINQ 允许在查询中使用一般的 C#函数调用：你可以做导航。由于对象数据库对于对象的物理存储和它们在 RAM 中的表示非常相似，所以对象数据库对 LINQ 能够做的优化远远胜过关系数据库。对象数据库能够通过一个直接指针来导航，但关系数据库就需要维护并查找两个索引才能在连接（join）之上对表进行查询。

LINQ 是对象数据库厂商的梦想。忽然之间，有了一个查询对象数据库的标准，而且到目前为止，它可以轻松胜过任何一款关系数据库系统。

我们热切盼望能看到针对 Java 的像 LINQ 这样的标准。使用本地查询（Native Queries），我们可以提供一个非常类似的方法：通过 100％的 Java 来表示数据库查询。

有一股强大的推动力在推动着我们的产品开发，追溯这些推动力的来源，我可以断定对于对象数据库有着巨大需求的领域有：

• 资源受限设备上的应用，其要求低内存消耗、高性能表现；
• 拥有诸多属性并且／或者多层继承体系的复杂类的应用；
• 类库频繁重构以及难以维护关系数据库和映射的应用；
• 需要快速推入市场的应用；
• 使用像 Eclipse RCP、JavaFX 或 Silverlight 等技术编写的富客户端应用程序。

在这些领域中，我们的客户似乎表现得非常满意，我因此可以推断这是当今对象数据库最能发挥其长处的领域。

Craig Russell：Java 和 SQL 的最底层抽象是无处不在的 JDBC 编程模型。它提供了最佳控制，并且使你可以利用驱动和数据库的所有特性。但这样的模型并不容易得到正确的结果，也无助于抽象。

很多程序员发现，使用类库来实现资源池，无需编写更多代码就能实现性能优化。但是，棘手的部分在于编写正确的 SQL，另外，处理预处理语句（prepared statements）和结果集仍然极富挑战。

我们发现 iBATIS 类似的工具达到了更高层次，它们摒除了很多繁杂乏味的对预处理语句和结果集操作，但仍需要编写 SQL 代码，这样一来，它们无法避免对数据库的高度依赖，而且还需要做很多使用映射域对象的工作。

在 Java 方面我所知道的层次最高的工具是从 Enterprise Java Beans Container Managed Persistence、JPOX、OpenJPA、Hibernate、TopLink 和 Cayenne 等对象关系映射解决方案中发现的。Java 持久性 API 和 JDO 是 JCP 标准，前面提到的解决方案中很多都实现了这些标准。这些工具有着高度的自动化特性，它们既允许从数据库模式创建 Java 领域对象，也允许从 Java 领域对象创建数据库模式。

在 Java 语言之外，其它类似于 Grails 和 Ruby on Rails 这样的工具提供了高层次的功能项，它们还提供了 web 框架实现，借此程序员可以摆脱乏味的与 web 服务器之间的手动调用。

问题三：在您看来，这些现存的解决方案有怎样的优缺点？

Mike Keith：这个问题，完全可以写上整整一本书来讨论，关于什么时候什么地方应该使用哪种方法的问题，足以引发无止境的讨论。简短来说，我相信它们都自有用处，没有任何一种方法可以成为所有应用程序的最佳选择。我唯一希望的是，开发者在计划使用占应用程序资源 30％的解决方案之前，能够花上一点时间仔细研究一下该解决方案。

Ted Neward：这个问题的回答很长，介于问题太过复杂，我无法在这里做详尽的回答。

Carl Rosenberger：面向对象实践的一个主要优势是可以降低长期维护的开销。如果使用对象数据库的话，你能够将这个优点扩展到数据模型（你的类等等）以及扩展到与其交互的代码。

使用对象数据库，所有的代码都可以以一种编程语言写成。结合现代 IDE，重构能够完全自动完成。

对象数据库使得所有代码在编译时得到检验，包含那些与数据库交互的代码在内。

由于对象数据库能够以与虚拟机在 RAM 上同样的方式（使用单向指针，而不是编入索引的元组（indexed tuples））来处理对象引用，它比关系数据库的处理速度要快得多。

和应用程序运行在同一个虚拟机上的本地纯嵌入式对象数据库，允许深入到数据库去刻画（profiling）及调节瓶颈用例。对于性能和内存有限的移动电话或掌上设备之上的嵌入式运用，纯嵌入式对象数据库是它们完美的选择。

SQL 是众所皆知的，有很多“历史悠久的”成熟 SQL 数据库可供选择，也有很多成熟的工具帮助编写、调整和查询 SQL 系统。

SQL 是可接受的特殊（ad-hoc）查询和数据聚合的标准。

Craig Russell：一般来说，抽象层次越高，应用程序的编写和部署就会越快。

但是为了从数据库投资中得到最后一份性能价值，有些应用程序仍然需要直接使用 SQL。

所以你必须深刻理解数据库提供者所接受的特定 SQL 方言。但大部分工具都能帮助你在较高层次的抽象上完成大部分的工作，你只需要在一些“边角”用例上钻研 SQL。

问题四：您认为对象关系映射适合用来解决“对象持久性”问题吗？如果是，为什么？如果不是？又是为什么？

Mike Keith：在绝大多数数据使用关系型数据库存储并且面向对象编程成为应用软件开发的标准的情况下，对象关系型映射技术纯粹是自然而然的需求。基于这个事实，已经不是如何解决对象持久性的问题，而是如何解决存在于大约 97％的使用 Java 编写并从关系数据库存取数据的应用程序中的问题。到目前为止，对象关系映射是最灵活最实用的解决方案。但是它是否合适？能肯定的是，成功使用了该技术的同仁们肯定是对其赞不绝口。但它是不是通用的最佳方案呢？我肯定如果你就这个问题多询问几个人，一定会有人持反对意见。

Ted Neward：我觉得对于那些希望将生产力和开发的便捷性置于性能和关系型访问能力之上的开发人员而言，这项技术能够满足需求。但不幸的是，很多时候，很多项目最终不得不屈服于性能或者固定关系模型并且可访问性并不像开发者想象的那样合意。项目发展到这个点上，如若不做大的重构甚至是重新编写代码，而只简单地将 O/R-M 用所谓的更具“关系友好”的某些东西来替代，已经无法解决问题了。

Carl Rosenberger：O-R 映射是一种权宜之计。在某种程度上，他们减少了手动编写 SQL 代码的工作。任何权宜之计都会带来相应的开销。以下列出的是 O-R 映射工具表现得不够理想的三个领域：

• 性能
  O-R 映射工具使得整个应用程序运行迟缓。对象需要完全被加载到内存中才能处理面向对象的业务逻辑。
• 复杂度
  O-R 映射缓存和传递对象的方式引出了它本身的副作用。开发者需要消耗很多时间去理解 O-R 映射工具在并发场景中具体是如何工作的。
• 设计的局限
  没有任何 O-R 映射工具能够处理面向对象编程语言提供的所有结构，原因很简单，因为并不是所有的结构在关系世界里都有相应的结构。正如所谓的“鱼和熊掌，不可兼得”，若要设计能够很好地结合 O-R 映射工具工作的应用类模型，就不得不在其他方面有所牺牲。

权宜之计永远都不是根治问题的良药。他们只是在真正的解决方案被发现以前的应急之策。

Craig Russell：对于很多应用程序而言，ORM 能够完美地平衡开发者需求和数据库数据中心资源管理的需求。尤其是在数据库模式受到细致地管理和控制的情况下。相反，如果应用程序的编程人员通过编写 Java 类来控制和创建数据库模式的话，一个很大的风险是应用程序将无法很好地运行，而且重新设计领域类来生成正确的模式可能会很艰难，这对数据移植也会造成严重影响。

问题五：您认为关系数据库系统适合用来解决“对象持久性”问题吗？如果是，为什么？如果不是，又是为什么？

Mike Keith：我想再次强调，关系数据库通常来说不是答案，而是问题所在。除非您是一个崭新的开发“绿色属性”应用软件的公司，否则您的应用软件不得不从关系型数据库中得到它所需的数据。实际上，很多新的应用程序甚至特别选择关系数据库作为数据存储地，因为其技术成熟，有可伸缩性及可靠性的成功记录。但问题在于，如何在使用 Java 这样的面向对象语言编写业务逻辑情况下来访问关系型数据库中的数据？

Ted Neward：我觉得讨论它们合适与否其实并不是关键所在——现在 IT 设施期望并需要将企业范围的数据存储到关系型数据库中的原因多种多样，开发人员需要找到将他们的对象映射到这些数据上的方法。通常来说，没必要直接通过用户界面来实现这些，使用一个中间对象数据库来批量或定期更新关系数据存储可能会促进开发过程中的生产率突飞猛进。

Carl Rosenberger：我认为不是的。阻抗失配是问题，而不是解决方案。

Craig Russell：结合所有 Java 到 DB 的工具的话，我认为答案是肯定的。

问题六：您认为对象数据库系统适合用来解决“对象持久性”问题吗？如果是，请解释一下原因；如果不是，又是为什么？

Mike Keith：对象数据库就像二十世纪的 betamax（Beta 制大尺寸磁带录像系统）。它们在一个问题上处理得很好，但就是不流行。它们渐渐地被边缘化，根本不是因为它们本身太烂、难以使用、或是运行太慢（尽管它们中可能有一些确实存在这些缺陷），而是因为它们无法满足企业的异质应用软件需求。虽然 IT 应用程序无论是在功能方面还是在构建技术方面都在不停地改变，但访问数据的方式却依然保持不变。数据应当能很容易被所有技术和应用程序来访问，在这个方面，关系型数据库做的比较好，对象数据库相对稍逊一筹。

Ted Neward：的确，只要数据存储在 OODBMS 中，它就不需要通过非面向对象技术来直接访问。这仍然是 OODBMS 最大的弱点。

Carl Rosenberger：当然。有了对象数据库，你只需要一行代码就能将任何对象存储到对象数据库中。不需要表和映射的任何额外维护工作。查询成为编程语言的一个主要部分。和数据库交互的代码是类型安全的、能够进行编译时检验、能够自动重构，就如所有其他类型的代码一样。

Craig Russell：对象数据库的市场与应用程序的领域更为相关，而不是访问数据所使用的编程模型。对象数据库的主要基本原理在于具有特定领域模型的系统性能和工作负荷。对于极端需求的应用程序，对象数据库在表现的更胜一筹。在这样的情况下，具有挑战性的工作更趋向于选择对象数据库的工具，比如查询工具、报告生成工具、事件传递、和其它数据库同步、以及失败安全操作等。

问题七: 在最近的一年内，您希望在对象持久性领域有什么新研究、新发展?

Mike Keith：数据能够长时间的保存。有关数据存活的问题之一在于那些已发明的专有存储模式，它们中很多都是在关系数据库流行之前所创建的，到现如今，人们仍然必须通过这些模式来访问数据。您可以去问一下那些系统集成工程师，问一下他们不得不处理的问题是什么，那样您可能会引发比预期更多的讨论。

另外，XML 已经逐渐成为无处不在的通用数据语言，这也说明本世纪面向服务的对象需要逐渐从对象迁移到 XML，再到关系型记录，或者甚至将数据记录以新奇另类的自定义方式存储。在接下来的一年或者几年中，这个领域的研究将会以一种让开发者在开发全程的每个步骤中都能感到满意的方式来解决这些问题。当然，这不会以单一持久性来统管所有方面，但我希望会产生一组统一的、一致的、集成并满足各层需求的持久性解决方案。

Ted Neward：关系的集成及将理论概念融入到编程语言中。

Carl Rosenberger：

(1) 融合面向对象语言及函数式语言

我喜欢函数式编程语言是由于它们处理集合的超强概念以及它的列表推导能力。但我仍然坚信对象是表示状态的最佳方式。

函数式概念和面向对象相结合的编程语言的发展前景非常光明。Scala 和 LINQ 都在这个正确的方向上迈出了精彩的一步。

分析列表推导并针对数据库索引运行之，这并不是什么深奥的技术。从概念上来说，这和 db4o 本地查询非常相似。我希望我们能够尝试使用 Scala 列表推导……即使我们不尝试，我们这个社区中也一定会有人去实现的。

（2）新并发概念

硬件发展走向多内核的趋势将会对编程语言提出新的处理并发的要求。

软件事务内存（Software Transactional Memory）和 Actors 是目前我们所能看到的融入主流编程语言的两个很棒的方法。运用这两个方法的时候，值得好好得思考一下怎样才能将它们以最佳方式与数据库处理相集成。

(3) 状态的管理

在面向对象的世界，我们在客户端和分布式系统中都能够拥有状态：对象。

让我感到吃惊的是，鲜有数据库研究关于如何将客户端的对象与服务器上的提交状态同步。

关系数据库提供了独立写入和锁的概念，但它们并不解决实际问题。其工作原理并不在乎客户端的状态，这也是阻抗失配的另一个因素。

在并发的世界里，我不相信什么锁。

我觉得更好地从根本上解决问题的方法，是将变化推向客户端或者采用与某一时间点一致的对象版本。

通过具体实验来测试这两种方法并据此衡量为什么一种方法比另一种好、好在那些方面，这种比较将会很有意思。

Craig Russell：工具和应用程序的生成，尤其是与前端脚本代码生成的集成仍然是对象持久性的弱点。

问题八：假设在过去的十年间，您拥有足够强大的力量来影响这些年间技术的发展，那么现如今什么样的经典项目能被用来作为持久性机制？请解释一下原因?

Mike Keith：假使我有那样的能力的话，我会一开始就将 EJB 创建成 POJO 模型，绝对可以减轻这个世界长达 8 年的“痛苦”。我还会使它能够支持 Smalltalk：）

Ted Neward：我想我不会对项目强行规定任何解决方案。“从技术出发，结合技术本身能力；以项目为本，综合项目自身需求”

Carl Rosenberger：我们还是抬头往前看而无须回首过去。我希望我曾致力于工作的 db4objects 能够对将来的十年带来好的影响。如果还没有选定数据库技术的话，当今新的移动电话和设备的项目（Android！）应该采用对象数据库技术。

我不是大型企业数据库的专家，但我怀疑网格数据库是否真的能达到它们所能实现的高效。考虑到目前成熟的大型数据库引擎都是用 C 或 C++ 编写，而这些语言不提供分布式和并发的高级概念，我相信这些系统的维护和优化必定又烦又没有效率。

尽管如此，仍然有可能有那么几个超强的牛人能够在合理的开销下实现最快最大的分布式数据库。假如我足够强大的话，我想我会在某种程度上去实现这样的项目。可能再等些时候，等到最近形成的并发概念再成熟一些，然后再去实现的话会更有意义。

关系并不定义以下这些内容：

• 一致性的开始点和结束点；
• 谁拥有 tuple 的原版拷贝；
• 在集群中数据如何分发；
• 预抽取（prefetching）如何深具意义；
• 数据如何从物理上集群；

我主要是看到了这些汲取了现有编程语言中的所有知识的概念的好处，并将这些知识融合到数据库上去。

站在站在理论观点上，如果所有企业应用程序使用互相兼容的面向对象语言来编写代码访问数据库的话，大型企业数据库最终选用对象数据库是有意义并且是值得的。

理想情况下，应该要有一个全世界所有企业应用软件都能够共享的通用面向对象领域模型。

实际上我十年前想过这个问题。如果我当时真的有那样强大的力量，那么今天所有的人都应该在使用这样一个模型了……那样，对象数据库无疑会成为所有应用程序最自然的持久性解决方案。

Craig Russell：如果有那样的假如的话，今天经典的项目则会使用一个配以对象持久层插件的世界级的 IDE，该插件既可以使用关系数据库也可以使用对象数据库来存储对象。

IDE 能够生成包括高度交互性展现的 javascript 和用户界面在内的、完整的 web 框架代码。

Java 虚拟机也允许将 instrumentation 用于变更追踪目的并避免开发商特定字节码转换。运行时性能工具应该能够在没有人为干预的情况下自动调优应用程序。

问题九：关于这个论题，还有什么需要补充的吗?

Mike Keith：对象持久性有趣的地方在于如何激起人们的热情。人们看起来都在恻耳聆听，即使仅仅是在简单提到持久性话题的时候，都能呐喊助威；社区的论坛甚至是在冷静沉默之期也只需要发表一点点评论意见，就能得到无止境的跟贴和评论。

原因可能在于，持久性对于应用程序来说有着巨大的影响力，也有可能是持久性本身就是这么吸引人的话题，但是在持久性领域研究和工作 18 年之后，我还是觉得它值得我们花时间去研究。大家一致认同，那些不注意其应用软件持久性方面地开发者，后果堪虑。

谢谢您邀请我参与这次讨论。

Ted Neward：谢谢您让我参与讨论。

Carl Rosenberger：我相信仿生学：从大自然解决问题的方式中，我们能够学到很多东西。我们可以一起看一下大自然组织知识的方式：它使用大量具有持续进步的高效通信技术、但本身缓慢冗余的系统（人类）。该系统中的任何节点都能与其它节点通信，而且连接的方向和强度可以被调整到与当前需要相吻合。

如果我们将其作为模型，巧妙地从错误中汲取精华的网格计算是未来的趋势，这点对于数据库同样使用。

现在的问题是，这个模型如何与我在上文描述的通用领域模型相协调呢？其实我觉得它协调得非常好。人类有一个通用的面向对象领域模型，这个模型有史以来一直都相对稳定，那就是自然语言。

正是由于自然语言的存在，我们才得以读懂几千年前的文章。

我们已经非常幸运了，因为古希腊文字不是用 OR 映射写成的。进化是缓慢而持续的过程，最终，最出色的概念才会是真正的赢家。

谢谢您邀请我参与讨论。

Craig Russell：谢谢您邀请我参与讨论。

关于作者

Mike Keith

Mike Keith 在面向对象和分布式系统方面有 15 年之多的教学、科研和实际开发经验，尤其精通对象持久性。Mike Keith 曾合作领导 EJB 3.0（JSR220）的规范制定，也是 Java EE 5 专家组（JSR224）的成员之一。他参与撰写了称为《Pro EJB 3：Java Persistence API》的第一本 JPA 参考手册，并且在面向对象和分布式系统方面 15 年之多的教学、科研和实际经验，尤其精通于对象持久性技术。目前，他是 Oracle TopLink、Oracle OC4J 的构架师之一，也是世界各地众多大会和活动的著名演讲者。

Ted Neward

Ted Neward 是加州萨克拉门托地区的自由软件开发构架师和教练。他同时是几本书的作者，像“Server-Based Java Programming”（Manning 出版社）；即将出版的“Effective Enterprise Java”（Addison-Wesley 出版社），另外他和 David Stutz、Geoff Shilling 一起撰写了“SSCLI Essentials”（OReilly），还和 Peter Drayton、Ben Albahari 合作编写了“C# In a Nutshell”（OReilly）。

Ted 还有很多技术白皮书供大家免费下载，他的博客是 neward.net/ted/weblog ，在博客上，他经常发表技术相关的权威见解。他参与了 JCP 规范 JSR 175 的制定，这是 J2SE 1.5 的定制元数据规范；他还是微软 C#团队的最有价值专家（MVP）。另外，他是 DevelopMentor 的讲师之一，主要致力于 Java 和.NET 领域的教学和著作，目前在 TheServerSide.NET 这个关注企业.NET 构架和论点的门户社区担当主编。

Carl Rosenberger

Carl Rosenberger 是 db4objects 公司的主要软件构架师，也是 db4o 数据库引擎的主要程序员。2000 年，Rosenberger 觉得有必要开发能够满足面向对象软件开发员需求的简单易用的对象数据库，于是就在当年，他开始创建 db4o。2002 年，他首次将 db4o 投入商业，当下载量超过 10 万并且有大概 100 个用户验证并将其运用到产品中以后，他于 2004 年为 db4objects 筹建了合资基金会。筹建 db4objects 之前， Rosenberger 是 APSIS 软件和 Lawconsult 的主要软件构架师。他还是 EJB 3 专家组（JSR 220）的成员，关注对象查询 API 的发展。

Craig Russell

Craig Russell 是 Sun Microsystems 的高级工程师。他是 Java 数据对象（JSRs 12 and 243）的需求制定领头人，并且领导团队从事 Apache JDO 的相关技术兼容工具箱（TCK）的工作。他曾是 J2EE 参考实现和 Sun Java 系统应用服务器（Sun Java System Application Server）中容器管理持久性（Container Managed Persistence）组件的构架师。Craig Russell 是 Apache 软件基金会的成员，Apache OpenJPA 项目管理委员会的主席，也是 Apache Incubator 项目的成员，负责向 Apache 引入新项目。

查看原文： Java Object Persistence: State of the Union