weidagang2046的专栏

　　EJB 3.0草案声明中允许资源经由@Resource注解来声明（这一决定定义在草案普通注解声明中）并且被容器注入进你的EJB。依赖性注入是一项技术-使用这种技术，一个对象外部的实体而不是显式地为该对象所创建的实体能够提供（注入）一个对象的依赖性。它有时被描述为好莱坞原则-这开玩笑似地意味着"不要给我们打电话，我们会给你打电话的"。

　　以TravelAgencyServiceImpl类为例-这个类为了持续性存储一些数据需要找到一个IFlightDAO接口的实现。传统地，这是经由一个工厂、singleton、服务定位器或一些另外的定制解决方案来实现的。其中，一个可能的解决方案看上去如下所示:

public class TravelAgencyServiceImpl implements ITravelAgencyService
{
　public IFlightDAO flightDAO;
　public TravelAgencyServiceImpl()
　{ flightDAO = FlightDAOFactory.getInstance().getFlightDAO(); }
　public void bookTrip(long outboundFlightID, long returnFlightID, int seats)
　throws InsufficientSeatsException
　{
　　reserveSeats(outboundFlightID, seats);
　　reserveSeats(returnFlightID, seats);
　}
}

　　你已看到，这个实现包含创建一个特定的工厂类-它很可能读取存储在某处的配置信息以了解要创建IFlightDAO的实现方式。如果不是让服务显式地创建它的由容器所注入的依赖性，那么配置细节和对象创建将被代理到容器上。这允许一个应用程序中的组件能够被容易地连接到一起-用不同的配置并且消除大量老式的singleton和工厂代码。

　　该类的一个实现-它依赖于一个用JSR 250资源注解所声明的IFlightDAO的实现-可能看上去如下所示：

public class TravelAgencyServiceImpl implements ITravelAgencyService
{
　@Resource(name = "flightDAO")
　public IFlightDAO flightDAO;
　public void bookTrip(long outboundFlightID, long returnFlightID, int seats)
　throws InsufficientSeatsException
　{
　　reserveSeats(outboundFlightID, seats);
　　reserveSeats(returnFlightID, seats);
　}
}

　　在这种情况下，容器将把一个命名为"flightDAO"的资源的正确实现提供给服务类。但是，如果你现在就想利用资源注入，而不是等待EJB 3.0发行版，又该如何呢？好，你可以采用一种轻量级的容器-它能够提供例如Spring或Pico Container的依赖性注入。然而，当前我还不了解存在一个轻量级的容器-它能够使用JSR 250资源注解以指定注入要求(尽管我非常盼望在这一方面出现一些)。

　　一种解决方案是使用方面来实现依赖性注入。如果你为此使用@Resource注解，那么你的实现将与EJB 3.0方式一致并且向前兼容EJB 3.0实现-而实现这并不是很困难的事情。下列列表显示用AspectJ创建的一个方面-它注入用@Resource注解所注解的字段:

@Aspect
public class InjectionAspect
{
　private DependencyManager manager = new DependencyManager();
　@Before("get(@Resource * *.*)")
　public void beforeFieldAccesses(JoinPoint thisJoinPoint)
　throws IllegalArgumentException, IllegalAccessException
　{
　　FieldSignature signature = (FieldSignature) thisJoinPoint.getSignature();
　　Resource injectAnnotation = signature.getField().getAnnotation(Resource.class);
　　Object dependency = manager.resolveDependency(signature.getFieldType(),injectAnnotation.name());
　　signature.getField().set(thisJoinPoint.getThis(), dependency);
　}
}

　　这个简单方面所做的全部是，从一个属性文件(这个逻辑被封装在DependencyManager对象中)查询实现类并且在存取字段之前把它注入到用@Resource注解所注解的字段中。显然，这种实现不是完整的，但是它确实说明了你可以怎样以一种JSR 250兼容方式且不需采用EJB来提供资源注入。
四、 安全性

　　除了资源注入外，JSR 250和EJB 3.0还提供经由注解的元数据安全表示。javax.annotation.security包定义了五个注解-RunAs，RolesAllowed，PermitAll，DenyAll和RolesReferenced-所有这些都能应用到方法上来定义安全要求。例如，如果你想要声明上面列出的bookFlight方法仅能为具有"user"角色的调用者所执行，那么你可以用如下的安全约束来注解这个方法：

public class TravelAgencyServiceImpl implements ITravelAgencyService
{
　@Resource(name = "flightDAO")
　public IFlightDAO flightDAO;
　@RolesAllowed("user")
　public void bookTrip(long outboundFlightID, long returnFlightID, int seats)
　throws InsufficientSeatsException
　{
　　reserveSeats(outboundFlightID, seats);
　　reserveSeats(returnFlightID, seats);
　}
}

　　这个注解将指出由容器来负责保证只有指定角色的调用者才能执行这个方法。因此现在我将展示另一个简单的方面-它将进一步加强在该应用程序上的安全约束：

@Aspect
public class SecurityAspect
{
　@Around("execution(@javax.annotation.security.RolesAllowed * *.*(..))")
　public Object aroundSecuredMethods(ProceedingJoinPoint thisJoinPoint)
　throws Throwable
　{
　　boolean callerAuthorized = false;
　　RolesAllowed rolesAllowed = rolesAllowedForJoinPoint(thisJoinPoint);
　　for (String role : rolesAllowed.value())
　　{
　　　if (callerInRole(role))
　　　{ callerAuthorized = true; }
　　}
　　if (callerAuthorized)
　　{ return thisJoinPoint.proceed(); }
　　else
　　{
　　　throw new RuntimeException("Caller not authorized to perform specified function");
　　}
　}
　private RolesAllowed rolesAllowedForJoinPoint(ProceedingJoinPoint thisJoinPoint)
　{
　　MethodSignature methodSignature = (MethodSignature) thisJoinPoint.getSignature();
　　Method targetMethod = methodSignature.getMethod();
　　return targetMethod.getAnnotation(RolesAllowed.class);
　}
　private boolean callerInRole(String role)
　{ ... }
}

　　这个方面包含了所有方法的执行-通过核实该调用者是在注解中所指定的角色之一，用@RolesAllowed注解来注解并且保证调用者被授权调用该方法。当然你还能代之以任何你喜欢的算法来授权用户并且检索他/她的角色，例如JAAS或一个定制的解决方案。在本示例程序中，为方便起见，我选择代理到servlet容器。
五、 事务

　　事务成为企业开发的一个重要部分-因为它们有助于在一个并发的环境中的数据集成。从一个高层次上看，事务可以通过多种或者是完整的或者是都不完整的操作来保证这一点。

　　不象针对资源注入和安全的注解，针对事务的注解是特定于EJB 3.0的并且没有在JSR 250普通注解中定义。EJB 3.0定义了两个与事务相联系的注解：TransactionManagement和TransactionAttribute。该TransactionManager注解指定事务是由容器所管理还是为bean所管理的。在EJB 3中，如果这个注解没被指定，那么将使用容器所管理的事务。TransactionAttribute注解用于指定方法的事务传播级别。有效值-包括强制的、要求的、要求新的、支持的、不支持的和从不支持的-用来定义是否要求一个已有事务或启动一个新的事务，等等。

　　因为bookFlight操作包含两步-订购一个外出航班和一个返回航班，所以，通过把它包装成一个事务，你能保证这项操作的一致性。通过使用EJB 3.0事务注解，这将看上去如下所示:

public class TravelAgencyServiceImpl implements ITravelAgencyService
{
　@Resource(name = "flightDAO")
　public IFlightDAO flightDAO;
　@RolesAllowed("user")
　@TransactionAttribute(TransactionAttributeType.REQUIRED)
　public void bookTrip(long outboundFlightID, long returnFlightID, int seats)
　throws InsufficientSeatsException
　{
　　reserveSeats(outboundFlightID, seats);
　　reserveSeats(returnFlightID, seats);
　}
}

　　并且你可以应用一个简单的方面来自动地界定事务边界:

@Aspect
public class TransactionAspect
{
　@Pointcut("execution(@javax.ejb.TransactionAttribute * *.*(..))")
　public void transactionalMethods(){}
　@Before("transactionalMethods()")
　public void beforeTransactionalMethods()
　{ HibernateUtil.beginTransaction(); }
　@AfterReturning("transactionalMethods()")
　public void afterReturningTransactionalMethods()
　{ HibernateUtil.commitTransaction(); }
　@AfterThrowing("transactionalMethods()")
　public void afterThrowingTransactionalMethods()
　{ HibernateUtil.rollbackTransaction(); }
}

　　这个实现基于这样的假设-Hibernate和无所不在的线程本地模式被用于管理Hibernate会话和事务对象；但是，任何其它适当的实现，例如基于JTA的实现，都能被代替使用。

　　六、 小结

　　通过使用EJB 3.0和JSR 250注解集，本文已经展示了例如资源管理、安全和事务等横切关注点是怎样被实现为方面的。当然，还有许多内容我们需进一步学习。首先要学的就是通过使用AspectJ的实现这些示例方面为模块化横切关注点所提供的蓝图。其次，我们已经看到了在如今正浮出水面的EJB 3.0声明背后的一些新思想和新概念。最后，我们还以戏剧性的方式看到了从EJB API中解耦我们的商业对象所必须要提供的自由。在这一点上，所有你想使TravelAgencyServiceImpl成为一个无状态会话要做的仅是添加一条最后的注解:

@Stateful
public class TravelAgencyServiceImpl implements ITravelAgencyService
{ ... }

　　最后，我非常希望这种自由地提供企业服务的方式会带来框架/容器工业界的竞争和革新。

from: http://www.7dspace.com/doc/21/2005-11-21/2005112107135764791_1.htm