|
|
Seth White目前是WebLogic EJB开发团队的首席工程师。他已经在WebLogic EJB团队工作了五个年头。在加入BEA之前，Seth曾是Sun Microsystems J2EE开发团队的成员，负责开发JDBC 2.0 API。Seth毕业于Wisconsin-Madison大学，获得数据库系统领域的博士学位。
欢迎Seth，您能向社区介绍一下自己吗？
我现在是WebLogic EJB开发团队的负责人，我已经在BEA工作了大约五年。此前是在Sun Microsystems的J2EE小组工作，负责开发JDBC 2.0 API。
非常棒，那么您认为EJB3中有哪些最激动人心的地方呢？
好的，我认为EJB3有太多激动人心的地方，我只能给出我认为最重要的部分，我认为必须要提到的是新的POJO编程模型、对不连续数据访问的支持和查询语言的增强，以及对象关系映射的标准化，添加对表达元数据注释的支持。
POJO编程显然是最激动人心的特性之一。那么EJB3中的POJO编程模型会对开发人员产生怎样的影响呢？
我想对开发人员的影响将是非常大的，特别是因为它简化了对开发人员编写JEB的要求。因此这些bean类将更像常规的Java bean类。不要求像过去那样实现特殊的回调界面或者扩展EJB类。所以它将使EJB的开发更像常规的Java开发。
太好了。那么注释呢？会影响到人们如何编程吗？
我不知道这是否会改变人们如何编程。但我想这将有助于简化编程和创建EJB的总体工作量。开发人员利用注释可以将元数据直接放入他们的Java代码中，这样Java代码和元数据将被放在一起。这样对理解使用元数据的理由和用途将会更加直观，同时也减少了开发人员维护时可能碰到的问题数量，这也是目前EJB编程模型最主要的缺点之一。
像大量部署描述符和相似的东西。
事实上，在EJB3.0中，部署描述符已经变为可选的。如果您希望使用它们，就可以使用；但是如果不希望使用的话，则可以利用JSR 175风格的注释将所有的元数据直接放入bean类中。
既然有这样的变化，为什么还要使用部署描述符呢？
我想部署描述符在某些情况下仍然非常重要，所以我并不认为部署描述符会被完全抛弃。例如，如果准备开发一个EJB，并将其部署到来自不同供应商的多个应用服务器，也许您需要使用某个供应商特定的部署描述符才能表达其对应元数据，而将标准的元数据放入Java代码的注释中。另一个重要的使用场合是在重写注释中指定值的时候。在将应用程序部署到QA环境，或者生产环境中的时候，如果需要重写元数据中的某些值，这将非常有帮助。
有没有担心过潜在的滥用注释的情况发生?
是的，然而我认为这并不会产生太大的影响，因为如果存在大量的元数据，假定它们都是有价值的，EJB会尽可能地通过为它们指定合理的缺省值来减少元数据的总数。因而EJB 3.0采用了一种基于例外策略的配置。如果用户存在大量的元数据，而且认为这将使代码看上去很散乱，他们总是可以选择将元数据重新部署到某个部署描述符和在不希望看到元数据时能够将其隐藏的工具。
在代码中会暴露出一些其他内容，比如SQL语句或是类似东西。处理这种问题有没有什么最佳实践呢？
有，我想这是一个新的领域。EJB 3.0能做到的一点，正如您所说，它允许您利用Java代码表达特定于某种关系数据库的对象关系映射部分。如果您准备在不同的数据库上部署应用程序并且需要使用数据库特定的SQL，这也许不是一种明智的选择。因此，如果您决定将SQL放入一个部署描述符中，这将是一个很好的例子。但是如果您不喜欢将特定于SQL的东西放入Java代码中，正如我上面说的，如果愿意的话，您总是可以将这些内容放入部署描述符中。
因而我想用户将会分成两大阵营，希望将所有内容放到一起的用户会一次看到所有内容，而其他用户更希望将一些内容放到外面而采用更为模块化的办法。
EJB 3需要Java 5吗?
嗯，我想答案是需要和不需要。因为EJB 3.0 API中并没有明确地需要使用到该语言的新特征。不过显而易见的是，如果您准备利用注释，那么就需要使用J2SE 5。我想这将取决于供应商和他们想做什么。如果供应商决定在J2SE1.4上支持EJB 3.0，则无所谓是否使用Java 5。BEA现在的计划是只在5.0平台上支持它。
那么新的改变会对老的实体模型产生什么影响呢？
老的实体模型仍将在EJB中占有一席之地，而且由于兼容性的原因总是会出现在EJB中。我怀疑大部分新的应用程序将会使用EJB 3.0编程模型，理由是我们刚才讨论到的出现在EJB 3.0中的强大功能。但是对于那些并没打算立即移植到新的3.0 API的人来说，他们不会被迫迁移。专家组目前正在考察EJB 3.0中众多可能有利于使用老编程模型的新特性，并考虑如何让这些特性适用于那些使用老编程模式的用户。因此如果您准备暂时仍使用老编程模型的话，那么完全可以使用，而且还可能利用某些新的功能。
我特别感兴趣针对EJBQL的改进，请您对此评论一下好吗?
有许多针对查询语言EJBQL的内容。其中最重要的新特性，也就是我想介绍的是对批量更新的支持。EJBQL使用新的更新和删除语句，所以它不再仅仅局限于查询。更新和删除帮助开发人员完成消费者折扣之类的事情，而无需将那些消费者对象调入到服务器的高速缓存中，这样您能够直接在数据库中进行更新，提高程序的性能。
当然，EJBQL还有更多其他新特征。它支持直接内连接和外连接操作，并在查询语言中加入了新的取连接（fetch join）概念，该指令可以在执行查询时通过查询直接取得相关的对象。该语言还扩展了对子查询的支持，具有一个类似子句的组，这对那些利用SQL编写查询的用户来说应该非常熟悉，还有其他各式各样的特性，比如名称参数，当然还与查询语言一样支持多态和继承。最后一个需要提到的特性是动态查询工具。除了静态查询以外，EJB 3.0支持动态查询，我想这将非常有用也非常令人激动。
那么在EJB 3中MDB发生了什么变化呢?
针对MDB的改变并不像刚才讨论的大部分改变和实体bean的改变那么广泛。在EJB 3.0中MDB类似于一个实体bean，但更像一个常规的Java对象，因而无需实现回调接口以及扩展EJB类和接口。MDB也可以利用新的依赖性注入框架，它简化了组件访问其运转所需资源的方法。
那么容器外部测试怎么样呢？这是一个重要因素吗？
我认为这是非常重要的，而且EJB3.0做了大量的尝试，并使组件的测试变得更容易，并将开发过程变为一次更为愉快的体验；因而缩短了开发和测试周期，容器外部测试是一个重要部分。这样，人们能够编写一些支架代码，并且由于它们的bean类也就是规则的Java类，因此可以创建那些类的实例，并在测试代码中直接调用业务方法等，不必再将组件应用到应用服务器来测试这些组件的简单行为。
在这次谈话的开始，您曾提到不连续数据访问，它的重要性在何时体现，又如何使用它呢?
不连续数据访问非常重要，特别是在Web应用程序中，或许通过例子来解释它最容易。典型的Web应用程序会读取一些数据，利用一次数据库事务，然后以HTML格式将数据返回到客户端的浏览器，接着客户端对数据进行一些处理，在浏览器中做一些修改，再将这些更改提交回应用服务器。所以当更改提交后，应用服务器需要利用第二个数据库事务更新数据库。这里的不连续意味着允许客户端在数据库事务之外处理数据，利用两次不同数据库事务的数据更新来调整数据读取，以保证更新是一致的。
您能谈一些关于编程模型和实体管理器方面的内容吗？
当然可以，实体管理器在EJB中是一个新的概念，但是存在于其他持久性API中。因此，这里EJB简单地标准化了一些Java社区中好的想法。实体管理器的角色是成为客户端代码用来访问实体bean子系统的主接口，它提供了从数据库中创建和删除实体bean，查询实体bean等功能。
既然开发人员利用POJO开发，实体管理器在重新连接对象时如何去处理呢？
当客户端希望得到从前一个事务中取回的实体bean实例并将其与实体管理器相关联时，就会进行重新连接，这样针对对象所做的任何更新才会持久保存在数据库中。通常情况下，实体管理器在进行重新连接时所做的就是检查对象的主键，它将告诉实体管理器该对象是上一次从数据库中提取的旧对象，还是需要在数据库中创建的新对象，并将使用该版本号作为数据在数据库中的版本号，实体管理器利用一种基于版本号的机制并发控制算法以更新数据库，并保证对象重新连接后事务提交的一致性。
那么开发人员会为对象模型添加一个版本属性吗？
通常是这样的。版本属性不需要公开在对象模型中，但它必须存在数据库中以保证其可以被容器使用，正如我提到的，保证更新的一致性。但是至于要不要通过对象模型将对象外部版本号公开给客户端，则取决于开发人员。
EJB如何与Beehive控件范例相连接或者关联呢?
控件是位于J2EE之上的便于使用的一层，EJB能够用于实现特定类型的控件，这些控件可以保证数据的访问，我想还可以隐藏某些关于实体管理器的细节，以及在每次使用过程中并不总是必须出现的一些其他EJB API细节。所以控件为人们在使用EJB时的某些公共场合提供了方便。
专家组现在正谈论的问题并不在早期的草案中吧?
这个问题问得好。到目前为止，专家组今年早于Java 1曾提出了一个早期的草案，这个早期草案的目的是从用户中获取有关EJB 3.0第一个修订版尽可能多的反馈。从那时起，专家组开始忙于考虑一个关于EJB的注入框架，同时指定了将部署描述符应用于重写注释中表达的元数据值的方法。因而，如果读过早期草案的话，您会发现它仅仅讨论了注释，并没有涉及到重写工具，更确切地说它已经起草完毕。
实体管理器将会通过一些接口成为可嵌入的吗?
通常是这样的。版本属性不需要公开在对象模型中，但它必须存在数据库中以保证其可以被容器使用，正如我提到的，保证更新的一致性。但是至于要不要通过对象模型将对象外部版本号公开给客户端，则取决于开发人员。
最后，请您为那些正在考虑使用EJB 3的读者提一些建议吧?
首先，我希望读者通过这次谈话了解到EJB 3.0发生了哪些变化。我想专家组在过去的这几年中已经获得了许多来自Java社区的优秀想法，这是一项真正出色的工作。专家组还尝试着将它们标准化作为官方Java标准的一部分。因此，如果大家过去对EJB已经有了一些领悟，这次应该真正地关注一下EJB 3.0，因为我想大家将会惊讶于其舒适感，并且会真正地喜欢上它。
|
|
