《面向模式的软件体系结构2-用于并发和网络化对象模式》读书笔记（4）--- 组件配置器...

2.2组件配置器（Component Configurator）

1.问题

      由组件构成的应用程序必须提供一种机制，把这些组件配置到一个或多个进程中去。解决这个问题受到三种强制条件的影响：

      1）在许多系统和应用程序中，组件功能或者实现细节的改变是很普遍的。对一个组件的修改应该对使用它的其他组件的实现有最小的影响。

      2）开发人员在开发应用程序时，常常并不知道最有效地配置或者分布多个组件到进程和主机中的方法。如果开发人员过早地专注于组件的特殊配置，那么这也许会破坏灵活性，降低整个系统的性能和功能特性，并且不必要地增加资源的使用。

      3）执行类似组件的配置、初始化和控制这样的普通管理任务应该是直接的，并且是与组件无关的。只要有可能，就应该使它们自动化，例如通过使用某种类型的脚本机制。

 

2.解决方案

      从组件的实现中分离出组件接口，使应用程序独立于组件实现被配置到应用程序进程的时间点。

      组件（Component）定义一个一致的接口，用来配置和控制它提供的特殊类型的应用程序服务或者功能。具体组件（Concrete Component）针对具体的应用程序实现这个接口。应用程序或者管理员可以使用组件接口动态地启动、挂起、恢复和终止它们的具体组件，还可以获取有关每个被配置的具体组件的运行信息。具体组件被打包进一个合适的配置单元，例如一个动态链接库（DLL）。在组件配置器的控制下，这个DLL能被动态地链接进和解链出一个应用程序，组件配置器使用组件仓库（Component Repository）来管理被配置到应用程序中的所有具体组件。

 

3.结构

      组件配置器模式包括四个参与者：

      组件定义一个一致的接口，用于配置和控制组件实现所提供的应用程序服务或者功能特性的类型，一般的控制操作包括初始化、挂起、恢复和终止组件。

      具体组件实现组件控制接口，以提供一个特定类型的组件。具体组件也实现方法以提供针对具体应用的功能，例如处理与其他的被连接的对等组件交换的数据。具体组件以某种形式（如DLL）打包，以便在运行时能被动态地链接进或解链出应用程序。

     

 

      组件仓库管理当前被配置到应用程序中的所有具体组件，这个仓库允许系统管理应用程序或者管理员通过中心管理机制，来控制被配置的具体组件的行为。

      组件配置器使用组件仓库来协调具体组件的（重新）配置。它实现一种解释和执行脚本的机制，此脚本指定哪个可用的具体组件，通过从DLL中动态地链接和解链来（重新）配置到应用程序中。

     

 

4.实现

      可以把组件配置器模式中的参与者分解为两层：

      ·配置管理层组件（Configuration Management Layer Component）。这一层执行通用的，与应用无关的策略，这些策略安装、初始化、控制和终止组件。

      ·应用层组件（Application Layer Component）。这一层实现执行针对应用的处理的具体组件。

      1）定义组件配置和控制接口。组件应支持下列操作，以便组件配置器能配置和控制它们：

          ·组件初始化。

          ·组件结束。关闭组件并清除它的资源。

          ·组件挂起。

          ·组件恢复。

          ·组件通知。报告描述组件的静态和动态伪指令的信息。 

      2）实现组件仓库。组件仓库管理所有通过DLL链接到应用程序中的具体组件实现。当组件被配置进或配置出应用程序时，组件配置器使用这个仓库来控制它。每个组件的当前状态，比如它是活动的还是挂起的，都能在仓库中获得维护。

      3）实现组件（重新）配置机制。在组件能够执行之前，它必须配置到应用程序的地址空间。组件配置器定义一种机制，控制把组件静态地和\或动态地（重新）配置进应用程序进程中去。组件配置器的实现包括5个子活动：

        3.1）定义组件配置器接口。组件配置器通常作为一个单件外观（Singleton facade）实现。这种做法能够协调对其他组件配置器模式组件的访问。

        3.2）定义一种用于指定组件配置伪指令的语言。这些伪指令向组件配置器供应它在运行时定位和初始化组件实现所需的信息，也提供在初始化组件之后挂起、恢复、重新初始化和\或终止组件所需的信息。可以用多种方式指定组件配置伪指令，例如用命令行、环境变量、图形用户接口或者配置脚本。

        3.3）实现一个机制。用于解析和处理组件配置伪指令。这种机制常常作为一个伪指令解释器（Directive Interpreter）实现，些解释器将组件的运行特性与它的配置相关的特性分开。

        3.4）实现动态的配置机制。组件配置器使用这种机制动态地把组件链接进和解链出应该程序进程。

        3.5）实现动态的重新配置机制。这种机制建立在上述的动态配置机制上，以触发组件实现的动态的重新配置（reconfiguration）。组件重新配置应该对应用程序进程中其他组件的执行影响最小。

      4）实现具体组件。实现具体组件包含3个子活动：

        4.1）实现具体组件并发模型。实现具体组件的一个重要方面，涉及到组件的并发策略的选择。

        ·反应的\主动的执行（Reactive\Proactive Execution）。使用这些策略，就可以使用一个控制线程反应地或者主动地处理所有组件。

        ·多线程或多进程并发执行（Multi-threaded or multi-process concurrent）。使用这些策略，被配置的组件经组件配置器初始化之后，就在它们自己的线程或进程中执行。

        4.2）实现用于组件间通信的机制。有些组件可以完全独立地运行，而另一些组件必须和其他组件通信。这时，组件开发人员必须选择一种用于组件间通信的机制。

        ·如果组件是搭配式的，则一般有两种选择，一是对组件间指针关系进行硬编码，但这样做不太灵活，也会丧失动态组件配置的优点；另一种方法就是使用组件仓库“按名字”访问组件。

        ·当组件是分布式的时候，一般也有两种选择，一是低层IPC机制，如使用套接字或TCP/IP连接，此外是类似CORBA的更高级机制。使用CORBA的优点是，通过自动地确定组件是在一起的还是分布式的，ORB可以透明地优化得到最快速的IPC机制。

        4.3）实现重新建立组件关系的机制。实现这种机制的策略之一是设置检查点，检查组件对它相关组件的引用，并把它存储在一个备忘录（Memento）中。组件在关闭之前，可以把这个备忘录传递给组件配置器。同样，备忘录可以包含从旧组件向新组件传递的其他状态信息，新组件安装后，组件配置器可以把备忘录传递给新组件。随后这个组件重新安装保存在备忘录中的连接和状态信息。

 

5.结论

优点：

      1）一致性。组件配置器模式强制采用一致的配置和控制接口来管理组件。这个一致性允许把组件作为积木块看待，它们可以作为组件集成到一个更大的应用中。

      2）集中化管理。组件配置器模式把一个或多个组件分为一个管理单元。这种合并通过自动地执行常用的组件初始化和终止活动。另外，模式通过确保每个组件支持相同的配置管理操作采集中化组件管理。

      3）模块性，可测试性和可复用性。通过从组件配置到进程的方式中分解出组件的实现，组件配置器模式提高了应用程序的模块性和可复用性。

      4）配置动态性和控制。组件配置器模式可以在不需要修改，重新编译或静态地重新链接现有代码的情况下，动态地重新配置组件。另外，在不重新启动组件或者和它搭配的其他主动组件的情况下，常常也可以执行组件的（重新）配置。这些特性有助于为应用程序定义的组件配置框架创建基础设施。

      5）调整和优化。组件配置器模式通过从组件执行机制中分解出组件功能，为开发人员增加组件配置的选择范围。

 

不足：

      1）缺乏决定性和排序相关性。使用组件配置器模式难以决定或者分析应用程序的行为，直到在运行时配置它的组件。

      2）减少安全性或可靠性。使用组件配置器模式的应用程序也许比同等的静态配置的应用程序更不安全或更不可靠。

      3）增加运行时开锁和基础设施复杂性。组件配置器模式在执行组件时增加了抽象和间接的级数。

      4）过度窄小公共接口。组件的初始化或者终止也许会过于复杂或者与它的语境过于耦合，以至于通过常用组件控制接口很难以一致的方式执行。

转载于:https://www.cnblogs.com/pennant/archive/2012/09/05/2669876.html