使用 Equinox 开发 OSGi 应用程序（五）

探讨 OSGi 应用架构

设计思路

到目前为止，我们已经涉及到了 OSGi 的诸多方面，那么在实际进行应用程序的架构设计的时候我们要考虑哪些因素呢，这一节我们详细讨论一下这个问题。

应用架构的设计应该充分考虑到可靠性、可扩展性、可维护性等因素，使用了 OSGi 框架后，我们可以更加容易的实现系统分层，组件化的设计方式。通过使用 HTTP 服务我们可以设计出一个基于 HTTP 服务的程序维护平台。架构如下：

图 28. 基于 HTTP 服务的程序维护平台

说明：

1. 通用第三方库层：这一层包括了常用的第三方库，例如 apache commons，jfreechart，xml 包等等，这一层需要将这些包全部 export 出去，这样上层就可以直接通过 require bundle 的方式使用这些包。
2. 业务模型定义层：这一层依赖于（require-bundle）通用第三方库层，定义了应用的业务模型，例如各种 JavaBeans，也可以在这一层提供额外的应用统一配置服务，即为上层应用提供配置文件的管理服务。
3. 业务逻辑实现层：这一层依赖于（require-bundle）通用第三方库层，还依赖于 (import package) 业务模型定义层提供的业务模型，定义了应用的业务逻辑，这一层可以细分为：
   1. DAO（Database Access Object）服务层：即为上层应用提供数据库存取服务的层，其 export 出去的接口全部都是和数据库操作相关的；
   2. Service 层：为 UI 层提供的业务逻辑的封装层，这样 UI 层只需要执行 service 层的接口即可，可以将更多的精力放在 UI 的设计；
4. 展现维护层：这一层依赖于（require-bundle）通用第三方库层，和下面各层提供的管理服务接口，基于 HTTP 服务的方式提供应用的维护，例如配置文件的在线修改、服务的管理，bundle 的管理，日志的管理，内存的管理等等，这些都可以以“ RUNTIME ”的方式展现，管理员或者维护人员操作的就是 Equinox 运行环境。还可以实现大部分的操作不需要重启 JVM，这一点类似于 JMX。
5. 事件服务：事件服务层是 OSGi 框架提供的标准服务之一，为除了通用第三方库层以外的各层提供事件服务，包括同步、异步的通知各种事件、发布各种事件等。通过事件服务，可以实现各层之间的联动。

这种架构的优势在于：

1. 各层只用关心自己的业务，例如通用第三方库层只需要 export，其它事情不用管，它也没有自己的 Activator 类，业务模型定义层只需要关心业务模型，而不必关心业务的流程，业务逻辑层中的 DAO 层则只需要关心数据库操作，service 层则负责组合业务流程。各司其职，这样才能精于自己的模块；
2. 较好的可维护性：最上层的维护展现层，为管理员提供了一个 OSGi 应用的管理窗口，提供在线重启服务、管理各个 bundle 和服务的能力，提供了类似于 JMX 的能力；
3. 统一的事件管理框架：为各层定义了统一的事件管理接口，基于 TOPIC 方式的事件监听机制能够有效的过滤事件，而且提供了异步、同步两种方式对事件进行处理，可以说有相当大的灵活性。

 

回页首

可维护性的考虑

一般的应用架构可能都比较多的考虑可靠性、灵活性、可扩展性等，对可维护性却没有提供太多的关注，使用 OSGi 后，将对可维护性提供类似于 JMX 的支持，当然这不需要您实现 MBEAN，就像上述介绍的架构设计，我们在最上层可以设计一个基于 HTTP 的维护层，这样，提供了一个小的 Web 控制台，供管理员进行维护。

维护的方面包括：

1. 系统维护
   1. Bundle 的管理：包括每个 bundle 的更新、停止、启动；
   2. 服务的管理：包括运行环境注册的服务的列表、停止、启动；
   3. 系统所有服务的重启、停止、启动；
2. 系统状态的监控
   1. 对各个业务层提供的服务的状态进行实时监视、统计；
   2. 对各个业务层提供服务的状态进行控制，通过 OSGi 事件的方式进行通知；
3. 系统日志的管理
   1. 对系统中各个层的日志进行统一列表、查看；
   2. 对系统中所有操作进行统一日志记录、管理；
4. 配置管理
   1. 对各个业务模块需要的配置文件进行统一展示；
   2. 对各个业务模块提供的配置文件提供在线编辑、提交功能；
   3. 对修改后的配置文件提供实时上线的功能；
5. 其它
   1. 维护系统的登录、登出；
   2. 维护系统自审计；
   3. 维护系统权限控制；