首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

用 OSGi 应用程序开发和工作的最佳实践 (7)

用 OSGi 应用程序开发和工作的最佳实践 (7)

12. 使用持久 bundle 来共享您的持久性单元在应用程序中使用 JPA 时,将 bundle 包装成一个 OSGi 持久性 bundle。如果您的客户不直接使用 EntityManagerFactory,在 OSGi 服务存储库中公开一个数据访问服务,而不是从持久性 bundle 导出实体类。
原因如下
WebSphere Application Server OSGi 应用程序特性支持符合OSGi JPA 服务规范的 OSGi 持久性 bundle。通过在一个持久性 bundle 中包装 JPA 管理的类和 persistence.xml,用易共享的 JPA 资源(在 WebSphere Application Server OSGi 运行时使用的)和不可管理的 JPA Service 实现创建一个可重用模块是有可能的。持久 bundle 也可被大量基于持久性客户端的 OSGi 共享,但不包括持久性客户端代码,这两个都是高度聚合和易于重用的。记得指定 Meta-Persistence bundle 清单头部,持久性描述符可以在包内给出任意路径。
如果一个持久性单元被包装在一个遗留 WAR 中,它应该被打开作为一个单独的 OSGi bundle。在 WAR 中的持久性单元由 Java EE 容器管理,并且在 OSGi 框架内不能共享。同样的,不能被 OSGi 应用程序中的其他 OSGi bundle 所用。从 WAR 中删除持久性单元不是可能的,记住它是不能通过 Blueprint 容器或 OSGi 服务存储库访问的。
从其他应用程序代码中分离持久性 bundle 的另一个原因由  来解释。如果几个应用程序需要在一个数据库中访问数据,重用同一个实体映射是有必要的。这有助于防止数据库中的数据损坏,因为两个应用程序共享同一数据映射,而只有一个 bundle 需要针对未来的模式更改而更新。如果持久性单元不能包装在一个较大的 bundle 中,那么实体将不再易于多个应用程序共享,需要代码副本和维护成本。
13. 充分利用提供的组件模型(专用于 WebSphere Application Server)
在 OSGi、WebSphere Application Server OSGi Applications 功能和 SCA 之间提供一系列不断增长的粗粒度组件模型:
  • 使用 Blueprint 在 OSGi bundle 中定义细粒度组件。
  • 将 OSGi 应用程序定义为 bundle 组合,这些 bundle 提供一个特定应用程序功能。
  • 使用 SCA 公开服务,从一个 OSGi 应用程序到另一个,并向常规 Java EE 应用程序提供服务。
原因如下
来管理细粒度组件以及与其他 OSGi Bundle 的交互。(通常很小)并使 您的依赖项保持松耦合性。高聚合和松耦合的原则继续适用,因为 bundle 被分组到业务 bundle 应用程序。
OSGi 应用程序可以认为同传统 Java EE 企业级应用程序大致相同。在组装应用程序时,记住 WebSphere Application Serverkeep 将 Application-Content 列出的 bundle 部署到自己的独立的框架。所有应用程序的依赖 bundle 被部署到一个共享 bundle 空间。因此鼓励将通用代码库和服务分解到共享的依赖 bundle。这节省了内存,增加了可重用性,并有助于系统的管理。在一个给定 OSGi 应用程序 Application-Content 中列出的 bundle 仅由该应用程序中独有的持久性、业务和显示逻辑组成。
有两个方法可以将工作深入到 OSGi 应用程序,第一个是通过 HTTP 深入到 WAR,第二个是调用一个 Application-ExportService 头部列出的服务;这么做需要使用 SCA。
SCA 是最粗粒度的可用组件模型,它提供一个分布式编程模型并强迫使用值传递语义。使用 SCA 从一个 OSGi 应用程序向另一个公开服务,并在常规 Java EE 程序之间提供服务。Rational Application Developer 8 提供工具支持构建和集成 OSGi 应用程序作为 SAC 组件。
返回列表