松耦合组件的通信模式研究

严 勇，赵长宽

（1.北京航天发射技术研究所，北京100076；2.东北大学 计算中心，辽宁 沈阳110819）

0 引 言

当前的计算机应用环境是由大型主机、工作站、微机和嵌入式设备等多种计算机硬件，各种各样的软件，通过网络链接起来的复杂系统。软件应用环境的复杂性，对软件开发提出了更高的要求。软件开发不仅需要满足用户的需求，还要充分考虑历史软件资源的重用，并实现与多种软件的集成。例如在开发多学科设计优化系统中，必须考虑分布式计算、分布式组件和多种软件集成等诸多问题。因此具有可重用、可配置、松耦合的等优秀特性的组件技术，在软件开发中获得的广泛应用。在构建松耦合系统的系统中，如何解决组件通信问题非常重要。目前组件通信主要采用通知和消息队列，其要求参与通信的消息发送者和接收者已知，且彼此存在。而在分布式计算环境下，参与计算的组件动态加入，并接受信息。在时间上，通信的双方是异步的，消息发出者预先并不知道具体的消息接收者，并且消息之间可能存在一定的关联。在异步通信模式下，还存在如何实现与即将加载的组件通讯；如何与担任某种角色的组件通信等问题。另外，根据不同的计算任务定义，消息之间存在一定的关联。如何处理关联信息，也成为组件通信中的一个重要问题。由于现有的组件通信模式没有完全解决上述问题，因此需要继续深入研究。结合多学科设计优化系统研制需要，针对此问题提出一种新的组件通信模式，并从通信方法、组件注册、消息队列和关联消息4个方面进行了说明，同时结合多学科设计优化系统研制开展了验证工作。

1 相关研究

组件技术引入的最初动机是解决多语言、多厂商和跨平台软件设计，实现普适性的代码重用。其出发点是实现软件领域的集成电路 （IC），实现软件的封装和即插即用［1］。因此在基于组件技术开展的软件设计中，一个基本的设计原则是紧内聚和松耦合，以实现组件的独立性。

由于组件以松耦合方式存在，在空间上，可能属于不同的计算机或进程；在时间上，可能是异步的。因此组件的通信成为一个重要的设计问题。为了解决基于组件的松耦合系统设计中的通信问题，已经出现了通知 （notifications）和消息队列 （message queuing）等通信设计模式［2］。在目前的主流组件技术中，CORBA采用消息通知模式［3－4］，COM／DCOM采用消息队列模式［5］，EJB采用的JMS也是一种消息队列机制［6］。通知和消息队列技术的前提是，消息发送者预先知道消息的接收者。而在分布式计算系统设计中，由于承担计算任务的组件是动态加入的，其在接收以消息方式传送的任务时，并不知道消息的发送者。

针对复杂软件系统的解耦耦合问题，Patrick提出从空间、时间和同步过程3个维度进行分析。空间解耦是指消息传递的彼此不认知，发送消息与接收消息通过不同的服务实现，两者一般不存在引用关系，并且接收者不知道消息的发出者。时间解耦是指发送者与接收者不需要同时活动。同步解耦是指消息发送过程和消息接收过程均是异步的。并将当前通行模式归纳为消息传递 （message passing）、远程调用 （RPC）、通知 （notifications）、共享空间 （shared spaces）、消息队列 （message queuing）和订阅－发布 （publish／subscribe），并从空间、时间和同步过程3个维度进行分析，其结论是：消息传递在空间和时间上耦合的，只是在消息的发送过程中部分解耦；一般的远程调用，在空间和时间上耦合，仅仅实现消息的发送过程中的部分同步解耦；异步远程调用在空间和时间上耦合，实现了同步解耦；通知在空间和时间上耦合，实现同步解耦；共享空间实现了空间和时间解耦，并实现消息发送过程部分解耦；消息队列实现了空间、时间的解耦，以及发消息发送过程部分解耦。只有订阅－发布完全实现在空间、时间和同步解耦［7］。

在组件技术中，消息传递一般作为网络通信的基础，远程调用和通知是组件通讯基础，消息队列是组件技术中的常用技术，订阅－发布还未引入组件通信。基于耦合分析，CORBA的通知服务 （notification service）采用事件管道 （event channel）和消息队列类似，因此本文重点分析消息队列通讯模式。

基于消息队列的通信模式下，消息发送者异步将消息填加到队列，消息接收者从队列中接收消息，消息接收过程仅仅依赖消息在队列中顺序，而不依赖于其它预先定义的结构。消息队列一般采用FIFO （first－in first－out）队列或优先级顺序 （priority－based order）队列。由于消息接收过程依赖于消息的顺序，因此不能解决接收过程的同步解耦。

另外在消息队列中，需要将全部组件注册到消息处理器中，成为其监听器，各组件往消息处理器中发不同的消息，由消息处理器来选择相应的监听器 （即组件）进行处理。并且此类消息通讯必须提前将组件注册为监听器，由组件本身从消息队列中挑选要处理的消息［8］。这无法满足与未加载组件通讯或组件间点对点通讯的要求。同时也无法解决关联消息的处理。

2 动态组件通信模式

2.1 通信框架

针对组件通信的耦合问题，本文提出以消息中心为核心的通讯机制，其基本思想是：各个参与通讯的组件均在消息中心注册，并通过消息中心实现消息的传递，如图1所示。首先所有组件在消息中心建立账号，即一种运行时唯一的ID，亦称为通讯地址。通讯地址的编码方案在2.2节详细介绍。除此之外，组件还要指定功能角色，从而方便通过功能角色实现消息传递，同时也兼顾延迟加载组件的通信问题。

图1 消息中心通讯

下面针对组件通信中的3种典型情景进行分析：

情景1：消息发出者和消息接收者均激活，并且消息发出者明确知道消息发送给那个接收者。

假设组件1需要与组件4传递消息，组件1知道组件4的通讯地址，具体的通讯过程如下：①组件1首先创建消息，将需要组件4处理的任务封装在内；②组件1请求消息中心传递此消息；③消息中心根据消息提供的目的通讯地址，通过查询注册内容，并调用组件4的消息处理程序；④组件4处理消息，并将结果填充组件1传递的消息，并请求消息中心传递此消息；⑤组件1获取消息，并查看处理结果。

情景2：消息发出者和消息接收者均激活，但是消息发出者仅仅知道将消息发送到那类功能角色的接收者。

假设组件1需要将消息发送到特定功能角色的组件，组件4是此类组件，具体的通讯过程如下：①组件1首先创建消息，将需要功能角色组件处理的任务封装在内；②组件1请求消息中心传递此消息；③消息中心根据功能角色组件的注册情况，查找相应的功能角色组件，并确定接收者通讯地址；④根据接收者通讯地址，通过查询注册内容，并调用组件4的消息处理程序；⑤组件4处理消息，并将结果填充组件1传递的消息，并请求消息中心传递此消息；⑥组件1获取消息并查看处理结果。

情景3：消息发出者仅仅知道将消息发送到那类功能角色的接收者，并且此类功能角色组件不激活。

假设组件1需要将消息发送到特定功能角色的组件，组件4是此类组件，具体的通讯过程如下：①组件1首先创建消息，将需要功能角色组件处理的任务封装在内；②组件1请求消息中心传递此消息；③消息中心根据功能角色组件的注册情况，查找相应的功能角色组件，并确定接收者通讯地址，如果查到相应组件，进入步骤⑤，否则进入步骤④；④将消息存储于消息队列中，并执行步骤③；⑤根据接收者通讯地址，通过查询注册内容，并调用组件4的消息处理程序；⑥组件4处理消息，并将结果填充组件1传递的消息，并请求消息中心传递此消息；⑦组件1获取消息，并查看处理结果。

由于消息中心所涉及的组件很多，组件可能激活，也可能不激活，所以提供点对点和消息队列两种方式实现通信。点对点方式则采用直接调用消息处理程序的方式进行。消息中心采用消息队列的方式进行，即通过消息队列来存放要处理的消息。

为了保证重要消息的及时传递，须在反复不断地扫描消息队列之外，优先处理级别较为重要的消息。需要采用消息队列机制处理的消息包括广播消息和驻留消息两种。其中广播消息主要用于向全体组件进行广播，基本上用于表现组件自身的状态或行为发生变化；驻留消息则为未加载的动态组件提供，通信过程如图2所示。

图2 3种消息通讯方式

在此通信模式下，消息传递通过消息中心传递，在空间上，消息发出者和接收者不存在参考关系。在时间上，消息发送过程是异步的，消息发出者不要接收者的确认。消息接收过程，消息接收不依赖于消息队列顺序，因此解决了消息队列模式的存在的同步耦合问题。并且解决动态加载组件的通信问题。

2.2 组件注册

组件注册的目的是让消息中心知道组件的存在，以便于实现消息通讯，注册过程如下：①首先为组件指定功能角色名称，一般情况下可以使用带限定名称的类名；②向消息中心申请相应的通讯地址，它可以是静态的地址或运行时地址；③以当前的通讯地址为关键件注册组件；④处理驻留消息；⑤处理广播消息。

由于通讯地址是由数字组成并且唯一，故静态地址在保证组件唯一性方面存在一定难度，主要原因在于外来的组件很难保证其通讯地址不与已有组件的冲突，如果采用UUID格式［9］，又有点浪费资源，同时也不利于操作。为此，采用运行时地址分配方案将有助于解决上述问题。

本方案将利用组件的功能角色名称来生成通讯地址，基本思想是利用编码技术，将变长度的字符串转化成一个整数来表示，并要求变长度字符串满足特定格式。字符串应该具备 “XXXXX.XXXXX.XXXXX……”类似格式，其中 “XXXXX”由小写字母组成，实质为带包名的类名称。为了保证能用一个整数去表示全部的组件功能角色名称，必须采用不对称方式对待功能角色名称中的各段名字，同时对段数也做相应限制。

根据对功能角色名称的使用统计，各字段的不同频率依次由小到大。如图3所示，字段1通常为 “com”，字段2代表公司名，字段3～字段n－2代表按层级区分的模块名称，字段n－1代表具体的功能实现类名，最后一个字段n代表实例序数。现在要确定的就是每个字段不同个数的取值范围是多少，这里要求其最大化，以便于容纳更多的功能。为保证各字段数据不互相影响，这里采用进制进行处理，可选的常用进制为2、8、10、16等。这里采用10，主要考虑其容易理解。

图3 通讯地址各字段含义

由于字段1只占用1位可以不用考虑，字段n指定占用10个位置，其它各字段都占用10m个位置 （这里m为整数，要求m至少为2）。现在来计算一下m和n的具体数值。参见下面的不定方程 （其中Imax表示最大整数）

在32位计算机上，最大的整数为Imax＝232，则由上述方程 （1）可得

代入n≥5到式 （2），可得：m≤2.8。由此可确定m＝2，再代入式 （2），可得：n≤6.3。

由此可知n＝5或6。为保证组件开发的灵活性，适当放宽字段数量，决定n＝6。最终的字段及其取值范围，如图4所示。

实际的编码过程是按组件提供的功能角色名称以 “.”区分，建立编码树，如图5所示。假设由两个公司开发出7个功能插件位于7个模块中。那么，类 “ClassName3”的第1个实例编码为 “1010202031”，类 “ClassName7”的第3个实例编码为 “1020405073”等。组件注册信息的存储通过映射表实现，并以组件的通讯地址作为键值。

图4 实际通讯地址各字段含义和其取值范围

图5 通讯地址应用举例

2.3 消息队列

消息的处理是通过 “消息中心”将要处理的消息调度到 “消息中心”队列中，然后由消息处理引擎 （参见图2）按照一定的规则依次处理队列中消息。可选用的规则包括3种：①先进先出 （FIFO）；②先进后出 （FILO）；③按组件优先级处理等。方式①和方式②对于那些执行效率要求不高的或有某些特殊要求的场合，是一种较为简单的调度方式；方式③是现在大多数应用所采用的任务调度方式，它又分为两种：静态优先级和动态优先级，这种方式将消息分为不同的级别，优先级高的消息先得到执行。本文采用动态优先级。

现在评估一下在动态优先级的执行队列中，一个组件最大调度时间是多少？先假设队列的长度 （容纳消息的最大个数）为L，消息的优先级数为R，一个消息被每被扫描N次，其级别便会自动上升一级直到最大，消息处理引擎每次将会处理队列中的全部最高级消息，消息处理引擎每个t0时间便会开始执行队列处理，那么一个消息最大调度时间T计算如下

然而在实际过程中，我们要研究通常级别的消息在队列中处理的时间。一般情况下，我们假定不同组件其级别分布服从正态分布，参见图6。在图中，曲线下的面积便是队列缓冲区大小，优先级从左到右由高变低。

图6 组件优先级分布

再过Δt时间后，图6中的曲线便会向做移动，移出部分可以认为是已经调度处理的消息，那么我们假定还会新进一定数量消息，它们级别服从正态分布。参见图7，实线的曲线向右移动了一段距离，移出部分由虚线所代表的新进消息代替，此时，要考察的消息也会由I移到II，此时我们考察的消息前边还有s1＋s2面积所代表的消息数量。那么，我们要计算的是，何时II能移动到与y轴重合，所花去的时间就是我们要考察消息排队等待的时间。

为了能够计算这个时间，我们有两种不同的方式去执行队列，一种就是上面提到的消息处理引擎全部执行队列中最高级别的组件，另一种就是每次只执行其中一定数量的组件，也是按级别由高到低进行处理。对于第一种方式来说，我们要考察消息排队等待的时间 （τ）为

图7 经过Δt时间后队列中组件级别分布情况

式中：R——消息级别总数；N——消息级别进级扫描次数；t0——消息处理引擎执行时间间隔。

假定N＝1，参见图8，在t时刻队列中的优先级分布情况为Ft（x），竖虚线代表Δt时间后，队列优先级升级后的情况，以及新进队列组件优先级分布情况为gΔt（x），由此可以列出方程式 （5）

式中：n——表示每次消息处理引擎处理的消息数量；t0——表示消息处理引擎每次调度时间间隔。

图8 等待时间计算模型

从式 （5）中可以看出，Δx是Δt的函数，Δt小于或等于t0。排队等待τ可以由方程 （6）获得，此方程是一个非常复杂的方程组，可以通过差分方法近似求得。由于不是本文的重点内容，求解方法简述如下：先根据消息优先级统计数据求得μ和σ，取Δt为t0，通过式 （5）计算出g和F来，在通过式 （5）的变参数积分方程获得Δx，由此我们可以通过一系列的Δt求得Δx1、Δx2、…、Δxm，再按式（7）获得差值，当出现由负号变成正号时的m值，我们可以通过τ＝mt0求得消息排队时间

2.4 关联消息

在松耦合情况下，一个比较难处理的问题就是组件之间任务如何关联［10］。例如：当一个组件需要另外一个组件提供运行结果，但是它并不能明确确定该组件何时能提供。针对这种情况下，本文采用解决方案是在发送的消息上提供关联信息，即建立关联消息对。如图9所示，在消息中设定一个指针，指向下一个相关联的消息。并在消息处理中心对消息队进行处理，以保证关联消息的正确。并在消息上设置同步锁，实现两个消息关联。

图9 关联消息对

3 实验与结果分析

结合发射平台数字化设计系统项目建设需要，基于RCP（rich client platform）技术构建了多学科设计优化系统，并对本文提出的方法进行验证。

在当前的复杂产品设计中，由于越来越多的产品要求其功能紧密集成，这就促使在产品的研发阶段必须要求各专业紧密协作、相互配合，在单一学科专业的优化设计的基础上，实现整体的多学科设计优化。多学科设计优化设计实现复杂系统的整体最优，同时兼顾各个子系统之间的约束和耦合关系［11］。多学科设计优化设计系统是按照多学科设计优化思想开发的分布式计算软件平台系统［12］。由于在多学科设计优化系统设计中，必然涉及与来自不同学科专业领域的多种设计、分析和仿真软件的信息集成［13］。为了实现系统的开放性，基于组件技术实现多种软件的封装，并基于松耦合方式实现系统设计，是系统设计的基本方法［14］。其基本思路是将不同的计算软件封装成不同的计算组件，将设计任务赋予具体的组件实例，通过流程将不同的组件实例按照设计过程要求，组成求解流程，通过多学科优化求解实现分布式计算和全局寻优。

3.1 实验结果

本系统设计实现的多学科优化设计系统组成如图10所示，将NX、ProE Ansys、Adams等典型专业设计分析软件封装成分析组件，通过可视化流程将组件实例的组装实现特定设计过程，通过多学科优化设计求解器实现迭代计算寻优，通过消息中心实现组件消息传递。系统可视化流程模块基于Eclipse RCP［15］技术构建，系统技术架构如图11所示。

消息中心部分，消息中心的主要类图结构，如图12所示，核心部分由MessageTransfer、MessageRequest、Cons trainRequestPair这3个类构成，其中MessageTransfer实现消息中心，MessageRequest实现消息的封装，Constrain－RequestPair负责关联消息。

图10 多学科优化系统组成

3.2 实验分析

图13所示流程描述基于Pro／E的悬臂梁结构优化问题，优化设计目标是满足结构强度要求条件下，质量最小。其中强度结算部分由ANSYS组件完成，优化求解由约束求解器组件完成，约束条件由脚本组件实现，结果输出由图形显示组件实现。整个流程9个组件实例构成。上述组件的消息通信通过消息中心完成。在生产环境中，ANSYS一般部署专门的计算服务器，因此ANSYS组件的生存状态取决于服务运行情况。通过消息中心机制，保证当服务器可用时，即可接收从 “写出”组件或 “约束优化”等上游组件发送的消息任务，并将运算结果传回。

图13 多学科设计优化系统主界面

4 结束语

本文针对基于组件的松耦合系统设计中的组件通讯问题，提出一种新的以 “消息中心”为核心的组件消息通信模式。此通信模式解决了组件通信的中同步耦合问题。并对组件通讯地址编码问题进行讨论，在提出了基于功能角色的组件编码技术。同时研究了消息队列的排列问题，给出具有动态优先级的执行队列的最大调度时间计算公式。最后结合航天科技集团信息化 “示范工程”中的子项目“发射平台数字化设计系统”设计实践，开展相关的验证工作。实践表明此技术是可行，并已应用于 “发射平台数字化设计系统”中。

［1］ZHOU Zhiying.Modern software engineering：New technoloy volume［M］.Beijing：Science Press，2000：116－123 （in Chinese）.［周之英.现代软件工程 （下）：新技术篇 ［M］.北京：科学出版社，2000：116－123.］

［2］SUN Changlin，Rajeev R.Compositional reasoning of performance in component－based distributed systems ［J］.Cluster Comput，2008，11 （4）：331－340.

［3］LU Hui－Chieh，CHU Yen－Ping.A generic application sharing architecture based on message－oriented middleware platform［J］.Computer Standards ＆ Interfaces，2008，30 （3）：191－199.

［4］Object Management Group，Notification service specification V 1.1 ［EB／OL］.http：／／www.omg.org／technology ／documents／corbaservices＿spec＿catalog.htm，2011.

［5］Message queuing architecture ［EB／OL］.http：／／technet.microsoft.com／zh－cn／library／cc754897（WS.10）.aspx，2011.

［6］Java message service specification－version 1.1 ［EB／OL］.http：／／www.oracle.com／technetwork／java／docs－136352.html，2011.

［7］Patrick Th Eugster，Pascal A Felber.The many faces of publish／subscribe ［J］.ACM Computing Surveys，2003，35 （2）：114－131.

［8］Silvestre B，Rossetto S.Flexibility andcoordinationineventbased，loosely coupled distributed systems ［J］.Computer Languages，Systems ＆Structures，2010，36 （2）：42－157.

［9］UUID structure ［EB／OL］.http：／／msdn.microsoft.com／enus／library／aa379358（v＝vs.85）.aspx，2011.

［10］LIU Yan，Ian Gorton.The architecture of an event correlation service for adaptive middleware－based applications ［J］.Journal of Systems and Software，2008，81 （12）：2134－2145.

［11］MA Mingxu，WANG Chengen.Multidisciplinary design optimization for complex product review ［J］.Chinese Journal of Mechanical Engineering，2008，44 （6）：15－26 （in Chinese）.［马明旭，王成恩.复杂产品多学科设计优化技术 ［J］.机械工程学报，2008，44 （6）：15－26.］

［12］TANG Xiao－an，LI Guo－zheng.Research on integrated missile optimized design environment with configurable function［J］.Journal of System Simulation，2009，21 （7）：1933－1937（in Chinese）.［汤晓安，李国正.支持功能重配的导弹集成优化设计平台研究 ［J］.系统仿真学报，2009，21（7）：1933－1937.］

［13］WANG Cheng－en，LIU Zhen.Integration technologies for design of aero－gas turbine ［J］.Journal of Northeastern University （Natural Science），2006，27 （5）：485－488 （in Chinese）.［王成恩，刘震.航空发动机涡轮设计集成技术 ［J］.东北大学学报，2006，27 （5）：485－488.］

［14］Heiko Koziolek.Performance evaluation of component－based software systems：A survey ［J］.Performance Evaluation，2010，67 （8）：634－658.

［15］Rich client platform （RCP）applications ［EB／OL］.http：／／www.eclipse.org／community／rcp.php，2011.