EJB 3规范自发布之日起就受到了不少开发者的青睐，原因在于其基于注释和POJO的思想简化了EJB的开发。相对于EJB 2.1，基于注释的EJB 3代码更加简洁，POJO的思想使得开发出来的EJB更像普通的Java Bean。主要表现在：

　　使用@Stateless@Stateful、@Entity等注释声明某个类（接口）是 EJB（EJB接口）。比如：EJB 3中，会话Bean无需实现SessionBean，其接口也无需扩展EJBObject。

　　大量使用缺省设置。比如，有状态会话Bean中的方法ejbActivate()和ejbPassivate()，如果不改动其缺省实现，则不需要定义之，除非开发人员想覆盖缺省实现，才需要定义这两个方法。

　　推荐使用依赖注入(Dependency Injection)，通过@EJB和@Resource等注释直接注入需要引用的对象，这种IoC（Inversion of Control）的思想大大简化了编程。

• EJB 3支持Java EE 5规范中的注释(annotation)，用户不需要定义部署描述符ejb-jar.xml。
• 无需Home接口，当然也可以定义Home接口以便于跟旧规范进行交互。
• EJB 3的好处和优势并不是本文的重点，所以这里就不一一历数了。想详细了解EJB 3的新特性。

　　EJB 3.0 FP支持EJB 3应用，同时向后兼容，支持EJB 2.1，也支持EJB 3和EJB 2.1的混合应用。WAS 6.1上的EJB 2.1应用不需要做任何改动，就可以被成功移植到EJB 3.0 FP上，这一点仅仅通过Augment当前WAS 6.1的概要文件到EJB 3.0 FP就能做到。本文主要介绍EJB 3应用从JBoss移植到EJB 3.0 FP时的注意事项，各软件提供商对EJB 3规范的实现方式和用法稍有不同，比如：JNDI绑定和命名规则、persistence.xml文件中的属性定义、EJB及资源的引用和依赖注入等，所以EJB 3应用从JBoss移植到EJB 3.0 FP时可能需要改动。当然，有些部分，比如拦截器(Interceptor)、事务、应用程序事务 (Application Transaction) 等，用法大致相同，基本不需要改动。

　　移植时应关注的几个最佳实践

　　本节主要介绍移植时应重点关注的JBoss和EJB 3.0 FP的几点不同，并提供了相应的最佳实践。

　　JNDI绑定和命名规则

　　EJB 3.0 FP中的JNDI绑定和命名规则旨在能够方便地与其他应用服务器的命名规则相互移植，尽管如此，还是略有不同。

　　JBoss的JNDI绑定和命名规则

　　JBoss有以下两种绑定规则：

　　缺省绑定

　　缺省情况下，会话Bean的JNDI绑定名称是 :

以下是引用片段： * local接口：<ejbName>/local  * remote接口：<ejbName>/remote

　　当EJB被部署到某个ear中后，缺省绑定名称中会以ear包的名称作为前缀。比如，ear文件是test.ear时，EJB的绑定名称是：

以下是引用片段： * local接口：test/<ejbName>/local  * remote接口：test/<ejbName>/remote

　　用户自定义的绑定

　　Jboss中，用户可以通过@LocalBinding或@RemoteBinding为某个EJB自定义JNDI绑定名称。注意：@LocalBinding和@RemoteBinding是JBoss自提供的扩展注释，而非EJB 3规范的标准注释。

　　EJB 3.0 FP的缺省绑定和命名规则

　　EJB 3.0 FP中，针对EJB提供两种命名空间(namespace)：JVM范围的ejblocal: 命名空间和全局JNDI命名空间。Local接口和Local Home接口（如果有的话）必须绑定到ejblocal: 命名空间，可被同一应用服务器进程内的其他应用访问得到。Remote 接口和 Home 接口（如果有的话）必须绑定到全局 JNDI 命名空间，从任何地方都能访问之，包括远程客户端或其他应用服务器进程。

　　ejblocal: 命名空间和全局JNDI命名空间是完全分离和独立的。举例来说，绑定在ejblocal命名空间的Local接口“ejblocal:HelloWorld”跟绑定在全局JNDI命名空间的Remote接口”HelloWorld”完全不同。

　　EJB 3.0 FP中，EJB容器为每个EJB业务接口 (Business Interface) 分配缺省的JNDI绑定名称，所以用户无需为每个EJB业务接口显式地定义JNDI绑定名称。如果不显式地定义绑定名称，EJB 容器会按照以下规则分配绑定名称，这跟以往WebSphere对EJB的支持稍有不同。

　　EJB容器为每EJB的业务接口分配两种缺省的绑定：短缺省绑定（Short Default Binding）和长缺省绑定(Long Default Binding)。短缺省绑定只引用接口的完整类路径及名称（package.qualified.interface，如com.ibm.ejb3.test.HelloWorld），而长缺省绑定用企业Bean的component-id作为前缀，由#跟接口的完整类路径及名称一起拼接而成。具体规则如下：

　　短缺省绑定：

• 　　Local接口ejblocal:<package.qualified.interface>
• 　　Remote接口<package.qualified.interface>

　　长缺省绑定：

• 　　Local接口ejblocal:<component-id>#<package.qualified.interface>
• 　　Remote接口ejb/<component-id>#<package.qualified.interface>

　　其中，缺省的component-id由应用名称、EJB模块名称和EJB的Bean名组成，形如：< 应用名称 >/<EJB 模块名称 >/<EJB 的 Bean 名 >，例如：test.ear/myEJB.jar/HelloWorldBean。用户还可以自定义 component-id，覆盖其缺省的component-id。此外，Remote接口的长缺省绑定被放在全局JNDI命名空间的ejb上下文中。

　　EJB 3.0 FP的自定义绑定和命名规则

　　用户可以在META-INF/ibm-ejb-jar-bnd.xml文件中为某个EJB定义<simple-binding-name>或<component-id>来自定义JNDI绑定，以覆盖其缺省绑定。

　　<simple-binding-name>是为EJB指定接口绑定的简易做法，适用于EJB 3.0的业务接口或者EJB 3.0以前的local home或remote home接口。如果接口是local的，则绑定位于ejblocal: 命名空间，如果接口是 remote 的，则绑定位于应用服务器的全局JNDI命名空间的根上下文。

  注意：<simple-binding-name>不能跟<local-home-binding-name>、<remote-home-binding-name>或<interface>一起使用，也不建议将其用于实现多个业务接口的EJB。如果非要将其用于实现多个接口的EJB，为避免二义性，EJB容器会自动在simple-binding-name后追加“#<package.qualified.interface.name>”来区分该EJB的各个接口。但这样做并不是最佳实践，会增加EJB容器的负担，所以应尽量避免，不用 simple-binding-name，而用<interface>为每个接口单独定义绑定。

　　<component-id>可单独使用，或者跟<interface class=… binding-name=…>一起联合使用，当联合使用时，那些被显式定义了绑定的接口使用这些自定义的值：<component-id>#<binding-name>，而那些未被显式指定绑定的接口，将会使用用户定义的<component-id>和缺省的<package.qualified.interface>，即 <component-id>#<package.qualified.interface>。

　　注意：<component-id>不能与<simple-binding-name> 一起使用，因为<simple-binding-name>应用于当前EJB的所有接口，也就是说，用了<simple-binding-name>后，所有接口都不能用缺省绑定了。而<component-id>只是替换了长缺省绑定中#以前的部分。