A Service-Oriented Product Lines Implementation Approach: SOPLE-IM

Introduction

Software reuse is a key factor for companies which intend to increase software productivity and improve quality, as well as reduce the development cost and time to market. Thus, instead of develop everything from scratch, it is better to reuse some assets that are common among the applications. Currently, with the growth of software complexity and size, the software maintenance and comprehension become a hard task. In addition, flexibility is another important factor that affects reuse, since today, large enterprise application packages are prevalent, leading to problems whenever a new system is introduced or business needs requires changes in existing systems. In this context, Software Product Lines (SPL) and Service-Orientation (SO) could be applied to meet these challenges.

In the context of software reuse, SPL explores commonality and variability among related products, while SO is a way of developing service-based applications, which has in its roots the Service-Oriented Architecture (SOA). SOA is a model with the support of designing, developing, deploying, and managing systems in which services provide reusable business functionality. Furthermore, applications or other service consumers are built using functionalities from available services, and, the SOA infrastructure enables the discovery, composition, and invocation of services. The development of software product lines using software architectures and implementation supports systematic planned reuse, high software flexibility and contract-based communication on the use of a common, managed set of core assets for rapidly developing customized products for specific customers. On the other hand, a SOA implementation exposes standard interfaces to make services available for authorized service consumers to use in a variety of ways.

However, reasoning about how to combine both SPL and SOA concepts within variability implementation and technological concerns become a challenging task. As a consequence, the challenges consist the implementation activities that become more complex, since it is important to understand the variability mechanisms for realizing variabilities in different levels of granularity at runtime (e.g.,components, services, service-orchestrations), and feature types (e.g., alternative, optional, and OR-feature). Consequently, it becomes more critical when these aspects are addressed in a technology-specific way. For example, the need of mapping these aspects within the interaction and life cycle of services, making the assembly of a product easier to perform. Therefore, when it comes down to code there are some specific aspects that must be dealt by a method or process. In this sense, the use of an appropriate approach is essential to make decisions on several SOA quality attributes (well-defined interfaces, loose coupling, composability, among others) and variability implementation concerns as aforementioned. Without it, these issues can hardly be mastered.