On the Role of Middleware in Architecture-Based Software Development

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

Abstract

摘要

Software architectures promote development focused on modular functional building blocks (components), their interconnections (configurations), and their interactions (connectors). Since architecture-level components often contain complex functionality, it is reasonable to expect that their interactions will be complex as well. Middleware technologies such as CORBA, COM, and RMI, provide a set of predefined services for enabling component composition and interaction. However, the potential role of such services in the implementations of software architectures is not well understood. Furthermore, components adhering to one middleware standard cannot readily interact with those adhering to another. In order to understand the role and tradeoffs among middleware technologies in implementing architectures and enable component interoperability across middleware platforms, we have investigated a set of techniques and conducted case studies involving a particular architectural style, C2, and its implementation infrastructure. In particular, by encapsulating middleware functionality within C2’s explicit software connectors, we have been able to couple C2’s existing benefits such as component interchangeability, substrate independence, and structural guidance with new capabilities of multi-lingual, multi-process, and distributed application development in a manner that is transparent to architects. Furthermore, we have demonstrated the utility of our connector-based approach in enabling components implemented on top of different middleware platforms to interoperate. Though several details of our approach derive from the characteristics of the C2 style, we believe that a number of lessons learned are more generally applicable. We argue that these lessons can help form a broader research agenda for coupling the modeling power of software architectures with the implementation support provided by middleware.
软件体系结构促进了针对模块化功能构建块（组件），它们的互连（配置）及其交互（连接器）的开发。由于体系结构级组件通常包含复杂的功能，因此可以合理预期它们的交互也将是复杂的。诸如CORBA，COM和RMI之类的中间件技术提供了一组预定义的服务，以实现组件的组成和交互。但是，这种服务在软件体系结构的实现中的潜在作用尚未得到很好的理解。此外，遵守一种中间件标准的组件不能轻易地与遵守另一种中间件标准的组件交互。为了了解中间件技术在实现体系结构中的作用和折衷，并实现跨中间件平台的组件互操作性，我们研究了一组技术，并进行了涉及特定体系结构样式C2及其实现基础结构的案例研究。特别是，通过将中间件功能封装在C2的显式软件连接器中，我们能够将C2的现有优势（例如组件互换性，基材独立性和结构指导）与多语言，多过程和分布式应用程序开发的新功能结合在一起。对建筑师透明的方式。此外，我们已经展示了基于连接器的方法的实用性，它使在不同中间件平台上实现的组件能够互操作。尽管我们的方法的一些细节源于C2风格的特征，但我们认为许多经验教训更普遍适用。我们认为，这些课程可以帮助形成更广泛的研究议程，以将软件体系结构的建模功能与中间件提供的实施支持相结合。

1. Introduction

1. 介绍

The software systems of today are rapidly growing in number, sophistication, size, complexity, amount of distribution, and number of users. This information technology boom has been fueled by the increased affordability of hardware and the evolution of the Internet from a novelty gadget of the “technological elite” to a critical world-wide resource. As a result, the demand for software applications is far outpacing our ability to produce them, both in terms of their sheer numbers and their desired quality [Sta98]. Most notable about current software engineering practice is the continued preponderance of ad-hoc development approaches, driven by industry needs, commercial interests, and market pressures, rather than well-understood scientific principles. The magnitude of this situation has even been recognized at the highest levels of the U.S. Government, reflected in the recent President’s Information Technology Advisory Committee (PITAC) report [P99]. In particular, the PITAC report identified several issues of large-scale software development, including component-based development, software reuse, and software interoperability, as major software engineering challenges.
当今的软件系统在数量，功能，大小，复杂性，分布数量和用户数量方面都在迅速增长。信息技术的蓬勃发展，源于硬件价格的上涨以及Internet从“技术精英”的新颖小工具到关键的全球资源的演进。结果，就软件的绝对数量和所需的质量而言，对软件应用程序的需求远远超过了我们的生产能[Sta98]。当前软件工程实践中最值得注意的是，临时性开发方法的持续优势是由行业需求，商业利益和市场压力驱动的，而不是人们容易理解的科学原理。这种情况的严重性甚至已经在美国的最高水平得到认可。政府，反映在总统信息技术咨询委员会（PITAC）的最新报告[P99]中。特别是，PITAC报告确定了大规模软件开发的几个问题，其中包括基于组件的开发，软件重用和软件互操作性，这些都是主要的软件工程挑战。

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 research and development thrust, actively pursued in parallel with that on middleware, has been software development with an explicit focus on common architectural idioms [PW92, SG96, MTOO]. In particular, software architecture research is directed at reducing the costs and improving the quality of applications by shifting the development focus from lines-of-code to coarser-grained architectural elements
(components and connectors) and their overall interconnection structure (configurations). Additionally, architectures separate computation in a system (performed by components) from interaction among the components (facilitated by connectors). This enables developers to abstract away the unnecessary details and focus on the “big picture:” system-level structure and behavior, high-level communication protocols, component deployment, and so forth. Software architects also have at their disposal a number of architectural styles— collections of recurring structural, behavioral, and interaction patterns—with well-understood properties.
另一个与中间件并行进行的研究和开发方向是软件开发，它明确地关注常见的体系结构习惯用法[PW92, SG96, MTOO]。特别是，软件体系结构研究的目标是通过将开发重点从代码行转移到粗粒度的体系结构元素来降低成本和提高应用程序的质量(组件和连接器)及其整体互连结构(配置)。此外，体系结构将系统中的计算(由组件执行)与组件之间的交互(由连接器促进)分隔开来。这使开发人员能够抽象出不必要的细节，并将精力集中在“大局”上:系统级的结构和行为、高级通信协议、组件部署等等。软件架构师还可以使用大量的体系结构样式——重复出现的结构、行为和交互模式的集合——这些样式具有很好理解的属性。

Architectures and middleware address similar problems—large-scale, component-based development— but at different stages of the development lifecycle. While architecture is an early model of a system that highlights the system’s critical conceptual properties using high-level abstractions, middleware enables that system’s realization and ensures the proper composition and interaction of the implemented components. Most existing architecture modeling and analysis approaches have suffered from the inability to map architectural decisions to the system’s implementation in an automated and property-preserving manner [MTOO]. At the same time, software development based purely on middleware can, in many ways, be regarded as the “assembly programming” of software composition [OMTR98]: a middleware technology provides no support for determining the application’s structure and behavior, selecting the needed components, or interconnecting the components into the desired topologies.
体系结构和中间件处理类似的问题——大规模的、基于组件的开发——但是在开发生命周期的不同阶段。虽然体系结构是使用高级抽象强调系统关键概念属性的系统的早期模型，但是中间件支持系统的实现，并确保实现的组件的适当组合和交互。大多数现有的体系结构建模和分析方法都无法以一种自动化的、保留属性的方式将体系结构决策映射到系统的实现中[MTOO]。同时,软件开发纯粹基于中间件,在许多方面,被视为软件组成的“汇编程序”[OMTR98]：一个中间件技术提供不支持确定应用程序的结构和行为,选择所需的组件,或连接组件所需的拓扑。

The relationship between the two areas and their respective shortcomings suggest the possibility of coupling architecture modeling and analysis approaches with middleware technologies in order to get “the best of both worlds.” Given that architectures are intended to describe systems at a high-level of abstraction, directly refining an architectural model into a design or implementation may not be possible. One reason is that the decision space rapidly expands with the decrease in abstraction levels: at the design level, constructs such as classes with attributes, operations, and associations, instances of objects collaborat-ing in a scenario, and so forth, are identified; the implementation further requires the selection and instantiation of specific data struc- Figure 1. The decision space grows as a system is refined from an architecture to an implementation. Middleware technologies can be employed to bound the implementation space and render the mapping from architecture to implementation more tractable.
tures and algorithms, interoperation with existing libraries, deployment of modules across process and machine boundaries, and so forth. One proposed solution to this problem has been to provide mechanisms for refining an architectural model into its implementation via a sequence of intermediate models [MQR95, LV95, RMRR98, AM99]. However, the resulting approaches have had to trade off the engineer’s confidence in the fidelity of a lower-level model to the higher-level one against the practicality of the adopted technique [MTOO]. Furthermore, to a large extent, the existing refinement approaches have failed to take advantage of a growing body of existing (implemented) components that may be reusable “as is.”
这两个领域之间的关系以及它们各自的缺点表明了将体系结构建模和分析方法与中间件技术耦合起来以获得“两全之利”的可能性。由于体系结构的目的是在抽象的高层次上描述系统，因此直接将体系结构模型细化为设计或实现可能是不可能的。一个原因是决策空间随着抽象级别的减少而迅速扩展:在设计级别，诸如带有属性、操作和关联的类、场景中对象协作的实例等构造被标识;进一步的实现需要选择和实例化特定的数据——图1。决策空间随着系统从架构到实现的细化而增长。可以使用中间件技术来绑定实现空间，并使架构到实现的映射更易于处理。设计和算法、与现有库的互操作、跨进程和机器边界的模块部署，等等。对此问题提出的一个解决方案是，通过一系列中间模型[MQR95、LV95、RMRR98、AM99]，提供将体系结构模型细化为其实现的机制。然而，由此产生的方法不得不在工程师对较低层次模型对较高层次模型的保真度的信心与所采用技术的实用性之间进行权衡[MTOO]。此外，在很大程度上，现有的细化方法未能利用不断增长的现有(实现的)组件，这些组件可以“按原样”重用。

Figure 1. The decision space grows as a system is refined from an architecture to an implementation. Middleware technologies can be employed to bound the implementation space and render the mapping from architecture to implementation more tractable.
图1 决策空间随着系统从架构到实现的细化而增长。可以使用中间件技术来绑定实现空间，并使架构到实现的映射更易于处理。

This paper pursues another strategy, depicted in Figure 1 . The goal is to bound the target (implementation) space to a specific, well-defined subspace by employing (a set of) middleware technologies. The paper presents a technique for exploiting a particular architectural construct, software connector, to achieve the desired result in a manner that minimizes the effect of the chosen middleware on the interacting components. Indeed, our approach enables, e.g., CORBA components to interact via, e.g., Java’s RMI in principle. We have conducted a series of case studies to validate our hypothesis. A specific architectural style, C2, has been used as the basis for this investigation [TMA+96, MRT99]. Our initial results are promising and indicate that a successful marriage of architecture- and middleware-based techniques and technologies is indeed possible. At the same time, this initial experience also points to certain deficiencies of basing our approach solely on connectors. We use these deficiencies as the motivation for a broader study of component-based development, interoperability, and the relationship between middleware and architectures. These issues comprise a research agenda that frames our future work.
本文采用另一种策略，如图1所示。目标是通过使用(一组)中间件技术将目标(实现)空间绑定到特定的、定义良好的子空间。本文介绍了一种利用特定的体系结构构造(软件连接器)来实现所需结果的技术，该技术以最小化所选中间件对交互组件的影响的方式实现。实际上，我们的方法在原则上支持CORBA组件通过Java的RMI进行交互。我们进行了一系列的案例研究来验证我们的假设。一个特定的建筑风格，C2，已经被用作这个调查的基础[TMA+96, MRT99]。我们的初步结果是有希望的，并表明基于架构和基于中间件的技术和技术的成功结合确实是可能的。与此同时，这一最初的经验也指出了仅仅基于连接器的方法的某些缺陷。我们利用这些缺陷作为更广泛地研究基于组件的开发、互操作性以及中间件和体系结构之间关系的动机。这些问题构成了一个研究议程，为我们未来的工作制定了框架。

The remainder of the paper is organized as follows. Section 2 provides a brief description of the C2 architectural style and the connectors it employs. Section 3 describes our approach to providing “middleware-enabled” connectors and discusses how those connectors are used to enable the interaction of components compliant with heterogeneous middleware. A discussion of lessons learned and future work rounds out the paper.
论文的其余部分组织如下。第2节简要描述了C2体系结构风格及其使用的连接器。第3节描述了我们提供“支持中间件的”连接器的方法，并讨论了如何使用这些连接器来支持与异构中间件兼容的组件的交互。对经验教训和未来工作的讨论使论文圆满结束。

2. Overview of the C2 Style

2. C2风格概述

We chose the C2 architectural style as a foundation upon which to initially explore the issues of integrating middleware with software architectures. The C2 style is a good fit for this task for several reasons. C2 has an explicit notion of software connectors as first-class entities that handle component interactions. The style provides facilities for exploring specific properties of connectors such as filtering, routing, and broadcasting, which are also typically provided by middleware. Further, the style is well-suited to a distributed setting, allowing us to leverage the networking capabilities of middleware technologies. C2 supports a paradigm for composing systems in which components may be running in a distributed, heterogeneous environment without shared address spaces, architectures may be changed dynamically, multiple users may be interacting with the system, multiple user interface toolkits may be employed, and multiple media types may be involved.
我们选择了C2体系结构风格作为基础，在此基础上初步探讨了中间件与软件体系结构集成的问题。C2样式非常适合这项任务，原因如下。C2将软件连接器明确定义为处理组件交互的一级实体。该样式为研究连接器的特定属性(如过滤、路由和广播)提供了工具，这些通常也是由中间件提供的。此外，该样式非常适合于分布式设置，允许我们利用中间件技术的网络功能。C2支持组合系统的范例，其中组件可以在分布式、异构的环境中运行，而不需要共享地址空间，架构可以动态更改，多个用户可以与系统交互，可以使用多个用户界面工具包，可以涉及多种媒体类型。

The C2 style can be informally summarized as a network of concurrent components hooked together by connectors. All communication among components in an architecture is achieved by exchanging messages via connectors. Message-based communication is extensively used in distributed environments for which C2 is suited. Each component may have its own thread(s) of control. This simplifies modeling and implementation of multi-component, multi-user, and concurrent applications and enables exploitation of distributed platforms. A proposed architecture is distinct from its implementation(s) so that it is indeed possible for components to share threads of control. The separation of architecture from implementation is a key aspect of our approach to integrating middleware technologies with C2, as discussed in Section 3. Finally, there is no assumption of a shared address space among C2 components. Any premise of a shared address space could be unreasonable in an architectural style that allows composition of heterogeneous, highly distributed components, developed in different languages, with their own threads of control, and internal architectures.
C2风格可以非正式地总结为由连接器连接在一起的并发组件网络。体系结构中组件之间的所有通信都是通过连接器交换消息来实现的。在适合C2的分布式环境中，广泛使用基于消息的通信。每个组件都有自己的控制线程。这简化了多组件、多用户和并发应用程序的建模和实现，并支持利用分布式平台。提出的体系结构与其实现是不同的，因此组件确实可以共享控制线程。体系结构与实现的分离是我们将中间件技术与C2集成的方法的一个关键方面，如第3节所述。最后，C2组件之间没有共享地址空间的假设。共享地址空间的任何前提在体系结构风格中都是不合理的，这种体系结构风格允许使用不同语言开发的异构、高度分布的组件，以及它们自己的控制线程和内部体系结构。

As already discussed, central to our approach are software connectors, architecture-level abstractions and facilities that bind components together into an architecture and facilitate their interactions [SG96]. Connectors manifest themselves in a software system as shared variable accesses, table entries, buffers, procedure calls, remote procedure calls (RPC), network protocols, pipes, and so on [SG96, MTOO]. In large, and especially distributed systems, connectors become key determinants of system properties, such as performance, resource utilization, global rates of flow, and security [MMPOO]. Abstracting and encapsulating interaction details within architectural connectors has shown a lot of promise in helping to address traditional software development challenges: scalability, distribution, concurrency, runtime adaptab
正如已经讨论过的，我们的方法的核心是软件连接器、体系结构级别的抽象和工具，它们将组件绑定到一个体系结构中，并促进它们之间的交互[SG96]。连接器在软件系统中表现为共享变量访问、表项、缓冲区、过程调用、远程过程调用(RPC)、网络协议、管道等[SG96, MTOO]。在大型系统中，尤其是分布式系统中，连接器成为系统特性的关键决定因素，例如性能、资源利用率、全局流率和安全性[MMPOO]。在体系结构连接器中对交互细节进行抽象和封装，在帮助解决传统软件开发挑战(可伸缩性、分发性、并发性、运行时适应性、代码移动性等)方面显示出了很大的潜力[SDK+95、SG96、AG97、OMT98、KM98]。ility, code mobility, and so forth [SDK+95, SG96, AG97, OMT98, KM98].

We have extensively employed connectors in our previous research to support software modeling, analysis, generation, evolution, reuse, and heterogeneity [TMA+96, MOT97, MT97, OMT98, MRT99]. In particular, connectors in the C2 style may be connected to any number of components as well as other connectors. A connector’s responsibilities include message routing, broadcast, and filtering. C2 connectors also support adaptation of messages to accommodate mismatched interfaces and interaction protocols [TMA+96, MOT97].
我们在之前的研究中广泛使用了连接器来支持软件建模、分析、生成、演化、重用和异构性[TMA+96, MOT97, MT97, OMT98, MRT99]。特别是，C2风格的连接器可以连接到任意数量的组件以及其他连接器。连接器的职责包括消息路由、广播和过滤。C2连接器还支持消息的适配，以适应不匹配的接口和交互协议[TMA+96, MOT97]。我们在之前的研究中广泛使用了连接器来支持软件建模、分析、生成、演化、重用和异构性[TMA+96, MOT97, MT97, OMT98, MRT99]。特别是，C2风格的连接器可以连接到任意数量的组件以及其他连接器。连接器的职责包括消息路由、广播和过滤。C2连接器还支持消息的适配，以适应不匹配的接口和交互协议[TMA+96, MOT97]。

To support implementation of C2-style architectures, we have developed an extensible framework of abstract classes for concepts such as components, connectors and messages, as shown in Figure 2. This framework is the basis of development and middleware integration in C2. 1 As we will discuss, the framework encapsulates all access to integrated middleware, ensuring that the use of middleware is transparent to an architect, and, indeed, to the implementor of a particular architecture. The framework, together with any employed middleware, directly enables the support for automatic (partial) application generation from an architecture in our DRADEL tool suite [MRT99]. The framework implements interconnection and message passing protocols. Components and connectors used in C2-style applications are subclassed from the appropriate abstract classes in the framework. This guarantees their interoperability, eliminates many repetitive programming tasks, and allows developers of C2 applications to focus on application-level issues. The framework supports a variety of implementation configurations for a given architecture: the entire resulting system may execute in a single thread of control, or each component may run in its own thread of control or operating system (OS) process. To date, the framework has been implemented in C++ and Java.
为了支持c2风格架构的实现，我们开发了一个可扩展的抽象类框架，用于组件、连接器和消息等概念，如图2所示。该框架是C2中开发和中间件集成的基础。正如我们将要讨论的，这个框架封装了对集成中间件的所有访问，确保中间件的使用对架构师是透明的，对特定体系结构的实现者也是透明的。该框架与任何已使用的中间件一起，直接支持从我们的DRADEL工具套件[MRT99]中的体系结构自动(部分)生成应用程序。该框架实现了互连和消息传递协议。在c2风格的应用程序中使用的组件和连接器是从框架中适当的抽象类派生出来的。这保证了它们的互操作性，消除了许多重复的编程任务，并允许C2应用程序的开发人员专注于应用程序级的问题。该框架支持给定体系结构的各种实现配置:整个结果系统可能在单个控制线程中执行，或者每个组件可能在自己的控制线程或操作系统(OS)进程中运行。到目前为止，该框架已经在c++和Java中实现。

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

Example C2-Style Application

C2-Style示例应用程序

An application that was extensively used in our investigation of middleware integration with C2 is a version of the video game KLAX. A description of the game is given in Figure 3. This particular application was chosen because game play imposes some real-time constraints on the application, bringing performance issues to the forefront. The architecture of the application is depicted in Figure 4. The components that make up the KLAX game can be divided into three logical groups. At the top of the architecture are the components that encapsulate the game’s state. The game state components respond to request messages and emitnotifications of internal state changes. Notification messages are directed to the next level, where they are received by both the game logic components and the artist components. The game logic components request changes of game state in accordance with game rules and interpret the change notifications to determine the state of the game in progress. The artist components also receive notifications of game state changes, causing them to update their depictions. Each artist maintains the state of a set of abstract graphical objects which, when modified, send state change notifications in the hope that a lower-level graphics component will render them on the screen. The GraphicsBinding component receives all notifications about the state of the artists’ graphical objects and translates them into calls to a window system. User events, such as a key press, are translated by GraphicsBinding into requests to the artist components.
在我们研究C2中间件集成时广泛使用的一个应用程序是视频游戏KLAX的一个版本。游戏的描述如图3所示。之所以选择这个特定的应用程序，是因为游戏对应用程序施加了一些实时约束，从而将性能问题暴露出来。应用程序的体系结构如图4所示。组成KLAX游戏的组件可以分为三个逻辑组。在架构的顶部是封装游戏状态的组件。游戏状态组件响应请求消息和内部状态更改的emitnotifications。通知消息被定向到下一层，在那里它们被游戏逻辑组件和艺术家组件接收。游戏逻辑组件根据游戏规则请求游戏状态的变化，并解释变化通知，以确定正在进行的游戏状态。美术师组件也会收到游戏状态变化的通知，这将导致他们更新自己的描述。每个艺术家维护一组抽象图形对象的状态，这些对象在被修改时发送状态更改通知，希望低级图形组件能够在屏幕上呈现它们。GraphicsBinding组件接收艺术家图形对象状态的所有通知，并将其转换为对窗口系统的调用。用户事件(如按键)通过GraphicsBinding转换为对artist组件的请求。

Figure 3. A screenshot and description of our implementation of the KLAX video game.
图3 一个屏幕截图和对我们实现的KLAX视频游戏的描述。

Figure 4. Conceptual C2 architecture for KLAX. Shaded ovals represent process/machine boundaries.
图4 KLAX的概念C2架构。阴影椭圆表示进程/机器边界。

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。

We used the deployment profile shown in Figure 4 to examine the issues in using middleware technologies to implement architectures, although a number of other deployments are clearly possible. Two KLAX implementations were built using the C++ and Java versions of the framework shown in Figure 2. A variation of the architecture shown in Figure 4 was also used as the basis of a distributed, multi-player KLAX application implemented using the Java framework. In this variation, each player executes a copy of KLAX on his own machine. A player competes against other game participants by issuing requests to a remote, central GameServer to, e.g., add an extra tile to a given player’s chute. The GameServer, in turn, notifies the appropriate players of the changes to their states in response to their opponent’s action.
我们使用图4所示的部署配置文件来检查使用中间件技术来实现体系结构的问题，尽管许多其他的部署显然是可能的。使用图2所示框架的c++和Java版本构建了两个KLAX实现。图4中所示的体系结构的变体还用作使用Java框架实现的分布式、多播放器KLAX应用程序的基础。在这个变体中，每个玩家在自己的机器上执行KLAX的一个副本。玩家通过向远程的中央游戏服务器发出请求来与其他游戏参与者竞争，例如，向给定的玩家的滑槽添加额外的瓦片。而GameServer则将相应的状态变化通知给相应的玩家，以响应对手的动作。

Performance of the different implementations of KLAX easily exceeds human reaction time if the ClockLogic component is set to use short time intervals. Although we have not yet tried to optimize performance, benchmarks indicate that the C++ framework can send 1200 simple messages per second when sending and receiving components are in the same process, with the Java framework being somewhat slower. In single-player KLAX, a keystroke typically causes 10 to 30 message sends, and a tick of the clock typically causes 3 to 20 message sends. The efficiency of message exchange across process and/or machine boundaries is a function of the underlying mechanism (i.e., middleware) used to implement the given inter-process/ machine connector.
如果将时钟逻辑组件设置为使用较短的时间间隔，KLAX的不同实现的性能很容易超过人类的反应时间。尽管我们还没有尝试优化性能，但基准测试表明，当发送和接收组件处于同一进程中时，c++框架每秒可以发送1200条简单消息，而Java框架的速度稍微慢一些。在单人游戏KLAX中，一个按键通常会导致10到30条消息发送，而时钟的滴答声通常会导致3到20条消息发送。跨进程和/或机器边界的消息交换效率是底层机制(即用于实现给定的进程间/机器连接器。

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实现的连接器体系结构。

A simple example that illustrates this strategy is shown in Figure 5. A conceptual architecture of a system is shown at the top. In this case, the C2 style mandates that information flow only up and down through the connector (e.g., Compl and Comp3 cannot directly interact, while Compl and Comp2 can). Assume we want to implement the architecture with components bound to a given middleware and to distribute the implementation over three locations. The middle diagram depicts the resulting solution: the single ORB ensures the cross-machine interaction of its attached components, but not the topological and interaction constraints imposed by the style. Also note that, if the four components are not all built on top of the same middleware infrastructure (e.g., CORBA), the engineers will depend on existing point solutions or will have to develop the needed intermiddleware bridge as yet another point (likely, ad-hoc) solution.
图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. Realizing a software architecture (top) using a middleware technology (middle) and an explicit, middlewareenabled software connector (bottom). *
图5 使用中间件技术(中间)和显式的、支持中间件的软件连接器(底部)实现软件体系结构(顶部)。

We have developed and used two different techniques that enable us to use middleware in the context of an architecture as outlined in Figure 5. Both of these techniques consist of 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. Each actual connector thus becomes a segment of a single “virtual connector.” All access to the underlying middleware technology is encapsulated entirely within the abstractioneffects 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-of a connector, meaning that it is unseen by both architects and developers, as well as the interacting components.
我们开发并使用了两种不同的技术，使我们能够在体系结构上下文中使用中间件，如图5所示。这两种技术都包括使用两个或多个实际连接器来实现单个概念软件连接器，这些连接器通过给定的中间件技术跨流程或网络边界进行链接。因此，每个实际连接器都成为单个“虚拟连接器”的一部分。所有对底层中间件技术的访问都完全封装在对不同应用程序部署配置文件的给定组件的抽象效果中，并使用遵循异构中间件标准的组件。注意，与中间图中显示的“仅middlewareonly”解决方案不同，图5的底部图还保留了应用程序的拓扑和风格约束。此外，连接器允许Compl和Comp2有效地交互，使用进程内的(即。同时，连接器的交互性，这意味着架构师和开发人员以及交互组件都看不到它。

We call the first approach “lateral welding.” It is depicted in the top diagram of Figure 6. Messages sent to any segment of the multi-process connector are broadcast to all other segments via the underlying middleware. Upon receiving a message, each segment has the responsibility of filtering and forwarding the message to components in its process as appropriate.
我们称第一种方法为“横向焊接”。它在图6的顶部图中进行了描述。发送到多进程连接器的任意段的消息通过底层中间件广播到所有其他段。在接收到消息后，每个段负责过滤消息并将消息转发给其流程中的组件。

While the lateral welding approach allows us to “vertically slice” a C2 application, we also developed an approach to “horizontally slice” an application, as shown in the bottom diagram of Figure 6. This approach is similar to the idea of lateral welding: a conceptual connector is broken up into top and bottom segments, each of which exhibits the same properties as a singleprocess connector to the components attached above and below it, respectively. However, the segments themselves are joined using the appropriate middleware. These two techniques have been implemented using five different middleware technologies: ILU [Xerox], VisiBroker CORBA [Inpr], RMI [Sun],Polylith [Pur94], and Q [MH096]. The resulting connectors are arbitrarily composable to support any deployment profile or middleware platform. The motivation for such a composition is that different middleware technologies may have unique benefits. By combining multiple such technologies in a single application, the application can potentially obtain the benefits of all of them. For instance, a middleware technology that supports multiple platforms but only a single language, such as RMI, could be combined with one that supports multiple languages but a single platform, such as Q, to create an application that supports both multiple languages and multiple platforms.
虽然横向焊接方法允许我们对C2应用程序进行“垂直切片”，但是我们也开发了对应用程序进行“水平切片”的方法，如图6的底部图所示。这种方法类似于横向焊接的思想:一个概念性的连接器被分解为顶部和底部两部分，每一部分都表现出与连接在其上和下的组件的单个过程连接器相同的属性。但是，段本身是使用适当的中间件连接的。这两种技术是使用五种不同的中间件技术实现的:ILU [Xerox]、VisiBroker CORBA [Inpr]、RMI [Sun]、Polylith [Pur94]和Q [MH096]。得到的连接器可以任意组合以支持任何部署配置文件或中间件平台。这种组合的动机是不同的中间件技术可能具有独特的优点。通过将多个此类技术组合到一个应用程序中，应用程序可以潜在地获得所有这些技术的好处。例如，一个中间件技术支持多种平台，但只有一种语言，如RMI，可以与一个支持多种语言但只有一个平台的技术(如Q)相结合，从而创建一个既支持多种语言又支持多种平台的应用程序。

Figure 6. Connectors as a primary vehicle for interprocess communication. A single conceptual connector can be “broken up” vertically (top) or horizontally (bottom) for this purpose. Shaded ovals represent process boundaries. Each connector encapsulates an ORB (elided for simplicity).
图6 连接器是进程间通信的主要工具。单个概念连接器可以垂直(顶部)或水平(底部)进行“分解”。阴影椭圆表示流程边界。每个连接器封装一个ORB(为简单起见省略)。

The advantages of combining multiple middleware technologies within software con- ILU-C2 Connector RM1-C2 Connector nectors are manifold. In the absence of a single panacea solution that supports all required platforms, languages, and network protocols, the ability to leverage the capabilities of several different middleware technologies significantly widens the range of applications that can be implemented within an architectural style such as C2. We believe that the key challenge is to develop the inter-middleware"bridge" to allow two or more technologies to exchange data; once the bridge is developed, it is usable indefinitely thereafter. We have tested this hypothesis by combining the lateral welding and horizontal slicing techniques from Fig-ure 6 to implement a single conceptual connector in the KLAX application (recall Figure 4) using Xerox’s ILU and Java’s RMI middleware. An example of this combined binding method is shown in Figure 7: our approach creates a three-process “virtual connector” using two in-process C2 connectors to bind two multi-process connectors. Note that an alternative approach would have been to create a single implementation-level connector that supported both ILU and RMI. However, the approach we adopted is compositional and, therefore, more flexible, with a slight efficiency cost due to the addition of in-process connectors to bind the multi-process connectors.
在软件con- ILU-C2连接器RM1-C2连接器连接器连接器内组合多种中间件技术的优点是多方面的。在缺乏支持所有所需平台、语言和网络协议的单一万能解决方案的情况下，利用几种不同中间件技术的能力可以显著地扩展可以在体系结构风格(如C2)中实现的应用程序的范围。我们认为，关键的挑战是开发中间件间的“桥梁”，允许两种或多种技术交换数据;这座桥一旦建成，就可以无限期地使用。我们将图6中的横向焊接和横向切片技术结合起来，在KLAX应用程序中实现了一个概念连接器，从而验证了这一假设(回忆一下图4)使用Xerox的ILU和Java的RMI中间件。这种组合绑定方法的一个示例如图7所示:我们的方法使用两个进程内C2连接器来绑定两个多进程连接器，从而创建一个包含三个进程的“虚拟连接器”。请注意，另一种方法是创建一个同时支持ILU和RMI的单一实现级连接器。然而，我们采用的方法是组合的，因此更加灵活，由于添加了进程内连接器来绑定多进程连接器，因此效率成本比较低。

Figure 7. An example of a three-process C2 application using different middleware packages. A single virtual connector is implemented with two in-process and two multi-process connectors. The in-process connectors facilitate message passing between the multiprocess connectors. Shaded ovals represent process boundaries.
图7 使用不同中间件包的三进程C2应用程序的一个示例。单个虚拟连接器由两个进程内连接器和两个多进程连接器实现。进程内连接器促进了多进程连接器之间的消息传递。阴影椭圆表示流程边界。

In all the examples shown thus far, the components have been treated as homogeneous (i.e., they adhere to the same architectural style, are implemented in a single language, and/or on top of the same platform). While the underlying mechanisms employed to enable the components’ interactions have varied, each middleware-enabled connector discussed above exports a message-based interface understood by C2 components. It is important to point out that this does not mean that we have adopted message-passing as the solution to the problem of software interoperability, replacing the proprietary interaction mechanisms employed by various middleware with one of our own. The approach described above provides the implementation power and flexibility to construct connectors that enable the interaction of heterogeneous components across middleware platforms. Again, the challenge is to isolate the inter-middleware bridge inside a connector, such that components on both sides of the connector can assume that they are still residing in a homogeneous (e.g., C2-only or CORBA-only) environment. One such connector we have constructed enables the interaction of C2 and CORBA components. So, for example, in the bottom diagram shown in Figure 6, Compl and Comp3 would be C2 components, while Comp2 and Comp4 are VisiBroker CORBA components; Compl and Comp3 assume that they are interacting with other C2 components via a C2 connector, while Comp2 and Comp4 assume that they are interacting with other CORBA components via an ORB.
在迄今所示的所有示例中，组件都被视为同构的(即它们坚持相同的体系结构风格，用单一语言实现，并且/或者在相同的平台上)。虽然用于支持组件交互的底层机制各不相同，但是上面讨论的每个支持中间件的连接器都导出了一个由C2组件理解的基于消息的接口。需要指出的是，这并不意味着我们已经采用消息传递作为软件互操作性问题的解决方案，用我们自己的消息传递机制替代各种中间件使用的专有交互机制。上面描述的方法提供了构建连接器的实现能力和灵活性，这些连接器支持跨中间件平台的异构组件交互。同样，挑战在于将中间件间的桥接隔离在一个连接器中，这样连接器两边的组件就可以假设它们仍然驻留在一个同构(例如，仅c2或仅corba)环境中。我们已经构建了一个这样的连接器，它支持C2和CORBA组件之间的交互。例如，在图6所示的底部图中，Compl和Comp3是C2组件，而Comp2和Comp4是VisiBroker CORBA组件;Compl和Comp3假设它们通过C2连接器与其他C2组件交互，而Comp2和Comp4假设它们通过ORB与其他CORBA组件交互。

Another aspect of heterogeneity is the components’ implementation in different languages. For example, we have used Q to enable the interaction among components written in C++ and Ada. Specifically, one configuration of the KLAX application (recall Figure 4) involved the TileArtist component implemented in Ada, while the rest of the architecture was implemented using CYs C++ framework. The connectors on top and bottom of TileArtist used Q to bridge the two languages.
异构的另一个方面是组件在不同语言中的实现。例如，我们使用Q来支持用c++和Ada编写的组件之间的交互。具体来说，KLAX应用程序的一个配置(回想一下图4)涉及到在Ada中实现的TileArtist组件，而架构的其余部分是使用CYs c++框架实现的。TileArtist顶部和底部的连接器使用Q来连接这两种语言。

We should note that these two examples (interoperability between C2 and CORBA, and Ada and C++, respectively) did not require specialized solutions, but were simple variations of our solution depicted in Figure 6. If we consider the C2 implementation framework to be a custom middleware platform for C2-style applications as argued by [DR99, YBB99], then the encapsulation of third-party ORBs inside C2’s connectors is nothing more than a composition of two or more inter-middleware bridges. For example, interoperability between C2 and CORBA is achieved by composing a a-CORBA bridge with a CORBA-C2 bridge, as depicted in Figure 8. Each such bridge (e.g., the top half of the figure) may be used independently as an inter-middleware connector. Furthermore, it is possible to invert the bridges such that, in the example shown in Figure 8, the underlying mechanism for CORBA component interaction is C2 message passing.
我们应该注意到这两个示例(分别是C2和CORBA之间的互操作性，以及Ada和c++之间的互操作性)并不需要专门的解决方案，而是图6中描述的解决方案的简单变体。如果我们认为C2实现框架是[DR99, YBB99]所主张的为C2风格的应用程序定制的中间件平台，那么在C2的连接器中封装第三方orb只不过是两个或多个中间件间桥的组合。例如，C2和CORBA之间的互操作性是通过将a-CORBA桥与CORBA-C2桥组合在一起来实现的，如图8所示。每个这样的桥(例如，图的上半部分)都可以作为中间件间的连接器独立使用。此外，可以对桥进行反向转换，这样，在图8所示的示例中，CORBA组件交互的底层机制就是C2消息传递。

Figure 8. A middleware-enabled C2 connector is a composition of two inter-middleware connectors.
图8 启用中间件的C2连接器是两个中间件间连接器的组合。

4. Conclusions

4. 结论

Ensuring interoperability is a critical issue in the quickly-emerging marketplace of heterogeneous software components. The unfortunate reality is that competing middleware vendors vying for market dominance have ended up constructing incompatible, proprietary component and middleware standards. The current situation can be characterized as a “component tower of Babel:” components “speaking” the same language are interoperable, while those “speaking” different languages are not. Although several technologies to bridge middleware platforms have been proposed and implemented (e.g., COM-EJB [Ver99] or CORBA.COM [Con98, Gar99]), these are usually pairwise solutions that 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 a frequently used term in the context of middleware technologies, middleware providers do not focus on guiding developers to achieve a suitable architecture for their systems, but rather propose a solution based solely around their implementation-level infrastructures. This “one size fits all” mentality is also reflected in the failure of middleware providers to acknowledge that their technologies impose certain stylistic constraints on component composition and interaction [DR99].
在异类软件组件快速发展的市场中，确保互操作性是一个关键问题。不幸的现实是，相互竞争的中间件供应商为了争夺市场主导地位，最终构建了不兼容的专有组件和中间件标准。当前的情况可以被描述为一个“巴别塔的组件”:“说”同一种语言的组件是互操作的，而那些“说”不同语言的组件则不是。尽管几种技术桥梁提出了中间件平台和实现(例如,COM-EJB (Ver99)或CORBA.COM [Con98 Gar99]),这些通常是成对的解决方案是直接依赖于中间件和提供小的特点,如果任何,指导如何实现一个类似的结果与一组不同的中间件平台。此外，尽管“体系结构”是中间件技术上下文中经常使用的一个术语，但是中间件提供者并不关注于指导开发人员为他们的系统实现一个合适的体系结构，而是仅仅基于他们的实现级基础设施提出一个解决方案。这种“一刀切”的心态也反映在中间件提供商的失败上，他们没有认识到他们的技术对组件的组成和交互施加了一定的风格约束[DR99]。

This paper has presented an approach that has the potential to remedy this situation. The approach directly exploits architectural constructs (styles and connectors) and provides a principled, repeatable solution to the problem of bridging middleware. We have employed sets of both commercial (RMI, VisiBroker) and research (ILU, Polylith, Q) OTS technologies to test our hypothesis that software connectors are the proper mechanisms for supporting middleware-based implementation of architectures. Our results to date are very promising: note that the details of the examples discussed above varied widely, yet the same basic integration techniques, shown in Figures 6 and 8, were used across all of them. At the same time, we acknowledge that these results are not definitive and that there are several issues that must be studied in order to render this work more general and assess the true extent of its applicability:
本文提出了一种可能纠正这种情况的方法。该方法直接利用体系结构构造(样式和连接器)，并为桥接中间件问题提供了一个有原则的、可重复的解决方案。我们已经使用了商业(RMI, VisiBroker)和研究(ILU, Polylith, Q) OTS技术来测试我们的假设，即软件连接器是支持基于中间件的架构实现的适当机制。到目前为止，我们的结果非常有希望:请注意，上面讨论的示例的细节差异很大，但是图6和图8所示的基本集成技术在所有这些示例中都得到了应用。与此同时，我们承认，这些结果并不是决定性的，为了使这项工作更具有普遍性并评估其适用性的真正程度，必须研究几个问题:

• We must have a better understanding of the underlying properties, both shared and proprietary, of middleware technologies in order to provide general, reusable, potentially automatable solutions.
• We must understand the role of and constraints imposed by architectural styles other than C2 in enabling middleware integration.
• Finally, we must understand the issues in applying this technique to connector types beyond message passing. To this end, we intend to leverage our recent work that has resulted in a comprehensive taxonomy of software connectors [MMPOO].
•为了提供通用的、可重用的、潜在的自动化解决方案，我们必须更好地理解中间件技术的基础属性(共享的和专有的)。
•我们必须理解除了C2之外的体系结构风格在支持中间件集成方面所施加的角色和约束。
•最后，我们必须理解在将此技术应用于连接器类型而不仅仅是消息传递时存在的问题。为此，我们打算利用我们最近的研究成果，对软件连接器进行全面分类[MMPOO]。

To address the issues identified above, our future work will involve a more comprehensive approach to investigating the role of middleware in implementing software architectures and exploiting architectural abstractions and mechanisms to enable cross-middleware interoperability. We have initiated a multi-institution project [MGROO] with three facets: improving our understanding of the relationship between middleware and software architectures [DR99], analyzing and codifying the underlying building blocks common to 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 the extent to which our solutions must be pairwise (in the sense of, for example, requiring N2 inter-middleware connectors for N middleware technologies). Our initial results, discussed in Section 3, indicate that it is possible to provide compositional inter-middleware connectors such that pairwise solutions can be avoided. We intend to leverage our codification of middleware services in constructing general connectors that can accommodate multiple, arbitrarily chosen technologies at once. Ideally, we would be able to provide a single, general solution for each technology; the solutions would be reusable indefinitely thereafter, even as new interoperability technologies are defined. We must also evaluate the tradeoffs (such as reliability, quality of service, and performance) between the different cross-middleware interoperability approaches that we investigate.
为了解决上述问题，我们未来的工作将涉及一个更全面的方法来研究中间件在实现软件架构和利用架构抽象和机制来支持跨中间件互操作性中的作用。我们启动了一个多项目[MGROO]有三个方面:改善我们之间的关系的理解中间件和软件架构(DR99),共同分析和编纂底层构件中间件平台(KG98, KG99),并进一步探索软件连接器的作用和局限在实现异构问题的基于组件的开发的通用解决方案。我们必须解决的一个关键问题是我们的解决方案必须两两配对的程度(例如，对于N个中间件技术，需要N2个中间件间连接器)。我们在第3节中讨论的初步结果表明，可以提供组成中间件之间的连接器，这样就可以避免成对的解决方案。我们打算利用中间件服务的编码来构建通用连接器，这些连接器可以同时容纳多种任意选择的技术。理想情况下，我们能够为每种技术提供单一的通用解决方案;此后，即使定义了新的互操作性技术，解决方案也可以无限地重用。我们还必须评估我们所研究的不同的跨中间件互操作性方法之间的权衡(例如可靠性、服务质量和性能)。

The benefits of this work will accrue from large amounts of legacy software at one’s disposal and the knowledge of what (types of) components can be (re)used in an application and under what circumstances. In turn, in tandem with related academic and industry-led work, this research has the potential to influence the next generation of interoperability standards and provide the underpinning of a true, open component marketplace.
这项工作的好处将从大量的遗留软件中积累起来，这些遗留软件可以由您随意处理，并且了解在应用程序中可以(重新)使用哪些(类型)组件，以及在什么情况下使用这些组件。反过来，与相关的学术和行业主导的工作相结合，这项研究有可能影响下一代互操作性标准，并为一个真正的、开放的组件市场提供基础。

5. References

5. 参考文献

The Author Comments

Note: the main body of this translation USES Google Translation , and appropriate supplemented by manual modification.if there is any mistake, please point out.
注:本篇翻译主体采用谷歌翻译，并适当辅以人工修改调整。如有错误，敬请指出。