ABSTRACTSoftware architectures promote development focused on modularfunctional building blocks (components), their interconnections(configurations), and their interactions (connectors). Since archi-tecture-level components often contain complex functionality, it isreasonable to expect that their interactions will be complex as well.Middleware technologies such as CORBA, COM, and RMI, pro-vide a set of predefined services for enabling component composi-tion and interaction. However, the potential role of such services inthe implementations of software architectures is not well under-stood. Furthermore, components adhering to one middleware stan-dard cannot readily interact with those adhering to another. In orderto understand the role and tradeoffs among middleware technolo-gies in implementing architectures and enable component interop-erability across middleware platforms, we have investigated a setof techniques and conducted preliminary case studies involving aparticular architectural style, C2, and its implementation infrastruc-ture. In particular, by encapsulating middleware functionalitywithin C2’s explicit software connectors, we have been able tocouple C2’s existing benefits such as component interchangeabil-ity, substrate independence, and structural guidance with new capa-bilities of multi-lingual, multi-process, and distributed applicationdevelopment in a manner that is transparent to architects. Further-more, we have demonstrated the utility of our connector-basedapproach in enabling components implemented on top of differentmiddleware platforms to interoperate. Though several details ofour approach derive from the characteristics of the C2 style, webelieve that a number of lessons learned are more generally appli-cable. We argue that these lessons can help form a broader researchagenda for coupling the modeling power of software architectureswith the implementation support provided by middleware.1 INTRODUCTIONThe software systems of today are rapidly growing in number,sophistication, size, complexity, amount of distribution, and num-ber of users. This information technology boom has been fueled bythe increased affordability of hardware and the evolution of theInternet from a novelty gadget of the “technological elite” to a crit-ical world-wide resource. As a result, the demand for softwareapplications is far outpacing our ability to produce them, both interms of their sheer numbers and their desired quality [Sta98].Most notable about current software engineering practice is thecontinued preponderance of ad-hoc development approaches,driven by industry needs, commercial interests, and market pres-sures, rather than well-understood scientific principles. The magni-tude of this situation has been recognized and is reflected in therecent U.S. President’s Information Technology Advisory Com-mittee (PITAC) report [P99]. In particular, the PITAC report iden-tified several issues of large-scale software development, includingcomponent-based development, software reuse, and softwareinteroperability, as major software engineering challenges.These issues have been extensively explored in the past decade,resulting in numerous commercial component interoperability ormiddleware technologies that have been adopted as de facto stan-dards (e.g., CORBA [OHE96], (D)COM [Ses97], OLE [Cha96],ActiveX [Cha96], Enterprise JavaBeans (EJB) [FFCM99], JavaRMI [Sun], DCE [Sch93], SoftBench [Cag90], ToolTalk [JH93]),as well as a number of widely-studied, research-oriented middle-ware technologies (Q [MHO96], Field [Rei90], Polylith [Pur94],JEDI [CDF98], SIENA [CRW01]). One can use any one of thesetechnologies to develop software systems from existing compo-nents more quickly and reliably than was generally possible in thepast. Yet ironically, the proprietary nature of these middlewaretechnologies has served to hinder interoperability between compo-nents developed according to different technologies. For example,the developers of COM components must modify or reimplementthose components for use in a system based on CORBA. More-over, even components implemented using different flavors ofCORBA may not be interoperable (although this problem has beenaddressed for more recent versions of CORBA via its IIOP proto-col). The result is a highly fragmented software component mar-ketplace that ultimately impedes the ability of softwareorganizations to develop systems with the highest possible qualityand reliability, at the lowest possible cost. Another problem areahas been the training of software engineers in the principles ofcomponent-based software development: it is currently mired inthe details and peculiarities of a few chosen technologies, insteadof focusing on underlying common principles and mechanisms.Another research and development thrust, actively pursued in par-allel with that on middleware, has been software development withan explicit focus on common architectural idioms [PW92, SG96,MT00]. In particular, software architecture research is directed atreducing the costs and improving the quality of applications byshifting the development focus from lines-of-code to coarser-grained architectural elements (components and connectors) andtheir overall interconnection structure (configurations). Addition-On the Role of Middleware inArchitecture-Based Software DevelopmentNenad MedvidovicComputer Science DepartmentUniversity of Southern CaliforniaLos Angeles, CA 90089-0781, [email protected] to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copiesare not made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, or republish, to post on servers or to redistribute to lists,SEKE '02, July 15-19, 2002, Ischia, Italy.Copyright 2002 ACM 1-58113-556-4/02/0700...$5.00.- SEKE '02 - 299 -ally, architectures separate computation in a system (performed bycomponents) from interaction among the components (facilitatedby connectors). This enables developers to abstract away theunnecessary details and focus on the “big picture:” system-levelstructure and behavior, high-level communication protocols, com-ponent deployment, and so forth. Software architects also have attheir disposal a number of architectural styles—collections ofrecurring structural, behavioral, and interaction patterns—withwell-understood