On the Role of Middleware in Architecture-Based Software Development——Translation Version

On the Role of Middleware in Architecture-Based Software Development

基于架构的中间件在软件开发中的作用

Abstract

摘要

软件体系结构促进了模块化功能构建块（组件）、它们的互连（配置）以及它们的交互（连接器）的发展。由于架构级组件通常包含复杂的功能,因此可以合理预期它们的交互也将是复杂的.诸如CORBA, COM 和 RMI 等 middleware 技术提供了一系列预定义的服务,以实现组件的组成与交互.然而,此类服务在软件体系结构中的潜在作用尚不完全清楚.此外,遵循一种 middleware 标准的组件无法轻易地与遵循另一种 middleware 标准的组件交互.为了理解 middleware 技术在实现体系结构中的作用及折衷,并实现跨 middleware 平台的组件互操作性,我们进行了系列研究,就特定体系结构样式 C2 及其实现基础设施展开了案例分析.特别是,通过将中间件功能整合到 C2 的显式软件连接器中,我们得以结合 C2 的现有优势（例如组件互换性、基材独立性和结构指导）与多语言、多过程及分布式应用程序开发的新能力.这种结合对开发者而言是透明的方式.此外,我们已经展示了基于连接器的方法的确切实用性,它使在不同 middleware 平台上实现的组件能够互操作.尽管我们的方法的一些细节源于 C2 样式的特征,但我们认为许多课程教训更具普遍适用性.我们认为这些课程可以帮助形成更广泛的研究议程,以将软件体系结构建模能力与 middleware 提供的支持相结合.

1. Introduction

1. 介绍

Today's software systems are ever-evolving in terms of count sophistication complexity distribution reach and user base. The surge in information technology has been driven by rising hardware affordability alongside the transformation of the Internet from a niche tech tool favored by elites to a vital global asset. Consequently demand for software applications far exceeds our capacity to develop them both quantitatively and qualitatively [Sta98]. A key aspect currently dominating software engineering practices is reliance on ad-hoc methodologies primarily motivated by industry demands commercial interests and market pressures rather than established scientific principles. The severity of this challenge has been acknowledged at highest levels within U.S. Government evidenced by recent findings from President’s Information Technology Advisory Committee (PITAC) report [P99]. Notably this report highlights significant issues related to large-scale software development such as component-based architecture reusability and interoperability as primary challenges within computer science domain.

These issues have been extensively explored in the past decade, resulting in numerous commercial component interoperability or middleware technologies that have been adopted as de facto standards (e.g., CORBA [OHE96], (D.COM [Ses97], OLE [Cha96], ActiveX [Cha96], Enterprise JavaBeans (EJB) [FFCM99], Java RMI [Sun], DCE [Sch93], SoftBench [Cag90], ToolTa1k [JH93]), as well as a number of widely-studied, research-oriented middleware technologies (Q [MH096], Field [Rei90], Polylith [Pur94], JEDI [CDF98], SIENA [CDRW98]). One can use any one of these technologies to develop software systems from existing components more quickly and reliably than was generally possible in the past. Yet ironically, the proprietary nature of these middleware technologies has served to hinder interoperability between components developed according to different technologies. For example, the developers of COM components must modify or reimplement those components for use in a system based on CORBA. Moreover, even components implemented using different flavors of CORBA may not be interoperable. The result is a highly fragmented software component marketplace that ultimately impedes the ability of software organizations to develop systems with the highest possible quality and reliability, at the lowest possible cost. Another problem area has been the training of software engineers in the principles of component-based software development: it is currently mired in the details and peculiarities of a few chosen technologies, instead of focusing on underlying common principles and mechanisms.
这些问题都进行了广泛的研究在过去的十年里,导致大量的商业组件互操作性或中间件技术,作为事实上的标准(例如,CORBA (OHE96) (D.COM [Ses97], OLE Cha96, ActiveX Cha96, Enterprise javabean (EJB) [FFCM99], Java RMI(太阳),DCE Sch93, SoftBench Cag90, ToolTa1k [JH93]),以及一系列的广泛研究,研究型中间件技术(Q [MH096], [Rei90], Polylith [Pur94],绝地[CDF98]，锡耶纳[CDRW98])。人们可以使用这些技术中的任何一种来从现有组件开发软件系统，其速度和可靠性都比过去通常可能实现的要快。然而，具有讽刺意味的是，这些中间件技术的专有性质阻碍了根据不同技术开发的组件之间的互操作性。例如，COM组件的开发人员必须修改或重新实现这些组件，以便在基于CORBA的系统中使用。而且，即使使用不同风格的CORBA实现的组件也可能无法互操作。其结果是高度分散的软件组件市场，最终阻碍了软件组织以尽可能低的成本开发尽可能高的质量和可靠性的系统的能力。另一个问题领域是软件工程师在基于组件的软件开发原则方面的培训:目前，它陷入了一些选定技术的细节和特性的困境，而不是集中在基本的通用原则和机制上。

Another significant research and development initiative has been actively pursued in tandem with middleware-related efforts. This particular software development direction is characterized by its explicit emphasis on common architectural patterns [PW92, SG96, MTOO]. Notably, particularly, software architecture research focuses on enhancing the quality of applications through the optimization of coarse-grained architectural elements - specifically components and connectors. The system's computational tasks are executed by individual components; these interactions are mediated by connectors. This strategic separation enables developers to abstract away intricate details and concentrate their attention on high-level aspects such as system architecture configurations, communication protocols at a systemic level, component deployment strategies, etc. Furthermore, software architects possess a diverse array of architectural styles - collections of recurring structural motifs along with their associated behavioral and interaction patterns - each defined by unique attributes that contribute to predictable outcomes.

The architecture and middleware address comparable challenges—large-scale, component-based development—but at distinct phases within a system's lifecycle. Although architecture serves as an early model highlighting a system's essential conceptual attributes through high-level abstractions, middleware facilitates its implementation while ensuring proper integration and interaction among implemented components. Current methodologies for architecture modeling and analysis have largely struggled with mapping architectural decisions to system implementations in both automated and property-preserving ways [MTOO]. Concurrently, software development reliant solely on middleware can be likened to "assembly programming" in software composition [OMTR98], where such technologies offer no support for defining application structure and behavior, selecting required components, or interconnecting them into desired configurations.
**体系结构和中间件处理类似的问题——大规模的、基于组件的开发——但在系统生命周期的不同阶段。尽管体系结构作为早期模型强调了系统的关键概念属性，并通过高级抽象实现这一目标，但中间件则支持其实现，并确保实现组件的适当组合与交互。当前针对体系结构建模与分析的方法已基本陷入无法以自动化且保留属性的方式将体系结构决策映射至系统实现中的困境[MTOO]。与此同时,完全依赖于中间件的软件开发在许多方面可被视为软件组成的"汇编程序"[OMTR98]：此类技术提供不支持确定应用程序的结构与行为、选择所需组件或连接组件以形成所需拓扑的信息。
**

这两个领域之间的相互作用及其各自存在的局限性表明了一种可能性：通过将体系结构建模与分析方法与中间件技术相结合来实现"两全之利"的目标。由于体系结构旨在在高度抽象的层次上描述系统，在直接将体系结构模型细化为具体的实现方案方面存在一定的困难。主要原因在于决策空间随着抽象层次的逐步降低而迅速扩大：在设计阶段识别出诸如带有属性、操作以及关联等类构造；而在实现阶段则需要选择并实例化特定的数据——图1展示了决策空间随着系统从架构向实现细化而不断增长的趋势。为了实现这一目标，在现有技术中已有的解决方案包括一系列中间模型[MQR95、LV95、RMRR98、AM99]以提供将体系结构模型细化为其实现的具体机制[相关研究]。然而，在实践中不得不权衡工程师对较低层次模型保真度的信心与所采用技术的实际可行性[研究结果]之间存在的矛盾[讨论]。此外，在很大程度上现有的细化方法未能充分利用不断增长的现有(已实现)组件库中的可重用组件资源

Figure 1. As a system becomes more detailed from an architecture to an implementation, the decision space increases. Middleware technologies are used for binding the implementation space, which makes mapping from architecture to implementation easier.

该论文采用另一种策略（如图1所示）。目标是通过使用一组中间件技术将目标（实现）空间绑定到特定的、清晰定义的子空间。本文介绍了一种利用特定体系结构构造（软件接口）来实现所需结果的技术。这种技术以最小化所选中间件对交互组件影响的方式实现。实际上，在理论上支持CORBA组件通过Java的RMI进行交互的可能性是存在的。我们进行了系列案例研究来验证我们的假设。一个特定的设计风格C2已经被用作这项调查的基础[TMA+96, MRT99]。我们的初步结果是有希望的，并表明基于架构和基于中间件的技术和技术的成功结合确实是可能的。然而，在这一最初的实践经验中也揭示了一些仅仅依赖于接口方法的局限性。我们利用这些局限性作为推动更广泛研究基于组件开发、互操作性和中间件与体系结构之间关系动机的基础。这些问题构成了一个研究议程，并为我们未来的工作制定了框架

本文余下部分按如下结构展开。第一部分介绍系统架构设计的基本概念及其核心要素。第二部分简要阐述了C2体系结构的特点及其所采用的连接器功能。第三部分详细介绍了我们采用的技术路径来实现"支持中间件"式的连接器，并探讨了其在跨平台组件交互中的应用效果。通过回顾所获得的经验与展望未来的工作内容完成了全文。

2. Overview of the C2 Style

2. C2风格概述

We selected the C2 architectural style as the foundation for our initial exploration of middleware integration with software architectures. This architectural style is particularly well-suited to this task due to several key advantages. C2 explicitly defines software connectors as first-class entities, which are responsible for handling component interactions. Furthermore, this style provides facilities for exploring specific properties such as filtering, routing, and broadcasting, features that are typically associated with middleware functionality. Additionally, the C2 paradigm excels in distributed environments, allowing us to leverage the networking capabilities inherent in many middleware technologies. By employing a system composition model supported by C2, we can integrate components running in distributed, heterogeneous environments without shared address spaces. This approach also accommodates dynamic architecture changes, supports concurrent user interaction with the system, allows multiple user interface toolkits to be utilized simultaneously, and enables involvement of various media types within the system.

C2风格可以非正式地总结为由连接器连接在一起的并发组件网络。体系结构中组件之间的所有通信都是通过连接器交换消息来实现的。基于消息的通信广泛应用于适合C2架构的分布式环境。每个组件可能拥有自己的控制线程。这简化了多组件、多用户和并发应用程序的建模和实现，并支持利用分布式平台。提出的体系结构与其实现是不同的，因此组件确实可以共享控制线程。体系结构与实现的分离是我们将中间件技术与C2集成的方法的一个关键方面，在第3节中有详细讨论。最后，在C2组件之间没有共享地址空间的假设。任何基于共享地址空间的前提在允许使用不同语言开发异构、高度分布组件及其各自控制线程和内部架构的情况下都是不合理的

Having already addressed the foundational aspects of our methodology, central to its effectiveness are software connectors, which are pivotal in bridging components together and facilitating their interactions. These connectors are intricately integrated into the architecture and serve as the backbone for inter-component communication. To be found within a software system, they manifest as shared variable accesses, table entries, buffers, procedure calls, remote procedure calls (RPC), network protocols, pipes and other forms of data exchange mechanisms [SG96]. The role of these connectors becomes particularly significant in large-scale systems and especially in distributed environments where their functionality becomes a critical determinant of overall system performance and reliability. By abstracting and encapsulating the intricate details of interactions within architectural connectors, we have demonstrated significant potential in addressing long-standing challenges in software development such as scalability, distribution, concurrency and runtime adaptability. This approach has been validated through extensive research efforts involving multiple studies conducted over several years [SDK+95], [SG96], [AG97], [OMT98], [KM98]. Through these investigations into key attributes influencing system behavior and performance metrics like resource utilization rates and throughput levels across different operational scenarios [MMPOO], we have identified several promising directions for advancing the state-of-the-art in software architecture design and implementation.

我们之前的研究中广泛运用了连接器来支持软件建模、分析、生成、演化、重用以及异构性[TMA+96,MOT97,…]。特别是C2风格的连接器能够连接到任意数量的组件以及其它类型的连接器。每个连接器的主要职责包括消息路由、广播以及过滤操作。采用C2设计风格的连接器还能够适配消息以适应不匹配的接口和协议[TMA+96,MOT97,…]。

为了实现C2风格架构的支持工作，我们开发了一个可扩展的抽象类框架，在组件、连接器和消息等概念方面提供了广泛的支持，并如图所示所示。该框架构成了C2体系结构开发及中间件集成的基础。我们即将讨论的是该框架如何封装所有集成中间件的访问权限，并确保这些中间件对体系结构师和特定实现者的透明性。该框架与所使用的任何中间件结合在一起，直接支持了从DRADEL工具套件中的体系结构自动生成（部分）应用程序的能力。该框架实现了互连与消息传递协议，并通过继承自适当的抽象类来定义在C2风格的应用程序中使用的组件和连接器类型。这不仅保证了它们之间的互操作性，还消除了许多重复性的编程任务，并使C2应用开发者能够专注于应用程序级别的问题本身。此外，该框架还支持多种实现配置：整个结果系统可能在单个控制线程中执行；或者每个组件可能在其自己的控制线程或操作系统（OS）进程中运行；或者整体系统在一个控制线程中运行等选择。到目前为止，该框架已在C++和Java语言中实现了这一功能并进行了测试验证。

Figure 2. C2 implementation framework.
图2 C2的实现框架。

Example C2-Style Application

C2-Style示例应用程序

In our investigation of C2 middleware integration, a system extensively employed has been adapted from the video game KLAX. Its detailed description can be found in Figure 3. The particular application was selected primarily due to its real-time requirements imposed by game play, which necessitated a focus on performance optimization. The system's architecture is illustrated in Figure 4. Comprising three logical groups, this application's components are structured as follows: at its core are state encapsulation modules that manage request messages and trigger internal state changes through notification emissions. These notifications are routed to subsequent processing stages, where they are received by both logic-based and artist-driven components. The logic components enforce game rules to request state changes and interpret these notifications to ascertain the evolving game state. Simultaneously, artist components also receive state change notifications, prompting them to update their visual representations. Each artist maintains a set of abstract graphical objects' states, whose modifications generate notification signals aimed at triggering lower-level rendering processes. The GraphicsBinding component collects all such state-related notifications from artists and translates them into window system calls. User interactions, such as key presses, are translated into request signals by GraphicsBinding, which are subsequently processed by artist components.

图表3：一个屏幕截图和对我们实现的KLAX视频游戏的描述.
图表3：一个屏幕截图和对我们实现的KLAX视频游戏的描述。

Figure 4 illustrates the conceptual architecture of the C2 within KLAX. Highlighted ovals indicate process-machine interfaces.
图4展示了KLAX中的概念C2架构。Highlighted ovals表示process-machine interfaces.

l. It has been argued by others [DR99, YBB99] that this framework is similar to commercial middleware platforms, such as CORBA and COM.
1. 其他人[DR99, YBB99]认为这个框架类似于商业中间件平台，比如CORBA和COM。

我们采用了图4所示的部署配置文件来评估使用中间件技术实现体系架构所面临的问题，并且尽管有许多其他部署方案显然是可行的。基于图2展示的框架构建了两个KLAX实现分别采用C++和Java版本。图4所示体系结构的一个变体也用作构建了一个分布式、多玩家KLAX应用程序的基础该应用中的每个玩家在其自己的机器上运行一个副本 of KLAX系统的核心机制在于每个玩家通过向远程游戏服务器发送请求来与其他玩家竞争例如向特定玩家的滑槽添加额外方块游戏服务器则会根据对手的动作向相应玩家反馈其状态变化情况

While we have yet to attempt optimization, benchmark results reveal that under identical conditions, C++ performance surpasses Java by approximately four times. In single-player KLAX sessions, each keystroke triggers between ten and thirty messaging events, while each clock tick corresponds to three through twenty such events. The efficiency of inter-process and/or machine communication hinges upon the foundational mechanisms (e.g., middleware) employed in their implementation.

3. Employing Middleware to Implement Software Connectors

3. 使用中间件来实现软件连接器

The predominant focus of component-based software development has been on designing, selecting, adapting, implementing, and integrating computational elements—software components. Since components may contain complex functionality, it is reasonable to expect that their interactions will be complex as well. Existing middleware technologies have addressed component interaction via a predefined set of capabilities (e.g., RPC) that is typically not intended to be extensible. These capabilities are usually packaged into a facility, such as an object request broker (ORB), a message broker (MOM), or a software bus [Rei90, Cag90, Pur94, ISG97, IMA98]. As foreshadowed above, our approach to coupling the benefits of architecture- and middleware-based development approaches will focus on component interactions and leverage ORBs. Thus, our primary hypothesis is that connectors are the proper abstraction for integrating architectures and middleware. This hypothesis is motivated by the recognition that, though different, ORBs and connectors share several key characteristics. Indeed, an ORB can be viewed as an implementation of a sophisticated connector that supports a large set of interaction protocols and services. This perspective suggests our general approach: a software architect designs an application in the most appropriate and intuitive way, selects one or more middleware platforms that are suitable for implementing the architecture, maps the architecture to a particular topology (sometimes imposed by the middleware [DR99]), selects the needed set of off-the-shelf (OTS) components, and uses the appropriate ORBs to implement the connectors in the architecture.
基于组件的软件开发的主要重点是设计、选择、调整、实现和集成计算元素—软件组件。由于组件可能包含复杂的功能，因此有理由期望它们的交互也将是复杂的。现有的中间件技术已经通过一组预定义的功能(例如RPC)解决了组件交互问题，而这些功能通常是不可扩展的。这些功能通常打包到一个工具中，如对象请求代理(ORB)、消息代理(MOM)或软件总线[Rei90、Cag90、Pur94、ISG97、IMA98]。如前所述，我们耦合基于体系结构和基于中间件的开发方法的好处的方法将集中于组件交互和利用orb。因此，我们的主要假设是连接器是集成体系结构和中间件的适当抽象。这一假设的动机是认识到，尽管不同，球体和连接器共享几个关键特征。实际上，ORB可以看作是支持大量交互协议和服务的复杂连接器的实现。这种观点表明我们的一般方法:软件架构师设计应用程序在最合适的和直观的方式,选择一个或多个中间件平台,适用于实现架构,架构映射到一个特定的拓扑(有时由中间件[DR99]),选择需要的现成的(OTS)组件,并使用适当的orb实现的连接器体系结构。

图5中展示了一个简单的示例来说明这一策略。系统的概念架构图显示在顶部位置上。在这种情况下，C2风格规定信息仅通过连接器实现上下流动（例如Compl与Comp3不能直接交互而Compl与Comp2可以）。假设我们希望将体系结构中的组件绑定到特定的中间件，并将其实施分发到三个不同的位置上。中间图表展示了得到的解决方案：单个ORB保证其关联组件的跨机器交互能力但未考虑样式所施加的拓扑结构与交互约束限制。此外需要注意的是如果这四个组件没有都基于相同的基础设施（例如CORBA）那么工程师们将不得不依赖现有的点状解决方案或者自行构建中间件间桥梁作为另一个独立的点状方案（可能是一个临时性的或非正式性的解决方案）。

2.In the interest of simplicity, and as is commonly done in literature, we will refer to the different interaction facilities provided by middleware as “ORBs” in the remainder of this section.
2.为了简单起见，就像通常在文献中所做的那样，我们将在本节的其余部分中把中间件提供的不同交互工具称为“orb”。

Our approach, depicted on the bottom of Figure 5, enables a more principled way of integrating architectures and middleware. The approach also allows bridging middleware, i.e., the interaction of components adhering to different middleware standards (e.g., CORBA and COM). We keep connectors an explicit part of a system’s implementation infrastructure, as discussed in the context of Figure 2. Each component thus only exchanges information with a connector to which it is attached; in turn, the connector will (re)package that information and deliver it to its recipients using one or more middleware technologies. Each such “middleware enabled” connector is a variant of a standard connector (recall Figure 2); it changes the underlying mechanism for marshalling and delivering messages, but externally appears unchanged. This approach minimizes the ffects on a given component of varying application deployment profiles and of using components that adhere to heterogeneous middleware standards. Note that, unlike the “middlewareonly” solution shown in the middle diagram, the bottom diagram of Figure 5 also preserves the topological and stylistic constraints of the application. Furthermore, the connector allows Compl and Comp2 to interact efficiently, using the in-process (i.e., C2 implementation framework) mechanisms while, at the same time, interact-ing with Comp3 and Comp4 using the inter-process (i.e., OTS middleware) mechanisms.
图5底部所示的方法支持一种更有原则的集成体系结构和中间件的方法。该方法还允许桥接中间件，即遵循不同中间件标准(如CORBA和COM)的组件之间的交互。我们将连接器作为系统实现基础结构的一个显式部分，如图2所示。因此，每个组件只与它所连接的连接器交换信息;反过来，连接器将(重新)打包该信息，并使用一个或多个中间件技术将其传递给它的接收者。每个这样的“启用了中间件”的连接器都是标准连接器的变体(回想图2);它改变了编组和传递消息的底层机制，但在外部看起来没有改变。这种方法最大限度地减少了对不同应用程序部署配置文件的给定组件和使用遵循异构中间件标准的组件的影响。注意，与中间图中显示的“仅middlewareonly”解决方案不同，图5的底部图还保留了应用程序的拓扑和风格约束。此外，连接器允许Compl和Comp2有效地交互，使用进程内的(即。同时，与Comp3和Comp4使用进程间(即进程间)交互 OTS中间件)机制。

_Figure 5. Achieving a software architecture (top) by employing middleware technology (middle) and an explicitly middleware-enabled software connector (bottom).
图5 通过采用中间件技术（中间）以及明确的、支持中间件的软件连接器（底部）实现了软件体系结构（顶部）。

We have crafted and employed two distinct techniques to enable us to utilize middleware within the context of an architecture, as illustrated in Figure 5. Each technique involves implementing a single conceptual software connector using two or more actual connectors that are linked across process or network boundaries via a given middleware technology. Consequently, each actual connector becomes a segment of a single "virtual connector." Access to the underlying middleware technology is entirely encapsulated within the abstraction effects of a given component, accommodating varying application deployment profiles and components that adhere to heterogeneous middleware standards. Notably, unlike the "middlewareonly" solution depicted in the middle diagram, the bottom diagram in Figure 5 preserves both the topological and stylistic constraints of the application. Furthermore, while Compl and Comp2 interact efficiently using in-process mechanisms (specifically through C2's implementation framework), this interaction is abstracted away from both architects and developers, as well as from the interacting components.

This technique is referred to as lateral welding. Its mechanism is illustrated in Figure 6's top diagram. Messages destined for any segment within a multi-process connector are distributed across all other segments through an intermediary middleware. Once a message is received, each segment assumes responsibility for filtering and forwarding it appropriately within its own process.

虽然横向焊接方法允许我们将C2应用程序分成垂直部分（如图6所示），但我们还开发了一种水平切分方法。这种方法类似于横向焊接的思想：一个概念性的连接器被分解为顶部和底部两部分，每一部分都表现出与连接在其上和下的组件的单个过程连接器相同的属性。但是段本身是使用适当的中间件连接的。这两种技术是使用五种不同的中间件技术实现的：ILU [施乐]、VisiBroker CORBA [Inpr]、RMI [太阳微电子]、Polylith [Pur94]和Q [MH096]。得到的连接器可以任意组合以支持任何部署配置文件或中间件平台。这种组合的动机是不同的中间件技术可能具有独特的优点。通过将多个此类技术组合到一个应用程序中，应用程序可以潜在地获得所有这些技术的好处。例如,RMI支持多种编程语言但仅兼容一个平台,可以通过与Q结合（Q支持多种语言但仅兼容一个平台）创建一个既支持多种编程语言又支持多种平台的应用程序

_Figure 6. Connectors serve as the principal medium for interprocess communication. A single conceptual connector may be partitioned either vertically at the top or horizontally at the bottom, depending on the requirements. The shaded ovals denote the boundaries of individual processes. One connector typically encapsulates an ORB, which is abbreviated here for brevity.]
图6 连接器是进程间通信的主要介质。单个概念连接器可能垂直（顶部）或水平（底部）进行划分以满足需求。阴影椭圆表示各个过程的边界。一个连接器通常封装一个ORB，在这里为了简洁起见进行了省略。

The advantages of integrating multiple middleware technologies within software architectures are numerous. In the absence of a universally applicable solution capable of supporting all required platforms, languages, and network protocols, leveraging several different middleware technologies can significantly expand the range of applications that can be implemented within a C2 architectural style. We believe that overcoming this challenge requires developing an inter-middleware bridge—essentially a mechanism for allowing two or more technologies to exchange data. Once this bridge is established, it becomes fully functional without requiring additional maintenance or updates. To validate this hypothesis, we integrated techniques such as lateral welding and horizontal slicing from Figure 6 into the KLAX application (referencing Figure 4), utilizing Xerox’s ILU and Java’s RMI middleware. A concrete example of our integration method is illustrated in Figure 7: our approach creates a three-process "virtual connection" using two in-process C2 connectors to link two multi-process connectors. If we had taken an alternative approach—such as creating a single implementation-level connector supporting both ILU and RMI—we could have achieved similar results. However, adopting our current compositional design provides greater flexibility while maintaining functional integrity. Although it introduces minor efficiency costs due to additional in-process connectors required for binding multi-process components, this trade-off aligns with our goal of achieving scalability and adaptability across diverse systems.

_Diagram 7 illustrates an example of a three-processor C₂ application employing diverse middleware packages. A single virtual connector is realized through two process-intra and two process-multi connectors. The process-intra connectors are utilized to enable message communication among the process-multi connectors. Shaded ovals denote processor boundaries.
**图7 使用不同中间件包的三进程C₂应用程序的一个示例。单个虚拟连接器由两个进程内连接器和两个多进程连接器实现。进程内连接器促进了多进程连接器之间的消息传递。阴影椭圆表示流程边界。
**

Throughout all the demonstrated examples so far, the components have been considered homogeneous (i.e., they follow the same architectural approach, are implemented in a single language, and/or run on the same platform). Although various middleware employ diverse underlying mechanisms to facilitate component interactions, each middleware-enabled connector discussed above provides a message-based interface that C2 components can utilize. It is important to note that this does not signify an adoption of message-passing as a solution for software interoperability; instead, it reflects an effort to replace proprietary interaction mechanisms utilized by different middleware with our own. The methodology outlined above offers implementation power and flexibility in constructing connectors that enable interaction between heterogeneous components across various middleware platforms. Notably, isolating the inter-middleWare bridge within a connector remains crucial so that components on either side can function as if they are operating in a homogeneous environment (e.g., exclusively C2 or CORBA). For instance, one such connector we developed facilitates interaction between C2 and CORBA components. As illustrated in Figure 6's lower diagram, Compl and Comp3 represent C2 components while Comp2 and Comp4 are VisiBroker CORBA components; Compl and Comp3 assume they interact with other C2 components via a C2 connector, whereas Comp2 and Comp4 assume they interact with other CORBA components through an ORB.

Another aspect of heterogeneity is components' implementation across different languages. For instance, we employ Q to facilitate interaction between components developed in C++ and Ada. Specifically, within a KLAX application configuration (as shown in Figure 4), TileArtist is implemented in Ada, whereas other architecture elements are built using CY's C++ framework. The connectors on both ends of TileArtist utilize Q as a bridge between these two languages.

我们应该注意到这两个示例(分别是C₂和CORBASE之间的互操作性以及Ada和C++之间的互操作性)并未需要专门的解决方案而是我们所展示解决方案的简单变体图6中描述的解决方案是这一事实的一个简单变体

Figure 8. A middleware-enabled C2 connector is enabled by the integration of two middlewares, which are designed to facilitate communication between different middleware systems. 图8 启用中间件的C2连接器是通过两个中间件间的集成实现功能定位与数据交换需求的具体体现。

4. Conclusions

4. 结论

In ensuring interoperability stands as a pressing issue within the rapidly-evolving landscape of heterogeneous software components. Regrettably, the fact is that competing middleware vendors in a race for market dominance have inadvertently created incompatible, proprietary component and middleware standards. The present scenario can be likened to a 'component tower of Babel': components that 'speak' the same language are interoperable, whereas those that 'speak' different languages are not. While several technologies have been proposed and implemented as solutions bridging middleware platforms: COM-EJB [Ver99] and CORBA.COM [Con98 Gar99]. Although these pairwise solutions are directly dependent upon the characteristics of the involved middleware and provide little, if any, guidance as to how a similar outcome can be achieved with a different set of middleware platforms. Furthermore, although 'architecture' is an often-used term within the realm of middleware technologies, it remains unclear how developers might craft an appropriate architecture for their systems without relying on their implementation-level infrastructure alone. This singular approach also underscores the failure of middleware providers to acknowledge that their technologies impose certain stylistic constraints on component composition and interaction [DR99].

本文提出了一种可能纠正当前困境的方法。这种方法直接利用体系结构构造(样式和连接器)，并为桥接中间件问题提供了一个有原则的、可重复的解决方案。我们已经使用了商业(RMI, VisiBroker)和研究(ILU, Polylith, Q)OTS技术来测试我们的假设：即软件连接器是支持基于中间件实现架构设计的适当机制。到目前为止我们的结果非常令人鼓舞：请注意上面讨论的例子细节差异很大；然而，在所有这些示例中都使用了相同的基线集成技术（如图6和图8所示）。同时我们承认这些结果还不是最终结论；为了使这项工作更具普遍性并评估其真正适用范围还需要研究几个关键问题：

• 为了更好地掌握中间件技术的基础属性（包括共性和专有属性），我们需要开发出通用、可重用且具备潜在自动化能力的解决方案。
• 我们必须了解除了C2体系结构风格之外其他体系结构风格在支持中间件集成方面所施加的角色和限制。
• 最终我们还必须理解将此技术应用于连接器类型而不仅仅是消息传递时所面临的问题为此我们将利用我们最近的研究成果——软件连接器分类综述[MMPOO]——来实现这一目标

To address the issues identified above, our future work will aim to adopt a more comprehensive approach in investigating the role of middleware in implementing software architectures and exploiting architectural abstractions and mechanisms to enable cross-middleware interoperability. We have recently initiated a multi-institution project [MGROO] with three main objectives: enhancing our understanding of the relationship between middleware and software architectures [DR99], analyzing and categorizing the shared building blocks underlying all middleware platforms [KG98, KG99], and further exploring the role and limitations of software connectors in achieving general solutions to the problem of heterogeneous component-based development. A critical issue we must address is determining the extent to which our solutions must be pairwise (for instance, requiring N² inter-middleware connectors for N middleware technologies). Our initial findings, discussed in Section 3, indicate that it is feasible to provide compositional inter-middleware connectors such that pairwise solutions can be avoided. We intend to leverage our categorization of middleware services in constructing versatile connectors capable of accommodating multiple, arbitrarily chosen technologies simultaneously. Ideally, we would like to develop a single, general solution for each technology; after implementation, these solutions could be reused indefinitely even as new interoperability technologies are developed. We must also evaluate the tradeoffs between different cross-middleWare interoperability approaches (such as reliability, quality of service, and performance) that we investigate.

The benefits will derive from substantial quantities of legacy software available to users and a clear understanding of which components can be reused in applications across different scenarios. Building upon existing academic and industry efforts, this research could shape the next generation of interoperability standards and establish a foundation for a truly open component marketplace.

5. References

5. 参考文献

The Author Comments

注：本篇翻译的核心部分基于谷歌翻译，并适当辅以人工修改以优化语言表达。如有任何技术上的错误，请指出修正