四、远程接口 为了远程存取一个会话bean，你仅需要用如下的@Remote注解来对它进行注解即可：
@Stateless
@Remote
public class MusicStore implements IMusicStore
{ ...} |
在上面的实例中，MusicStore bean仅仅实现了一个商业接口；既然这个类被指定为远程的，所以我们假定它是远程的。否则，如果MusicStore实现了两个商业接口，那么你将被要求指定哪个接口是本地和哪个接口是远程的。为此，你可以使用下面两种方法中的一种：在类上或在接口上。改变MusicStore类来使用一个远程接口的情况如下所示：
@Stateless
@Local( { IMusicStore.class } )
@Remote( { IMusicStoreRemote.class } )
public class MusicStore implements IMusicStore, IMusicStoreRemote
{ ...} |
你可以把上面的方法与在一个接口上指定的方法进行比较：
@Remote
public interface IMusicStoreRemote
{ ...} |
注意，远程接口并没有抛出RemoteExceptions异常。如果一个异常在协议级上出现，那么一个包装了RemoteException的EJBException异常将由容器抛出。作为一个RuntimeException异常，EJBException不需要在远程接口的方法签名或在它的实现bean类中声明。
五、有状态的会话beans 有状态的会话beans与无状态的会话beans有非常相似的需求。就象无状态的会话beans，它们必须至少有一个商业接口。然而，它们被代之用@Stateful注解所注解。因此在音乐店实例中，用户的购物车已经被建模为一个有状态的会话bean-既然它描述了用户和服务器之间的有状态的会话：
@Stateful
public class ShoppingCart implements IShoppingCart
{ ...} |
如在EJB 2.x中一样，调用相同的到一个有状态的会话bean的参考也是由相同的EJB实例来处理的；这样以来，把这一参考存储到一个能够被客户不断读取的位置就显得极为重要。在音乐店情况下，这个参考存储在用户的HttpSession中。
六、消息驱动的Beans 消息驱动的Beans(MDB)还要实现一个商业接口并且被注解以指示它们的bean类型。然而，在这种情况中，该商业接口并不是来自于域而是来自于一个针对所用消息系统类型的适当的听者接口。在JMS的情况下，这是javax.jms.MessageListener。这个音乐店的订单处理器提供一实例:
@MessageDriven
public class OrderProcessor implements MessageListener{
public void onMessage(Message message){
ObjectMessage objectMessage = (ObjectMessage) message;
try{
Order order = (Order) objectMessage.getObject();
System.out.println("Products Ordered:");
for (Product p : order.getProducts())
{ System.out.println(p.getTitle()); }
}
catch (JMSException e) { e.printStackTrace(); }
}
} |
就象在EJB 2.x一样，你可以给发布者提供关于如何配置MDB的其它信息。这个信息现在能够通过@MessageDriven注解的activationConfig元素来提供。例如，为了定义OrderProcessor仅在JMS消息到达订单队列时激活，你可以对类进行如下注解：
@MessageDriven(activateConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/orders")
})
public class OrderProcessor implements MessageListener
{ ...} |
但是就象在前一个版本的EJB中一样，发布者将负责把一个MDB与一个目标或终端相关联。
七、打包和发布 在EJB 3.0中的打包与EJB前一个版本中的打包很相似。就象在前一个版本中一样，企业bean类必须被打包成一个.JAR文件。最大的不同在于，在EJB 3.0版本中，发布描述符成为可选的。然而，如果提供一个发布描述符的话，那么它必须存在于它通常所在位置(META-INF/ejb-jar.xml)。
该示例应用程序展示了构建一个EJB3.0 EJB-JAR并且以一个企业档案(EAR)形式把该JAR与web应用程序(WAR)绑定到一起。该构建使用了Maven 2.0；更多信息请参考所附源码。
作者注: 在Jboss中，EJB 3.0 jar文件的扩展名为.ejb3-这是一个JBoss惯例而并不是规格说明书中的要求。 为了发布示例应用程序，只要把结果.EAR文件复制到一个用JBoss AOP 1.3.4发布器配置的一个JBoss 4.0.3服务器的发布目录下。所附源码中也包含安装指令。
八、使用一个简化的模型 EJB 3.0公共草案展示了一种创建企业级组件的相当简化的模型。这种新型范例的目的在于简化开发，只是引入了较少的超出前面讨论范围的新功能。然而，EJB 3.0所提供的这种简化应该会大大地增强团队开发的生产能力，你将有趣地看到这种新型轻量级实现是怎样与其它如Spring和Hibernate等轻量级框架竞争的。
