Tailoring an Architectural Middleware Platform to a Heterogeneous Embedded Environment Sam Malek Chiyoung Seo Nenad Medvidovic Computer Science Department University of Southern California Los Angeles, CA 90089-0781 U.S.A. {malek,cseo,neno}@usc.edu Abstract • A communication port on a component may be implemented as Embedded systems are rapidly growing in size, complexity, distri- an explicit PL-level interface (again, perhaps with different bution, and heterogeneity. As a result, the traditional practice of properties from those intended in the architecture-level port, developing one-off embedded applications that are often rigid and such as bi-directionality) or simply as an ungrouped set of meth- unmanageable is no longer acceptable. Recent studies have sug- od declarations. gested that an effective approach to developing software systems in •An event may be supported directly in a middleware as a mes- this domain is to employ the principles of software architecture. sage, or it may be mimicked via a method call or even shared However, for software architectural concepts to be truly useful in a memory. development setting, they must be accompanied by support for •A connector may be distributed (and thus “lost”) across different their implementation and evolution. This has motivated our work implementation-level modules as a combination of method over the past several years on an architectural middleware, called calls, shared memory, network sockets, and other facilities. Prism-MW, that provides implementation-level support for the • Finally, a given architectural style (e.g., publish-subscribe or development of software systems in terms of the software architec- peer-to-peer) may not be supported at all, but rather at best mim- tural constructs (e.g., components, connectors). Prism-MW was icked, and at worst ignored, by the style (e.g., client-server) as- initially developed in Java and used in several domains. Recently, sumed by the middleware. as part of an on-going project, we were required to implement Ample experience demonstrates that software engineers have Prism-MW in ANSI C++. This experience proved to be more chal- clearly “made do” with the existing middleware facilities, building lenging than we initially anticipated, mainly due to the inherent many successful systems. However, an argument can also be made heterogeneity of the computing substrate. As a result of this experi- that it is precisely this “abstraction chasm” between design and im- ence, we had to reconsider some of our earlier assumptions of what plementation that is a significant cause of architectural erosion constitutes an architectural middleware and its role in the software [13]. Architectural erosion denotes the (frequent) situation in which development process. In this paper, we provide an overview of our a system’s implementation departs from, or even invalidates, key experience and the lessons we have learned along the way. architectural design decisions. 1. Introduction Our hypothesis has been that we can significantly reduce archi- Over the past several years, our research group has conducted work tectural erosion by bridging the abstraction chasm and, in turn, that in the area of architectural middleware [6,9,10,12]. We define ar- we can bridge the chasm by providing an architectural middleware chitectural middleware as a middleware platform that provides im- platform. As a proof-of-concept, we developed such a platform, plementation-level constructs for key architectural abstractions called Prism-MW [6,9,10,12]. Prism-MW was initially implement- [13,15]: components, connectors, ports, events, styles, and so forth. ed, evaluated, and used primarily in Java (both JVM and KVM). The objective behind architectural middleware is clear: software de- However, different subsets of it were also implemented in Embed- velopers have embraced these architectural abstractions as powerful ded Visual C++ (EVC++), Python, C#, and Brew. The Java version design-level tools, but are typically forced by existing technologies in particular was evaluated extensively in the laboratory setting for to realize them using a different set of implementation-level tools. a number of properties of interest, including efficiency, scalability, Thus, while engineers may prefer to think of systems in terms of dynamic adaptability, and portability [6,12]. Prism-MW was used high-level abstractions such as components, connectors, styles, and in several domains: desktop applications, handheld computing, data so on, they are often forced to implement them in terms of low-level grids, and embedded systems [6,8,10]. constructs such as methods, arrays, linked lists, and so on. Based on this experience, we felt confident in our understand- A programming language (PL) or middleware platform may ing of architectural middleware and in Prism-MW’s applicability to provide support beyond such low-level constructs, but typically additional domains. So, when engineers from the Bosch Research they are insufficient to fully realize architecture-level decisions [6]. and Technology Center (RTC) approached us with the idea of using For illustration, consider the following examples. our work in one of their heterogeneous, distributed embedded sys- tems, we were optimistic that Prism-MW was the right solution. Af- • A software component may in fact be implemented as a middle- ter all, we “only” had to reimplement our design in ANSI C++, and ware-level component (though perhaps with different properties, we already had the EVC++ implementation as a baseline. such as lack of support for required interfaces), or simply as a cluster of PL-level classes. Unfortunately, things did not go that smoothly. The application domain and computing environment (including the PL) to which we were porting Prism-MW turned out to be very different from those strained applications. Orbix/E provides the ability to choose a sub- we had faced in the past. A lot of the facilities on which we had set of features for a given application in order to optimize its size come to rely, and which we got “for free” in Java (and even and speed. EVC++) and on the platforms we had employed (e.g., Compaq’s ACE [14] is an object-oriented framework that implements PocketPC), were no longer present. In this new setting, we had to many core patterns for concurrent communication software. The custom-build many of those facilities (e.g., data serialization, sock- patterns and components in the ACE framework have been applied et-based communication), and develop several low-level utilities in the ACE ORB (TAO), which is a CORBA-compliant middleware (e.g., memory management, thread synchronization) to abstract framework. TAO allows clients to invoke operations on distributed away the heterogeneity of the computing substrate. Even then, port- objects without concern for object location, PL, OS platform, com- ing Prism-MW posed a number of added challenges, at least in part munication protocols, or hardware. due to the inherent trade-off between the two desired characteristics JXTA [4] is a set of open protocols that allow any connected of a middleware for the embedded systems domain: supporting het- device on the network, ranging from cell phones and wireless PDAs erogeneous target platforms and achieving efficiency. to PCs and servers, to communicate and collaborate in a peer-to- This experience forced us to reassess what an architectural mid- peer manner. JXTA peers create a virtual network where any peer dleware is, what facilities it must provide, and which of those facil- can interact with other peers and resources directly, even when ities are “more architectural” vs. “more middleware”. As a result, some of the peers and resources are behind firewalls or on different we have developed a much more nuanced understanding of Prism- network transports. JXTA supports multiple platforms and languag- MW, and believe that the insights we have gained can also help us es, and ensures secure communication of collaborating peers. in formulating a generally applicable reference architecture for ar- Jini network technology [17] is an open architecture that ena- chitectural middleware platforms. As a side benefit, we can now bles developers to create network-centric hardware or software better relate Prism-MW, and other similar technologies, to tradi- services that are highly adaptive to change. The Jini architecture tional middleware platforms, as well as to related infrastructure specifies a way for clients and services to discover each other and concepts such as software libraries and frameworks. to collaborate across the network. When a service joins a Jini net- The remainder of the paper is organized as follows. Section 2 work, it advertises itself by publishing an object that implements the discusses the related work in the areas of architecture-based devel- service API. A client finds services by looking for an object that opment and middleware for embedded systems. Section 3 provides supports the API. When the client gets the service’s published ob- a brief overview of Prism-MW. Section 4 presents our experience ject, it will download any code it needs in order to communicate in developing a family of sensor network applications on top of with the service, thereby learning how to “talk” to the particular Prism-MW in collaboration with Bosch, with a particular focus on service implementation via the API. the changes this imposed on the middleware itself. Finally, Section XMIDDLE [7] is a data-sharing middleware for mobile com- 5 discusses the lessons we have learned from this experience. puting. XMIDDLE allows applications to share data that are encod- ed as XML with other hosts, to have complete access to the shared 2. Related Work data when disconnected from the network, and, when possible, to At a very high-level the related literature can be classified into two reconcile any changes made with all the hosts sharing the data. The categories: technologies specifically targeted at supporting imple- goal is to make sure that eventually all hosts will have a consistent mentation of software architectures, and middleware platforms for version of the shared data.