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

论文研读 专栏收录该内容
1 篇文章 0 订阅

On the Role of Middleware in Architecture-Based Software Development





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.

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.

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.

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.”
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. 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.

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.

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.
Figure 2. C2 implementation framework.
图2 C2的实现框架。

Example C2-Style Application


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.
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.

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.

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.

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.

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.

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.

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.

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].

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.

  • 3
  • 0
  • 3
  • 打赏
  • 扫一扫,分享海报

©️2022 CSDN 皮肤主题:鲸 设计师:meimeiellie 返回首页


Mr. 鹏


¥2 ¥4 ¥6 ¥10 ¥20
余额支付 (余额:-- )



钱包余额 0