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.
注:本篇翻譯主體採用谷歌翻譯，並適當輔以人工修改調整。如有錯誤，敬請指出。