Hybrid Service-Oriented Architectures: A Case-Study in the Automotive Domain Luciano Baresi, Carlo Ghezzi, Antonio Miele, Matteo Miraz, Andrea Naggi, Filippo Pacifici Dipartimento di Elettronica e Informazione - Politecnico di Milano Piazza Leonardo da Vinci 32 I-20133 Milano, Italy ghezzi@elet.polimi.it ABSTRACT Vehicles are becoming complex software systems with many components and services that need to be coordinated. Ser- vice oriented architectures can be used in this domain to sup- port intra-vehicle, inter-vehicles, and vehicle-environment services. Such architectures can be deployed on different platforms, using different communication and coordination paradigms. We argue that practical solutions should be hy- brid: they should integrate and support interoperability of different paradigms. We demonstrate the concept by inte- grating Jini, the service-oriented technology we used within the vehicle, and JXTA, the peer to peer infrastructure we used to support interaction with the environment through a gateway service, called J2J. Initial experience with J2J is illustrated. 1. INTRODUCTION Vehicles are becoming complex software systems where many different components and services need to be properly coordinated [5]. Consider, for example, the large number of intra-vehicle features that must be controlled and coordi- nated, such as wheels, brakes, injection control, ABS system, and other subsystems and accessories, including climate con- trol, HI-FI, and GPS. Furthermore, advances in network- ing technologies are now adding complexity (and new chal- lenges), by allowing vehicles to communicate and coordinate their behaviors with the external environment and with the other vehicles in proximity. Vehicles may also be viewed as carriers of services, e.g., providing information on the traffic encountered during their journey to other vehicles, or inter- acting with the environment, which might provide location aware services to the people in the vehicle. Both intra-vehicle, inter-vehicles, and vehicle-environment interactions require flexibility and, possibly, some degrees of self-configuration. Intra-vehicle (IV) interactions must deal with the many configurations of modern vehicles and also with the mobile devices that might be used in the car. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SEM 2005 September 2005 Lisbon, Portugal Copyright 2005 ACM 1-59593-204-4/05/09 ...$5.00. Although components do not vary frequently, we cannot envisage software architectures where the communications among components are hard-wired. The different configura- tions would lead to a very complex architecture with many different variants. Inter-vehicles and vehicle-environment (also called, extra- vehicle —EV) interactions consider the different vehicles (and the environment) as components of a dynamic feder- ation, which supply and require services. Service suppliers and requestors are not fixed nor predefined, but can join and leave the federation dynamically. In this context, it is not only a problem of understanding who is “alive” out of a predefined set (i.e., the mandatory elements and additional components that can be operated on a vehicle), but avail- able features can change with the context and thus need to be discovered, negotiated, and bound dynamically. Dynamism, flexibility, and self-organization are the key features of service-oriented architectures (SoAs) [2]. A SoA is a software architecture where available services are ad- vertised through brokers, clients can discover and negotiate them, and the binding between clients and providers can be set in flexible ways, e.g., dynamically. This solution works for both IV and EV interactions. In the first case, it helps discover the features installed in the vehicle and configure them. In the second case, since services change with the context, discovery and negotiation capabilities help identify available components and set proper federations. The investigation of SoAs in the automotive domain — both at the IV and the EV level— is one of the main research goals of our participation to the EU research project called SeCSE (Service Centric System Engineering, [7]) whose goal —among others— is to investigate the use of SoAs in the automotive domain. In order to use it as a guideline for development, the general idea must be refined into detailed design and implementation guidelines. We argue that in do- ing so we do not force software architects to follow a uniform style and adopt a single middleware technology. Rather, we aim at designing hybrid solutions, where services are sup- plied through different interaction paradigms and middle- ware systems. For example, interactions within the vehi- cle and between vehicles and the environment may require different solutions. Within a vehicle, we can adopt a mid- dleware solution that is based on some shared centralized components. As we move to EV features, we must fore- see a decentralized organization where services are suitably replicated to improve their availability. Moreover, the de- gree of reliability is higher in the vehicle than in the open 62