下面列出了一些EJB QL的增强特性：
·支持批量更新和删除。
·直接支持内连接和外连接。FETCH JOIN运行你指出关联的实体，Order可以指定只查询某个字段。
·查询语句可以返回一个以上的结果值。实际上，你可以返回一个依赖的类比如下面这样：
SELECT new CustomerDetails(c.id, c.status, o.count)
FROM Customer c JOIN c.orders o
WHERE o.count > 100
·支持group by 和having。
·支持where子句的嵌套子查询。
在提交的EJB3.0草案中，EJB QL与标准SQL非常的接近。实际上规范中甚至直接支持本地的SQL(就像我们上面提到的那样)。这一点对某些程序员来说也许有些不是很清楚，我们将在下面进行更详细的讲解。
多样性
方法许可(Method permissions)可以通过@MethodPermissions或@Unchecked注释来声明；同样的，事务属性也可以通过 @TransactionAttribute注释来声明。规范中仍然保留资源引用和资源环境引用。这些一样可以通过注释来声明，但是有一些细微的差别。比如，上下文(context)环境要通过注入工具控制。容器根据bean对外部环境引用自动初始化一个适当的已经声明的实例变量。比如，你可以象下面这样获得一个数据源（DataSource）：
@Resource(name="myDataSource") //Type is inferred from variable
public DataSource customerDB;
在上面的例子中如果你不指定引用资源的名称(name)那么其中的customerDB会被认为是默认值。当所有的引用属性都可得到时，@Injec注释就可以这样写：
@Inject public DataSource customerDB;
容器负责在运行时初始化customerDB数据源实例。部署人员必须在此之前在容器中定义好这些资源属性。
更好的消息是：那些以前必须检测的异常将一去不复返。你可以声明任意的应用程序异常，而不必在再抛出或捕获其他类似CreateException和 FinderException这样的异常。容器会抛出封装在Javax.ejb.EJBException中的系统级异常或者只在必要时候抛出 IllegalArgumentException或IllegalStateException异常。
<ccid_page/>
<!--BlogUser:itzealot--><!--BlogType:10-->
EJB文件处理模式
在我们结束本节之前，让我的快速的浏览一下容器提供商在EJB处理模式方面可能的变更。规范中对此并没有明确的表态，但我可以想到至少两种模式。
·一种办法是首先利用EJB文件生成类似于EJB2.1部署模式的文件（包括必要的接口和部署描述符）然后再用类似于EJB2.1的方式来部署这个EJB组件。当然，这样产生的部署描述符可能并不标准但是它可以解决同一个容器对EJB2.1和EJB3.0兼容的问题。
·另一种方法是一种类似于jsp托放的部署模式。你可以把一个EJB文件放到一个预先定义的目录下，然后容器会识别这个EJB并处理它，然后部署并使之可以使用。这种方法可以建立于上面那种方法之上，在支持反复部署时有很大的帮助。考虑到部署的简单性也是EJB3.0规范的目的之一，我真诚的希望在下一个草案出来时能够确定一个模式(至少能有一个非正式的)。
你有什么想法？
EJB3.0规范的制定正在有序的进行，为了使 EJB的开发变得更加容易，EJB规范组织作出的努力是有目共睹的。就像他们说的那样，一切对会变得简单，但做到这一点并不容易。目前已经定义了50个注释标记(还有几个将在下一个草案中发布)，每一个都有自己的缺省规则和其他的操作。当然，我真的不希望EJB3.0变成EJB2.1的一个翻版"EJB 3.0 = EJB 2.1 for dummies"（希望这个等式不要成立）。最后，我还是忍不住要提一些我自己的观点：
·首先，规范确实使反复部署变得容易了，并且有一个简单的模式来访问运行时环境。我还是觉得home接口应该放弃。
·在早期的EJB规范中，实体bean用于映射一个持久化存储。理论上(也许只是理论上)可能需要把实体bean映射到一个遗留的EIS (entERPrise information system)系统中。出于将来扩展的考虑这样作是有好处的，并且可以使更多的业务数据模型采用实体bean。也因此其伴随的复杂性使得实体bean不被看好。在本次提交的草案中，一个实体bean只是一个数据库的映射。并且是基于非抽象持久化模式和简单的数据访问模式的更加简单开发。
·我对模型变更持保留态度，我认为在EJB中包含SQL脚本片断并不是个好注意。一些开发人员完全反对包含某些“SQL片段（SQLness）”（比如 @Table 和 @Column注释）。我的观点是这些SQLness是好的，据此我们可以清楚的知道我们到底要数据库作些什么。但是某些SQL段我看来并不是很好，比如 columnDefinition="BLOB NOT NULL"，这使得EJB代码和SQL之间的耦合太过紧密了。
·尽管对于本地SQL的支持看似很诱人，其实在EJB代码中嵌入SQL是一个非常糟糕的主意。当然，有些办法可以避免在EJB中硬编码SQL，但是这应该在规范中说明，而不能是某些开发人员自己定义的模式。
·假设@Table注释只用于类。在运行时通过@Table注释的name属性定义的表名称将必须对应一个实际的数据库表。规范对此应该给予清楚的说明和一致的模式。
·规范还需要更清楚的说明客户端编程模型，尤其是普通Java客户端。规范中所有的参考都假设或者隐含的使用EJB客户端。而且规范中对客户端的向后兼容方面也没有给出明确的说法。
·Transient注释应该重新命名以避免和已有的transient关键字发生冲突。事实上，在这一点上我们更乐于稍微的背离一下 configuration-by-exception原则并且定义一个@Persistent注释来明确的定义持久化字段。@Persistent注释可以仅仅是一个标记注释或者它可以有几个属性来关联O/R映射注释。
与其他规范的关联
目前可能影响到EJB3.0的JSR有JSR175（Java语言元数据工具）和JSR181（Java Web服务元数据）
JSR175已经初步完成并且不会和EJB3.0有太大的冲突；但是JSR181与EJB3.0有两个关联的地方：
·Web Service接口：EJB规范将采用一种机制适应JSR181以便可以把一个bean实现为一个Web service并告诉Web service如何被客户端调用。
·JSR 181计划采用不同的机制来处理安全问题。在早期的规范中EJB建议使用一个一致的机制（MethodPermissions），但是JSR 181计划使用一个稍微不同的方式（SecurityRoles和SecurityIdentity注释）。同样的RunAs注释的定义也存在这些许差别。这一问题还在解决中最终会在J2EE层的规范中维持其一致性。
在J2EE 1.5中的一些开发规范可能与EJB3.0有关联。除了上面说到的几个关联之外现在没有其他的开发规范与EJB3.0有冲突。
结束语
在使EJB的开发变得简单高效之前，我们还有很长一段路要走。规范组织在降低EJB的开发难度方面起了个好头。O/R映射模型的提议还处在早期阶段，规范组织正在完善它。我希望它不要太复杂也不要与SQL过分的耦合。让我们不要只是停留在期望、希望、思考和请求中：提出你的想法并把你的建议发送给规范组织 ejb3-feedback@sun.com。JCP并不是很民主的组织，但是你的建议一定是有价值的。
