我先介绍几个在构建和设计解决方案来适应商业活动中的持续变化时需要注意的商业场景:
公司需要将其文件仓库从文档文件转成网络文件。
公司需要更换其安全提供商。
因为经济情况的巨大的改变，保险公司必须扩展其保险流程政策到更大范围。
一样东西是很确定的，需求更改就像商业和技术一样快速改变。但是对于所有改变，无论其大小，我们都需要抛弃原来整个系统重新开始么？这是不必要的?架构和设计解决方案时加入少许考虑，好的策略以及最优方法可以适应现有的体系结构的变更而不需要太多争辩。
在面向对象编程以及分布式对象技术中，组件是类和接口的集合，通过可重用的外部API来满足需求（功能性的以及非功能性的）。组件应该可以在分布式网络环境运行来形成网络程序。基于组件的设计和开发对于遵循面向对象分析与设计（OOAD）的方法学的专家并不是新的话题。
本文的目的是根据Java的最优方法和最初开始一步一步地达到通用的概念模型来开发Java组件。本文面向的读者需要具有Java，UML以及Java/J2EE设计模式的知识。这篇文章主要描述的范围是：
组件的基本性质。
如何利用Java设计最优方法（设计模式）来实现这些Java组件设计的基本性质，并且形成一个概念上的基本组件开发框架, 这个框架将来可以方便地用于任何组件开发中的。
组件的基本性质
为了让其他组件可以与之相互作用，组件必须有服务接口（API）。
组件必须有合适的生命周期机制（start, stop, initialize等等）
组件必须可以配置。
组件只有一个实例在企业程序中运行。
配置的改变应该是动态的（在运行中）。
组件必须有合适的第三方软件融入的机制。
组件必须有合适的处理错误机制
如何实现基本的组件性质
组件必须有服务接口（API）
无论我们是在一个类还是几个类中写100行到1000行的代码，最终劳动成果（类或者类的结合）提供一些基本的高级的服务。返回去想想，我们甚至可以在实现他们之前定义那些我们想要达到的基本的高级的服务。
让我们举个来自保险界的例子，保险商在他每天做了以下的工作：
检查保险申请。
收集并评估背景信息。
根据公司现有的规则计算保险金
从其他部门收集信息以及各种各样的报告（医学等等）。
准备相关的政策。
现在我们如果想写一个保险商的商业组件，当其他组件请求保险商组件的服务时，并不需要考虑组件内部的操作。封装其商业逻辑让组件更易维护及扩展。
服务组件将有一个主要的服务实现类（服务接口的实现）以及这个类使用助手类，这个类是组件的一部分，同时也可能使用其他的组件
在产品开发中，我们也须有许多组件提供不同的服务。例如，在保险业，我们有“索取流程组件”，“投保人服务组件”以及其他更多组件。所以我们必须有个机制来在企业解决方案中注册这些服务组件，使其可以根据企业的特殊需要采用或者中止这些服务。
下面是XML结构的例子，它可以自动处理服务注册的流程。
组件应该具有合适的生命周期机制
组件也需要一个在它的生命周期内置的，可见的，独立的机制，所以它可以根据需要被开始和中止。ComponentControllerFactory（组件控制工厂）是singleton，因为其只需要一个实例。
这个工厂负责根据配置内容为不同的提供商创建类的实例。ComponentControllerFactory扮演双重角色：首先其通过其init(),reload()等等方法来管理组件的生命周期（这就是为什么它是一个“工厂”）
组件的生命周期方法是:
在企业应用中组件只有一个实例在运行
一个组件应该有且只有一个实例在运行，而Singleton设计模式是合适的选择来保证在JVM中只有一个实例。但是当这种模式在单一JVM情形下可行，但是在多JVM情形下就有问题。
但是由于配置信息在组件开始时载入而不需要改变并处理所有静态信息，用Singleton设计模式依然可行。
Singleton控制工厂提供的方法是
getXXXService():方法返回在XML文件中定义的服务提供的实现类
getXXXAdapter():方法返回在XML文件中定义适配实现类
配置文件的更改应该是动态的
如果组件是不可变的，每串代码应该有与singleton实例同样的拷贝，但是如果它是不是不变得，我们需要改变时，配置文件需要动态改变。
有两种可能的情况但动态配置文件更改：
单一JVM情况
多JVM情况
单一JVM情况
如果程序在单一JVM中运行，事情就简单得多了。我们已经知道，SingletonControllerFactory通常在JVM中有一个实例，所以任何时候配置文件发生任何改变，将需要根据一些通知机制轮流载入Java串行的配置对象来重新载入工厂对象。这是基于Observer-Observable模式并做两件事：
通过XMLizer（单独的组件）来读取和处理XML配置文件并载入Java配置对象。监视XML配置文件可能发生的更改。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，它将会做一下任务：
创建需要可以动态改变的XML配置文件。
创建来自XML文件的Java串行文件。串行和非串行化将会在不同的组件中完成。
创建RMI服务，注册从RMI服务中创建的RMI stub,并通过RMI服务载入串行配置对象。
将RMI stub与集群环境中的JNDI树的任何节点绑定。
创建通知系统，其将重新绑定RMI服务并当XML文件似乎发生变化时重新载入对象。
ConfigManagerMultipleJVM类扮演Observer的角色。当他被Observable通知时，其update方法将会被调用。通过update()方法，rebindRMIService()方法将会被调用，这样新创建的对象（通过最新的配置信息）将会被重新载入。
SingletonControllFactory将会为RMI服务扮演wrapper角色，返回合适的已配置的对象。这种方法的会产生问题，因为只有一个实例，所以只可以允许一个点的错误。ConfigManager组件需要更强壮来处理错误。
但是同样有其他的方法，通过MDB和JMS在群众的不同节点同步缓存的配置对象。在这种情况下，并不需要RMI服务。下面是实现这种方法的步骤：
SingletonControllerFactory通过配置对象初始化并开始组件。
ConfigManager的Observer-Observable模型通过其通知机制来跟踪XML配置文件的任何
变更。当发现更改时，他将公布消息到JMS topic。运行在集群环境中的每个群中的MDB触发其onMessage()方法，并载入更改的配置Java对象。
组件应该有合适的第三方软件整合机制
如果组件依赖第三方软件整合来建立服务，第三方API不应该直接在实现类中使用。最佳的策略是开发适配器并隔离第三方软件调用和适配器的实现。
利用adapter模式的优点是更容易的和第三方软件APIs合并。此外，当这些APIs改变时,适配实现需要改变，而用此适配接口的服务将不需要改变。通过XML配置文件从不同的适配器中选择是便利的，就如上面这节介绍的那样。
组件应该有合适的错误处理机制
每个组件应该有自己的异常处理类，它可以帮助捕捉适当的异常。假设我们对于特定的即将使用的商业程序有单独的组件来处理异常。这个特定组件异常类（Underwriter exception）将会使需要的服务脱离异常处理组件。
这个异常处理类是特定用于Underwriter服务并扩展基于企业程序的异常类。其工作就是掩盖在服务类中产生的异常并重新释放他。
结论
总的来说，以下是整合的基本步骤：
作为程序开始过程的一部分，ConfigManager键通过XMLizer（用于XML-to-Java对象转换的单独对象）来为不同的组件读取XML配置文件，并通过程序服务器节点的JNDI tree来绑定Java配置对象。
作为程序开始过程的一部，配置对象将会被读取，因此相关的provider/adapter/service需要被说明。如果配置文件发生更改，ConfigManager将读取更改后的XML文件并重新绑定配置对象。
组件将会重新载入配置对象并根据其最新更改来重新初始化。回到我们开始的地方，当你计划开发强壮的系统时组件框架将会有效地适应商业和技术上的改变。概念框架的最佳部分是通过引入不同的即插即用的服务提供商的概念，完全将组件管理/生命周期进程与商业逻辑和不同的第三方APIs隔离。即使发生改变，除了更改/替代服务提供商，你也不需要担心代码的其他部分。这样可以使程序更易维护，更易适应，和更强壮。
410
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
