EJB2.0中的变化增强,应用程序开发的灵活性和可移植性(3)

　　 
　　在部署时，部署者将使用持久性管理器工具来具体实现这个 bean 类及其从属类。这些具体实现将在运行时保持各种关系，并使各 bean 实例的状态与数据库同步。容器将在运行时管理持久性实例，从而提供一种强健的环境，其中具有自动的访问控制和事务控制。

bean 也可以定义从属对象的值，这些对象是可序列化的对象，如 EJB 1.1 示例中的 Address 对象。这些值通过序列化而变为持久的，它们并不形成与 bean 的关系 -- 它们是严格的容器管理的持久性字段。

容器与持久性管理器之间也已经定义了一个合约，使持久性管理器可以获得事务的句柄，并访问由该容器管理的数据库连接池。这个合约稍嫌宽松，将来还需要使其更为严格，但它是允许持久性管理器跨 EJB 容器移植的基础。容器和持久性管理器之间合约的细节已超出了本文的范围。

除了通过抽象持久性方案定义持久性之外，EJB 2.0 还提供了一种新的查询语言，用来说明持久性管理器应该如何实现 CMP 中的各种查找方法。

EJB 查询语言
EJB 查询语言 (EJB QL) 规定了持久性管理器应该如何实现在本地接口中定义的各种查找方法。 EJB QL 以 SQL-92 为基础，可由持久性管理器自动编译，这使得实体 bean 具有更高的可移植性，并且更容易部署。

EJB QL 和查找方法
EJB QL 语句是在实体 bean 的部署描述符中声明的。使用 EJB QL 非常简单。作为一个例子，Employee bean 的本地接口可以按以下方式声明：

public interface EmployeeHome extends javax.ejb.EJBHome
{
...

public Employee findByPrimaryKey(Integer id)
throws RemoteException, CreateException;

public Collection findByZipCode(String zipcode)
throws RemoteException, CreateException;

public Collection findByInvestment(String
investmentName)
throws RemoteException, CreateException;

}



给定了上面的本地接口定义之后，您就可以使用 EJB QL 来指定持久性管理器应该如何执行查找方法。每个实体 bean 都必须有一个 findByPrimaryKey() 方法。为执行该方法所需的查询是很明显的 -- 使用主关键字的（一个或几个）字段在数据库中查找 bean，这样就不需要任何 EJB QL 语句。

findByZipCode() 方法用来获得具有某个邮政编码的所有 Employee bean。这将使用部署描述符中的下列 EJB QL 来表达。

FROM contactInfo WHERE contactInfo.zip = ?1

该语句本质上是表示“选择其邮政编码等于 zipcode 参数的所有 Employee bean”。

在用于查找方法的 EJB QL 语句中，不需要使用 SELECT 子句来表明要选择的内容。这是因为，查找方法将总是选择与其自身的 bean 类型相同的远程引用。在这种情况下，就可以认为选择语句将返回远程 Employee bean 的全部引用。

如果各种查找方法都一起部署在同一个 ejb-jar 文件中，并且其间具有可导航的实际关系，那么这些查找方法就甚至可以跨越到另一些 bean 的抽象持久性方案中去。例如，findByInvestment() 方法将要求该查找查询从 Employee 导航到投资 bean 的抽象持久性方案中去。声明来表达这种查找操作的 EJB QL 语句如下所示。

FROM element IN benefit.investments WHERE element.name
= ?1



以上语句是说：“选择全部这样的 Employee bean：其获利从属对象至少包含一个投资 bean 的引用，并且其名称等于 findByInvestment() 方法的 investmentName 参数。”

EJB QL 和选择方法
EJB QL 也用于一种称为 ejbSelect 方法的新查询方法中，该方法类似于查找方法，只是它仅供 bean 类使用。该方法不在本地接口中声明，所以也不显露给客户机。此外，ejbSelect 方法可返回范围更大的各种值，而不仅限于 bean 本身的远程接口类型。

存在两种选择方法：ejbSelect<METHOD> 和 ejbSelect<METHOD>InEntity。ejbSelect<METHOD> 方法是全局执行的，这是指这种方法并非专用于执行该方法的 bean 实例。ejbSelect<METHOD>InEntity 方法则专用于执行该方法的实体实例。这些选择方法在 bean 类中被声明为抽象方法，并在这些类的业务方法中使用。下面是 ejbSelect<METHOD> 方法和 ejbSelect<METHOD>InEntity 方法的示例，同时说明了可以如何在业务方法中使用它们。

public abstract class EmployeeBean implements
javax.ejb.EntityBean {
...
// ejbSelectInEntity
public abstract Collection
ejbSelectInvestmentsInEntity (String risk);

// ejbSelect
public abstract Collection
ejbSelectInvestments(String risk);
...
}



在上面的声明中，两种选择方法运行于不同的范围。ejbSelectInvestmentsInEntity() 仅在当前的 Employee bean 实例上执行，所以它只返回雇员的风险投资。

SELECT invest FROM invest IN benefit.investments WHERE
invest.type = ?1



另一方面，ejbSelect<METHOD> 方法的范围则是全局性的，所以同一个查询将返回整个企业内所有雇员的全部风险投资。

ejbSelect<METHOD>InEntity 选择方法可以返回 bean 的远程类型（如在上面的查询中那样）、从属对象或任何其它 Java 类型。另一方面，全局选择方法则不能返回 bean 的从属对象类型。

选择方法的 EJB QL 语句要求使用 SELECT 子句，因为它们能够返回范围更广的各种值。

新的 ejbHome 方法
在 EJB 2.0 中，实体 bean 可以声明一些 ejbHome 方法，用来执行与 EJB 组件相关的操作，但并不专用于某个 bean 实例。在 bean 类中定义的 ejbHome 方法在本地接口中必须有一个与其相匹配的本地方法。下面的代码说明了一个本地方法，它正是作为 Employee bean 的本地接口定义的。applyCola() 方法用来根据最近 COLA（生活费用调整）的增长来更新所有雇员的薪水。


public interface EmployeeHome extends javax.ejb.EJBHome
{
// 本地方法
public void applyCola(double increate) throws
RemoteException;
...
}



applyCola() 方法在 bean 类中必须有匹配的 ejbHome 方法，它被声明为 ejbHomeApplyCola()。ejbHomeApplyCola() 方法并非专用于一个 bean 实例，它的范围是全局的，所以它将对所有雇员的薪水使用同一个 COLA。

public abstract class EmployeeBean implements
javax.ejb.EntityBean {
...
// ejbHome 方法
public void ejbHomeApplyCola (double increase ){
Collection col = ejbSelectAllEmployees ();
Iterator employees = col.iterator();
while(employees.next()){
Employee emp =
(Employee)employees.next();
double salary =
emp.getAnnualSalary();
salary = salary + (salary*increase);
emp.setAnnualSalary(salary);
}
}
}



bean 的开发人员需要为 BMP 和 CMP 实体 bean 都实现 ejbHome 方法。CMP 实现可能在很大程度上要依赖于全局的选择语句（如上面所说明的那样）和 finder 方法，而 ejbHome 的 BMP 实现则将使用直接数据库访问和 bean 的 finder 方法，来查询数据和进行更改。

MessageDrivenBean
在 EJB 2.0 中，对规范的一个基础性更改是添加了一种全新的企业级 bean 类型，即 MessageDrivenBean。MessageDrivenBean 专门设计来处理入网的 JMS 消息。对于许多开发人员来说，JMS 是一种新的范例，所以本文将花一些时间逐步说明对 JMS 的理解，以及它们在 EJB 2.0 中的用法。

什么是 JMS？
JMS 是一种与厂商无关的 API，用来访问消息收发系统。它类似于 JDBC (Java Database Connectivity)：这里，JDBC 是可以用来访问许多不同关系数据库的 API，而 JMS 则提供同样与厂商无关的访问方法，以访问消息收发服务。许多厂商目前都支持 JMS，包括 IBM 的 MQSeries、BEA 的 Weblogic JMS service 和 Progress 的 SonicMQ，这只是几个例子。

JMS 使您能够通过消息收发服务（有时称为消息中介程序或路由器）从一个 JMS 客户机向另一个 JML 客户机发送消息。消息是 JMS 中的一种类型对象，由两部分组成：报头和消息主体。报头由路由信息以及有关该消息的元数据组成。消息主体则携带着应用程序的数据或有效负载。根据有效负载的类型来划分，可以将消息分为几种类型，它们分别携带：简单文本 (TextMessage)、可序列化的对象 (ObjectMessage)、属性集合 (MapMessage)、字节流 (BytesMessage)、原始值流 (StreamMessage)，还有无有效负载的消息 (Message)。

消息收发系统是异步的，也就是说，JMS 客户机可以发送消息而不必等待回应。比较可知，这完全不同于基于 RPC 的（基于远程过程的）系统，如 EJB 1.1、CORBA 和 Java RMI 的引用实现。在 RPC 中，客户机调用服务器上某个分布式对象的一个方法。在方法调用返回之前，该客户机被阻塞；该客户机在可以执行下一条指令之前，必须等待方法调用结束。在 JMS 中，客户机将消息发送给一个虚拟通道（主题或队列），而其它 JMS 客户机则预订或监听这个虚拟通道。当 JMS 客户机发送消息时，它并不等待回应。它执行发送操作，然后继续执行下一条指令。消息可能最终转发到一个或许多个客户机，这些客户机都不需要作出回应

原文转自：http://www.ltesting.net