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

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