关于Java组件开发:一个概念框架(组图)

我先介绍几个在构建和设计解决方案来适应商业活动中的持续变化时需要注意的商业场景:

·公司需要将其文件仓库从文档文件转成网络文件

·公司需要更换其安全提供商

·因为经济情况的巨大的改变保险公司必须扩展其保险流程政策到更大范围

一样东西是很确定的需求更改就像商业和技术一样快速改变但是对于所有改变无论其大小我们都需要抛弃原来整个系统重新开始么？这是不必要的—架构和设计解决方案时加入少许考虑好的策略以及最优方法可以适应现有的体系结构的变更而不需要太多争辩

在面向对象编程以及分布式对象技术中组件是类和接口的集合通过可重用的外部API来满足需求（功能性的以及非功能性的）组件应该可以在分布式网络环境运行来形成网络程序基于组件的设计和开发对于遵循面向对象分析与设计（OOAD）的方法学的专家并不是新的话题

本文的目的是根据java的最优方法和最初开始一步一步地达到通用的概念模型来开发java组件本文面向的读者需要具有JavaUML以及Java/JEE设计模式的知识这篇文章主要描述的范围是

·组件的基本性质

·如何利用Java设计最优方法（设计模式）来实现这些Java组件设计的基本性质并且形成一个概念上的基本组件开发框架 这个框架将来可以方便地用于任何组件开发中的

组件的基本性质

·为了让其他组件可以与之相互作用组件必须有服务接口（API）

·组件必须有合适的生命周期机制（start stop initialize等等）

·组件必须可以配置

·组件只有一个实例在企业程序中运行

·配置的改变应该是动态的（在运行中）

·组件必须有合适的第三方软件融入的机制

·组件必须有合适的处理错误机制

如何实现基本的组件性质

组件必须有服务接口（API）

无论我们是在一个类还是几个类中写行到行的代码最终劳动成果（类或者类的结合）提供一些基本的高级的服务返回去想想我们甚至可以在实现他们之前定义那些我们想要达到的基本的高级的服务

让我们举个来自保险界的例子保险商在他每天做了以下的工作

·检查保险申请

·收集并评估背景信息

·根据公司现有的规则计算保险金

·从其他部门收集信息以及各种各样的报告（医学等等）

·准备相关的政策

现在我们如果想写一个保险商的商业组件我们必须有如图的服务接口以及其实现

当其他组件请求保险商组件的服务时并不需要考虑组件内部的操作封装其商业逻辑让组件更易维护及扩展

服务组件将有一个主要的服务实现类（服务接口的实现）以及这个类使用助手类这个类是组件的一部分同时也可能使用其他的组件

在产品开发中我们也须有许多组件提供不同的服务例如在保险业我们有索取流程组件投保人服务组件以及其他更多组件所以我们必须有个机制来在企业解决方案中注册这些服务组件使其可以根据企业的特殊需要采用或者中止这些服务

下面是XML结构的例子它可以自动处理服务注册的流程

<Services>

<Service>

<Serviceid>S</Serviceid>

<ServiceName>UnderwriterService</ServiceName>

<ServiceImplClass>

serviceUnderWriterServiceImpl

</ServiceImplClass>

</Service>

<Service>

<ServiceId>S</ServiceId>

<Servicename>PolicyHolderService</ServiceName>

<ServiceImplClass>

servicePolicyHolderServiceImpl

</ServiceImplClass>

</Service></Services>

组件应该具有合适的生命周期机制

组件也需要一个在它的生命周期内置的可见的独立的机制所以它可以根据需要被开始和中止ComponentControllerFactory（组件控制工厂）是singleton因为其只需要一个实例这个工厂负责根据配置内容为不同的提供商创建类的实例ComponentControllerFactory扮演双重角色首先其通过其init()reload()等等方法来管理组件的生命周期（这就是为什么它是一个工厂）图显示其方法

组件的生命周期方法是:

·doStart(): 开始组件

():帮助其从XML配置文件中取得配置对象负责创建适当的类的实例

·doStop():停止组件

·reload():如果当组件已经开始但XML配置文件发生更改这个方法将重新读取XML配置文件并重启逐渐

·getInstance():返回ComponentControllerFactory类的实例

一个组件应该是可配置的

通常每个组件有自己的可配置的不经常改变的参数例如假设我们需要写一个缓存组件它需要每小时从数据库取得半静态的数据来刷新本身状态更新的时间应该在配置文件中设置那样我们可以不更改源代码来更改参数的值

下面是关于logger组件的XML配置文件的例子专用于管理企业程序各个层次的logging

<LoggingServiceProvider>

<Provider>

<ProviderName>Apache</ProviderName>

<AdapterImpl>integrationadapterLogjAdapter

</AdapterImpl>

<Enable>true</Enable>

</Provider>

<Provider>

<ProviderName>WebLogic</ProviderName>

<AdapterImpl>integrationadapterWebLogicAdapter

</AdapterImpl>

<Enable>false</Enable>

</Provider></LoggingServiceProvider>

在企业应用中组件只有一个实例在运行

一个组件应该有且只有一个实例在运行而Singleton设计模式是合适的选择来保证在JVM中只有一个实例但是当这种模式在单一JVM情形下可行但是在多JVM情形下就有问题但是由于配置信息在组件开始时载入而不需要改变并处理所有静态信息用Singleton设计模式依然可行

我们假设组件可以在单JVM情况下可行ComponentControllerFactory将会如图那样

Singleton控制工厂提供的方法是

·getXXXService():方法返回在XML文件中定义的服务提供的实现类

·getXXXAdapter():方法返回在XML文件中定义适配实现类

配置文件的更改应该是动态的

如果组件是不可变的每串代码应该有与singleton实例同样的拷贝但是如果它是不是不变得我们需要改变时配置文件需要动态改变

有两种可能的情况但动态配置文件更改

·单一JVM情况

·多JVM情况

单一JVM情况

如果程序在单一JVM中运行事情就简单得多了我们已经知道SingletonControllerFactory通常在JVM中有一个实例所以任何时候配置文件发生任何改变将需要根据一些通知机制轮流载入java串行的配置对象来重新载入工厂对象这是基于ObserverObservable模式并做两件事

·通过XMLizer（单独的组件）来读取和处理XML配置文件并载入Java配置对象

·监视XML配置文件可能发生的更改

图显示ConfigManager的方法

ConfigManager类当被Observable通知时扮演Observer角色其更新方法将会被调用Update()方法将会调用SingletonControllerFactory的reload()方法所以新创建的java对象将会从其配置信息中重新载入

ConfigurationChangeNotifier扮演Observable的角色并在XML配置文件发生更改时启动通知ConfigManger线程并将指出其内容上的改变图显示其关系

多JVM情况

在多JVM情况下事情就不会变得这样简单我们必须有

·需要机制在运行时来动态载入更改的XML配置文件而不关闭整个企业程序

·需要机制保证在群中只有一个实例在运行

结合RMI利用JNDI是一种选择来保证在集群环境中的多个节点中的特定的一个节点自由一个实例在运行RMI服务需要编写同时RMI stub要在RMI服务之外创建创建的RMI stub需要被绑定在程序服务器的JNDI树上这个对象将保持在container中container可以让对象在集群中都可以用到

为了处理这种情况我们需要引入ConfigManager它将会做一下任务

·创建需要可以