Java组件开发的一个概念框架

1、Java组件开发的一个概念框架我先介绍几个在构建和设计解决方案来适应商业活动 中的持续变化时需要注意的商业场景 : 公司需要将其文件仓库从文档文件转成网络文件。 公司需要更换其安全提供商。 因为经济情况的巨大的改变，保险公司必须扩展其保 险流程政策到更大范围。一样东西是很确定的，需求更改就 像商业和技术一样快速改变。但是对于所有改变，无论其大 小，我们都需要抛弃原来整个系统重新开始么？这是不必要 的架构和设计解决方案时加入少许考虑，好的策略以及最 优方法可以适应现有的体系结构的变更而不需要太多争辩。 在面向对象编程以及分布式对象技术中，组件是类和接口的 集合，通过可重用的外部 API 来满足需

2、求（功能性的以及非 功能性的）。组件应该可以在分布式网络环境运行来形成网 络程序。基于组件的设计和开发对于遵循面向对象分析与设 计（ OOAD ）的方法学的专家并不是新的话题。本文的目的 是根据 java 的最优方法和最初开始一步一步地达到通用的概 念模型来开发 java 组件。本文面向的读者需要具有 Java， UML以及Java/J2EE设计模式的知识。这篇文章主要描述的 范围是： 组件的基本性质。 如何利用 Java 设计最优方法 （设计模式） 来实现这些 Java组件设计的基本性质，并且形成一个概念上的基本组件 开发框架 , 这个框架将来可以方便地用于任何组件开发中 的。组件的基本性质

3、 为了让其他组件可以与之相互作用，组件必须有服务 接口（ API ）。 组件必须有合适的生命周期机制（ start, stop, initialize 组件必须可以配置。 组件只有一个实例在企业程序中运行。 配置的改变应该是动态的（在运行中） 。 组件必须有合适的第三方软件融入的机制。 组件必须有合适的处理错误机制如何实现基本的组件性质组件必须有服务接口（ API ）无论我们是在一个类还是几个 类中写 100 行到 1000 行的代码，最终劳动成果（类或者类 的结合）提供一些基本的高级的服务。返回去想想，我们甚 至可以在实现他们之前定义那些我们想要达到的基本的高 级的服务。让我们举个来自保险界

4、的例子，保险商在他每天 做了以下的工作： 检查保险申请。 收集并评估背景信息。 根据公司现有的规则计算保险金 从其他部门收集信息以及各种各样的报告（医学等 等）。 准备相关的政策。现在我们如果想写一个保险商的商 业组件， 我们必须有如图 1 的服务接口以及其实现： Figure 1. Underwriter service interfac 当其他组件请求保险商组件的服 务时，并不需要考虑组件内部的操作。封装其商业逻辑让组 件更易维护及扩展。服务组件将有一个主要的服务实现类 （服务接口的实现）以及这个类使用助手类，这个类是组件 的一部分，同时也可能使用其他的组件在产品开发中，我们 也须有许多组

5、件提供不同的服务。例如，在保险业，我们有 索取流程组件 ， 投保人服务组件 以及其他更多组件。所以我们必须有个机制来在企 业解决方案中注册这些服务组件，使其可以根据企业的特殊 需要采用或者中止这些服务。下面是 XML 结构的例子，它 可以自动处理服务注册的流程。<Services><Service><Serviceid>S001</Serviceid><ServiceName>UnderwriterService</ServiceName><ServiceImplClass>.service.Un

6、derWriterServiceImpl</Service><Service><ServiceId>S002</ServiceId><Servicename>PolicyHolderService</ServiceName><ServiceImplClass> .service.PolicyHolderServiceImpl </ServiceImplClass></Service></Services> 组件应该具有合适的生命周期机制 组件也需要一个在它的生命周

7、期内置的，可见的，独立的机 制，所以它可以根据需要被开始和中止。ComponentControllerFactory (组件控制工厂)是 singleton ， 因为其只需要一个实例。这个工厂负责根据配置内容为不同 的提供商创建类的实例。 ComponentControllerFactory 扮演双 重角色：首先其通过其 init(),reload() 等等方法来管理组件的 生命周期(这就是为什么它是一个 工厂 )， 图 2 显示其方法 Figure 2. Component controller factory 组件 的生命周期方法是 :doStart(): 开始组件(): 帮助其从 XML

8、 配置文件中取得配置对象，负责创建适当 的类的实例doStop(): 停止组件reload(): 如果当组件已经开始但 XML 配置文件发生 更改，这个方法将重新读取 XML 配置文件并重启逐渐。 getInstance(): 返回 ComponentControllerFactory 类的实 例一个组件应该是可配置的 通常，每个组件有自己的可配置的不经常改变的参数。 例如， 假设我们需要写一个缓存组件，它需要每小时从数据库取得 半静态的数据来刷新本身状态。更新的时间应该在配置文件 中设置，那样我们可以不更改源代码来更改参数的值。下面 是关于 logger 组件的 XML 配置文件的例子，专用

9、于管理企 业程序各个层次的 logging 。<LoggingServiceProvider><Provider><ProviderName>Apache</ProviderName><AdapterImpl>egration.adapter.Log4jAdapter</AdapterImpl><Enable>true</Enable></Provider><ProviderName>WebLogic</ProviderName><Ad

10、apterImpl>egration.adapter.WebLogicAda pter</AdapterImpl> <Enable>false</Enable> </Provider></LoggingServiceProvider> 在企业应用中组件只有一个 实例在运行一个组件应该有且只有一个实例在运行， 而 Singleton 设计模 式是合适的选择来保证在 JVM 中只有一个实例。但是当这 种模式在单一 JVM 情形下可行，但是在多 JVM 情形下就有 问题。但是由于配置信息在组件开始时载入而不需要改

11、变并 处理所有静态信息， 用 Singleton 设计模式依然可行我们假设 组件可以在单 JVM 情况下可行， ComponentControllerFactory 将会如图 3 那样： Figure 3. Component controller factory in a single JVMSingleton 控制工厂提供的方法是 getXXXService(): 方法返回在 XML 文件中定义的服务 提供的实现类getXXXAdapter(): 方法返回在 XML 文件中定义适配实现类配置文件的更改应该是动态的如果组件是不可变的， 每串代码应该有与 singleton 实例同样的拷贝，

12、但是如果它是 不是不变得，我们需要改变时，配置文件需要动态改变。有 两种可能的情况但动态配置文件更改： 单一 JVM 情况 多 JVM 情况单一 JVM 情况如果程序在单一 JVM 中运行，事情就简单得多了。我们已 经知道， SingletonControllerFactory 通常在 JVM 中有一个实 例，所以任何时候配置文件发生任何改变，将需要根据一些 通知机制轮流载入 java 串行的配置对象来重新载入工厂对 象。这是基于 Observer-Observable 模式并做两件事： 通过 XMLizer (单独的组件)来读取和处理 XML 配 置文件并载入 Java 配置对象。 监视 X

13、ML 配置文件可能发生的更改。图 4 显示 ConfigManager 的方法： Figure 4. ConfigManager ConfigManager 类当被 Observable 通知时扮演 Observer 角色， 其更新方法将会被调用。 Update() 方法将会调用 SingletonControllerFactory 的 reload() 方法，所以新创建的 java 对象将会从其配置信息中重新载入。ConfigurationChangeNotifier 扮演 Observable 的角色并在 XML 配置文件发生更改时启动通知 ConfigManger 线程，并 将指出其内容

14、上的改变。图 5 显示其关系： Figure 5.ConfigurationChangeNotifier 多 JVM 情况在多 JVM 情况下， 事情就不会变得这样简单。我们必须有 需要机制在运行时来动态载入更改的 XML 配置文件 而不关闭整个企业程序。 需要机制保证在群中只有一个实例在运行。 结合 RMI 利用 JNDI 是一种选择来保证在集群环境中的多个节点中的 特定的一个节点自由一个实例在运行。 RMI 服务需要编写， 同时 RMI stub 要在 RMI 服务之外创建。创建的 RMI stub 需 要被绑定在程序服务器的 JNDI 树上。这个对象将保持在 container 中， c

15、ontainer 可以让对象在集群中都可以用到。为 了处理这种情况，我们需要引入 ConfigManager ，它将会做 一下任务： 创建需要可以动态改变的 XML 配置文件。 创建来自 XML 文件的 java 串行文件。串行和非串行 化将会在不同的组件中完成。创建 RMI 服务，注册从 RMI 服务中创建的 RMI stub, 并通过 RMI 服务载入串行配置对象。 将 RMI stub 与集群环境中的 JNDI 树的任何节点绑 定。 创建通知系统， 其将重新绑定 RMI 服务并当 XML 文 件似乎发生变化时重新载入对象。 图 6 显示 RMI 服务的接口 以及其实现： Figure 6

16、. RMI service 在多 JVM 情况下，ConfigManager 如图 7： Figure 7. ConfigManager in a multiple-JVM scenarioConfigManagerMultipleJVM 类扮演 Observer 的角色。当他被 Observable 通知时，其 update 方法 将会被调用。通过 update()方法，rebindRMIService()方法将 会被调用，这样新创建的对象(通过最新的配置信息)将会 被重新载入。 SingletonControllFactory 将会为 RMI 服务扮演 wrapper 角色，返回合适的已配

17、置的对象。这种方法的会产 生问题， 因为只有一个实例， 所以只可以允许一个点的错误。 ConfigManager 组件需要更强壮来处理错误。但是同样有其 他的方法， 通过 MDB 和 JMS 在群众的不同节点同步缓存的 配置对象。 在这种情况下， 并不需要 RMI 服务。 下面是实现 这种方法的步骤： SingletonControllerFactory 通过配置对象初始化并开 始组件。ConfigManager 的 Observer-Observable 模型通过其通 知机制来跟踪 XML 配置文件的任何变更。当发现更改时， 他将公布消息到 JMS topic。 运行在集群环境中的每个群中的

18、 MDB 触发其 onMessage()方法，并载入更改的配置 Java对象。 组件应该 有合适的第三方软件整合机制 如果组件依赖第三方软件整合来建立服务， 第三方 API 不应 该直接在实现类中使用。最佳的策略是开发适配器并隔离第 三方软件调用和适配器的实现。图 8 显示调用 logger 组件的适配器的例子，演示了如何让其更方便的适应第三方APIs 。Figure 8. Application logger interface 利用 adapter 模式的优点 是更容易的和第三方软件 APIs 合并。此外，当这些 APIs 改 变时 ,适配实现需要改变， 而用此适配接口的服务将不需要改 变。通过 XML 配置文件从不同的适配器中选择是便利的， 就如上面这节介绍的那样。组件应该有合适的错误处理机制 每个组件应该有自己的异常处理类，它可以帮助捕捉适当的 异常。假设我们对于特定的即将使用的商业程序有单独的组 件来处理异常。 这个特定组