用 OSGi 应用程序开发和工作的最佳实践 （8）

look_w

14.  让容器担起重任（专用于 WebSphere Application Server）
使用容器服务来构建应用程序并提企业品质服务而不是编写代码来管理服务。
原因如下
应用程序程序员经常希望以一种健壮可信的方式解决复杂的问题，并希望信任业务服务，例如事务和托管的资源，来为他们提供他们想要的服务质量。然而，向容器提供这些服务的完全控制权通常有点勉强，这无疑有损灵活性并失去控制。结果是许多应用程序选择管理自己的资源和周期。
控制反转，特别是依赖注入，是极为强大的简化应用程序开发工具，但它们依赖一个事实：容器能负责周期和资源管理。向  Blueprint bean 中的所有方法应用声明事务需要一行 XML，然而在每个方法中需要多行代码来在应用程序中完成同样的结果。类似地，对于资源管理，使用一个 Blueprint 资源引用可以将资源直接注入应用程序，也可以使其可以使用安全证书进行配置，以至于资源没有必要在应用程序中提供。如果一个开发人员选择定位自己的资源，容器就没有机会验证应用程序，因此证书被存储在应用程序中，而且，如果证书过期应用程序必须被更改。
示例
bundle 提供一个基于 JPA 的数据访问服务，但是不使用任何容器服务。它必须手工管理事务、EntityManager 周期和服务存储库。这将需要大约 100 行代码。需要多个 try/finally 块整理资源。客户端必须使用 OSGi API 来查看服务，这需要更多的周期管理和 try/finally 块。由于不使用 Blueprint 注册和使用服务，应用程序也必须手工处理服务不可用的错误案例。这也不是自动基于服务配置的。
通过使用声明性事务、Blueprint 和 管理 JPA，应用程序在大小上有所减少，减少了数百行复杂的周期和错误管理代码。这也减少了应用程序潜在缺陷的数量。这个应用程序，以及将来所有使用数据访问服务的应用程序，都可以利用基于服务的依赖配置优势。
结束语本文描述了构建 OSGi bundle 和 WebSphere Application Server OSGi 应用程序来实现 bundle 之间的高聚合和松耦合的最佳实践。通过采用这些最佳实践，您可以使用 Feature Pack for OSGi 应用程序和 JPA 2.0 来创建更加可维护和可扩展的应用程序，这些应用程序所用的是运行在 WebSphere Application Server V7 中的技术。