Product Lines that supply other Product Lines: A Service-Oriented Approach Salvador Trujillo IKERLAN Research Centre Mondragon, Spain strujillo@ikerlan.es Christian Kästner University of Magdeburg Magdeburg, Germany ckaestne@ovgu.de Sven Apel University of Passau Passau, Germany apel@uni-passau.de Abstract A software product line is a family of software products that share a set of core assets with the goal of reuse. In this paper, we focus on a scenario in which different products from different product lines are combined together in a third product line to yield more elaborate products, i.e., a prod- uct line consumes products from third product line suppli- ers. The issue is not how different products can be produced separately, but how they can be combined together. We pro- pose a service-oriented architecture, in which product lines are regarded as services, yielding a service-oriented prod- uct line. This paper illustrates the approach with an ex- ample for a service-oriented architecture of a web portal product line supplied by portlet product lines. 1. Introduction The goal of a software product line is to produce a set of distinct but similar products. Typically, this is achieved by reusing a common product line infrastructure, which con- sists not only of traditional reusable software (e.g., code, models, documentation, etc), but contains product line spe- cific assets as well (e.g., feature model, production plan, product line architecture, etc). Currently, product lines in software development are tar- geted primarily at producing software products that are used in isolation. They can depend on third-party software (e.g., operating system, embedded system, or web container), but this third-party software is usually regarded as fixed because it is considered to be part of the execution environment. So, they do not depend on other software developed by third- party product lines. Service-oriented architecture (SOA) is a novel paradigm that may change this scenario. Typically, an SOA appli- cation comprises a set of third-party services, which may be distributed. Each of such services supplies some spe- cific functionality, and all together complete the distributed application functionality (i.e., the web services with fine- grained functionality are combined together to serve an ap- plication with coarse-grained functionality). SOA promotes services to be easily consumed by diverse applications be- cause the discovery and consumption of services are stan- dardized. The usefulness of SOA rests on existing standard- ization efforts and tooling [16]. Reusing services can be further ameliorated by creating a product line that satisfies diverse variability requirements from different customer applications (e.g., a product line of customized portlets for customer portals where existing techniques are used [10, 18]). This way, not only the ap- plication interface is customized by using standards to con- sume supplied services, but also the application function- ality is customized by using product lines of supplied ser- vices. However, the entire SOA application itself could require its customization (e.g., not only is each portlet customized from a product line, but the portal as well). When the SOA application itself turns into a product line, a new scenario emerges. This scenario requires that a product line con- sumes products that are supplied from third-party product lines. We call such scenario a service-oriented product line (SOPL). Such situations are well-known in real industrial assem- bly lines. Consider a carmaker with an assembly line (e.g., from the chassis to the end-product) where third-party sup- plied components provided by other product lines are as- sembled together. These non-trivial components are the en- gine, the gear, the front-end, etc., which are also customized products of other product lines. In this case, there is a prod- uct line of cars that is supplied by other product lines of components. Although this context seems futuristic for traditional software at first, it occurs for example when developing software for consumer electronics (e.g., several components like a TV receiver with different options are built into a TV product line) [19]. Here, product populations offer an architecture-centric approach to combine multiple product lines where human intervention is required [19]. Our work strives to homogenize the combination of products from 1