Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Nowadays enterprises and companies deal with several challenges for developing SOA-based solutions. To stay relevant with the global competition, they need to rapidly and cost effectively develop and deploy stockholder-tailored services. On the other hand, enterprises often have to design and develop services which fit to a wide variety of stakeholders (i.e., consumers) within a particular domain or targeted market sectors. These challenges motivate enterprises to shift from mass software production to mass software customization. A trend inclines towards developing software applications composed from reusable software assets that can be re-targeted for different requirement sets. To enable mass customization in the context of Service-Oriented Architectures (SOAs), innovative software engineering methods and models need :(1) to capture the knowledge of variable requirements and reflect variability in services (2) support reuse not only reuse of service, but also in all other software development assets (3) enable service customization and management according to different stakeholders’ functional and non-functional requirements [2, 13, 36].

Software Product Line Engineering (SPLE) is one of the most promising and well-established paradigms, focusing on the development of software product lines [12, 49] based on the principles of variability modeling and mass-customization. SPLE research has proposed numerous approaches and techniques for the efficient production of similar software systems (i.e., also known as software families). Hence, the adaptation of SPLE approaches for mass-customization have received much practical attention and have already been applied successfully in many enterprises [39]. Employing SPLE techniques results in the reduction of costs, efforts, and time-to-market and the improvement of quality. This is done by decreasing the complexity of the design and by alleviating customization, maintenance, and evolution of software products [12, 44, 49].

Adopting SPLE offers promising prospects to provide scalable solutions to the current challenges of the development, management and customization of Web services and generally SOA-based systems [13, 14, 35, 36]. to which we refer as Service-Oriented Software Product Lines (SOSPLs). In this chapter, we firstly provide a comparison of SPL and SOA from different perspectives. We then present a method for a systematic development of a family of SOA-based applications (i.e., SOSPL). The underlying idea of the described method is to guide the development process of an SOSPL and which extends the conventional SPLE life-cycle to support modeling, developing and managing variant-rich service-oriented applications.

This chapter is organized as follows: Section 21.2 introduces the basic concepts of SPLE and outlines some of the main SPLE activities. Section 21.3 presents a holistic comparison of SPL and SOA, which focuses on reuse, architectural and variability aspects of the two paradigms. Section 21.4 introduces the end-to-end methodology for SOSPL development by focusing on the main engineering activities of the approach. Before concluding the paper in Section 21.6, we provide a detailed discussion of the proposed approach in Section. 21.5.

2 Software Product Line Engineering (SPLE)

SPLE addresses the issues of software reuse and mass-customization. An SPL or a software product family is defined as: “a set of software-intensive systems, sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and are developed from a common set of core assets in a prescribed way” [12]. The ‘particular market segment’ refers to a domain (i.e., a business area) and the business strategies of an enterprise or organization whose objectives of the business area are determined based on changes in its stakeholders’ requirements.

A key idea in SPLE is to capture the essential concepts of ’commonality’ and ’variability’ among a set of similar software products belonging to the same domain. Therefore, rather than describing a single software system, the model of software product lines describes the set of products in the same domain. A product line includes predicted variations that are introduced by tailoring the core assets using variation mechanisms. Variability introduced in SPLE is an abstraction that enables and facilitates customization. It empowers product derivation of different applications by explicit modeling and management of variation points [49, 57]. which define decision points determining how the product family members may differ from each other. Variations along with their possible choices, functions or qualities, can be defined at each level of abstraction (e.g., requirements, architecture, or components).

SPLE relies on a fundamental distinction of development for reuse and development with reuse with aims at maximizing reusability and eliminating wasteful generic development of components used only once. This insight can be leveraged to improve software development life-cycle [12, 49] that SPLE shifts from the development of a specific application or individual system to a domain, in turn, leads to two characterized development processes commonly referred to as domain engineering and application engineering. Domain engineering models variability among product family members and develops the reusable software platform by focusing on developing-for-reuse. The software platform encompasses all software development artifacts that are liable to be recycle. On the other hand, application engineering adopts the developing-with-reuse approach, where products are customized and derived from product family and reference platform which is constructed and developed in the domain engineering phase. Reuse of the software platform and binding variability for different applications are then enacted in application engineering. Differentiating these two development lifecycles allows for establishing the software platform, application customization, and product derivation.

Approaches to the analysis and construction of SPLs can be classified into three strategies: (i) proactive, (ii) reactive, and (iii) extractive [22]. A proactive strategy is similar to the waterfall approach in conventional software engineering, where all product variations on the foreseeable horizon are analyzed and designed, while architectures for the target domain are defined and implemented upfront. This approach is suited for enterprises that to foresee and plan ahead of their product line requirements well and that have available resource and time for a long development cycle. A reactive strategy is an incremental approach where only the product-line reusable assets needed in immediate terms are developed and built. Hence, this approach typically requires less upfront efforts than proactive. In a reactive strategy, one or several variations of software products can be analyzed, designed and implemented in each development spiral. Such an approach is suitable where the upfront requirements for product variations cannot be predicted well in advance or where enterprises have to maintain an aggressive product schedule, which is usually limited in time and resources, through the transition to an SPLE approach. An extractive strategy is between proactive and reactive ones and reuses existing software products as the product line initial baseline.

3 Comparison of SPL and SOA

SPL and conventional SOA-based approaches to software development share common goals. With both promoting the concepts of reuse and foster organizations to reuse existing assets and capabilities rather than repeatedly redeveloping them for new software systems. Recent years have witnessed growth of research in the exploration of the synergies of the combination of SPL and SOA in recent years [9, 13, 14, 23, 26, 36, 59]. Even though two paradigms support software reuse there are different perspectives and outlooks [37]. In this section, commonalities and differences corresponding to the two paradigms are discussed, helping to enlighten how SPLE can be adopted and leveraged for the development and customization of a family of SOA-based applications. To compare SPL and SOA, we consider four main aspects including development processes, reusability notions, architectural styles, and variability modeling and management.

3.1 Development Processes

SPL and SOA follow different engineering goals. Therefor, the activities associated with their software development life-cycles are different. One of the main objectives of SPLs is to reduce the overall engineering efforts required to produce a set of similar software applications by capitalizing on the commonality and by managing the knowledge of variability and customization. Therefore, the engineering goal of SPL is remarked as the systematic development and management of core assets and software platform in order to achieve the high level of reusability [12, 22, 44, 49]. In contrast, service-oriented approaches set the goal of achieving system agility and of enabling automation to cope with integration, inteoperability and dynamic execution in heterogeneous environments, and providing runtime flexibility [6, 20, 48]. Table 21.1 shows a summary of major life-cycle phases of two paradigms essentially including requirement and domain analysis, design and implementation, and deployment.

Table 21.1 Comparison of the major engineering activities of software product line engineering and service orientation
Full size table

  • Requirement and Domain Analysis: Service-oriented design and development are basically based on an iterative and incremental process. The process is initiated with planning proportional to the requirements which, for a new application, are investigated through the analysis phase. This process comprises of reviewing business goals and objectives that derive the modeling and development of business processes. In the analysis phase, business processes and services are identified and specified in a stepwise manner [20, 47] with the main objective of it to facilitate the reuse (or reproposing) of the business process functionality through the identification and orchestration of services when constructing new applications.

    The requirement-analysis phase in SPLE also consists of determining the requirements and using domain information. Nonetheless , SPLE focuses on the analysis and specification of requirements for the entire product family (i.e., product line). To this end, domain engineering of SPLE mainly concentrates on a systematic analysis and the settlement of the variability of both functional and non-functional (quality) prerequisites performed by scoping the product line, by analysing product line requirements, and identifying commonalities and variabilities among product line members. Requirement analysis in the application engineering life-cycle further focuses on the analysis and determination of prerequisites of individual stakeholders. In the application engineering life-cycle, requirement analysis is established for configuring reusable software assets developed and produced in the domain engineering life-cycle.

  • Design and Implementation: Service-oriented design and implementation is followed by the design and specification of business processes and service components corresponding to the requirements. Service implementation and testing involves discovery of existing available services through local or remote service repositories; and development of services by using the specifications developed in the design phase.

    In SPL, domain design and implementation involve the detailed design and realizing the reusable software components for the entire product family. It starts with the domain design sub-process which consists of (1) defining and modeling the commonality and variability based on the domain-specific requirements identified in the requirement engineering phase; (2) specifying the reference architecture of the product family; the reference architecture provides a common, high-level structure for all product line applications. Furthermore, the domain design incorporates configuration mechanisms into the reference architecture for supporting variability management in order to enable further product customization and derivation. The domain realization sub-process focuses on the implementation and testing of each component which is planned and designed for the reuse in different contexts (i.e., the applications of the product line). The application design sub-process in the application engineering life-cycle employs the reference architecture to refine and instantiate the application architecture and incorporates application specific adaptations. Afterward, the application realization sub-process focuses on the selection and configuration of reusable software components and testing for specific application, which are already contained product line architecture developed in domain engineering phase.

  • Deployment and Maintenance: In this phase, service-oriented development deals with packaging, provisioning, publishing services, service-matching based on requirements of stakeholders, executing stakeholders-acceptance testing, and monitoring performance in the production environment. TheSPLE development phase including the configuration and deployment of a final product is associated with application engineering with activities for building and customizing systems according to the result of domain engineering.

Table 21.2 Reuse in SPL and SOA
Full size table

3.2 Reuse in SPL Versus SOA

Software reuse, as one of the important goals in software engineering, can improve the quality and productivity of software development. For this purpose, several software reuse approaches have been devised. Component-based software engineering (CBSE) facilitates software reuse and promotes quality and productivity. The aims of CBSE are to achieve interoperability, reusability, and extensibility. These objectives are intended to facilitate fast-paced delivery of scalable evolving software systems [33]. Research on SOA is a modern instance of this vision [6, 46]. SOA leverages a logical framework by decoupling several logical units of functionality (i.e., services), which facilitate reuse by eliminating the recreation of common services. Thereby, business goals are achieved through loosely connected services with their variability is guided by SOA policies.

Reuse in SPL versus services in SOA have different characteristics (cf. Table 21.2). As mentioned, reusable assets in SPL encompass all the reusable software artifacts. A core asset is the most essential element of SPL since it is a common asset which is reused within multiple products and the reusability of which will largely determine the success of the whole product line [49]. For instance, the most distinguishable reusable assets in SPL context are as follows [12]:

  • Analysis and design models: including the requirements and variability models, which describe the common and variable features for all family members

  • Domain models: describing and representing all the entities and concepts that can be utilized in the context of software product families

  • Architectures: specifying and determining which of the reusable components are needed for configuring executable applications and how to configure software families that best satisfy non-functional requirements

  • Design decision models: specifying the family configuration model and determining how to derive software products based on specific requirements

  • Software components: supporting variation points and implementing the required functionalities of software families

  • Interfaces: enabling different implementation of the same functionality

  • Test artifacts: reusing test plans, test cases and scenarios, and test data

In SOA, service, on the other hand, are intended to be reusable building blocks and units of sharable software assets for different applications which implement different business processes. As a consequence, services can be orchestrated to construct composite services through business processes.

Core assets in SPL including a generic architecture and components are used to develop applications, whereas services are basic building blocks in SOA to support software development by composition. In SOA, business processes or application templates specify entire applications through the definition of execution sequences of valid workflows. Services can be reusable artifacts which enable rapid SOA application development [56].

Assets and applications are generally tightly coupled in SPL, while services are loosely coupled which is one of the most pronounced properties of services in SOA research [48]. Services maintain a relationship that minimizes the decency to the context or state of other services.

Software components often operate within a context defined by a generic architecture for product family members in SPLs. SOA is grounded on the idea of open integration of business processes by means of shared services where services are described through standard-interface and are intended for reuse in different contexts. Nevertheless, services can also be developed and reused for internal processes within organizations. In essence, SOA basically envisages and focuses on large scale reuse [28] because SOA promotes services to be seamlessly consumed by diverse applications where they can be published, discovered and invoked through standardized specifications [6].

Unlike core assets are reused in application development time which is often static, while services can be reused at design time but reconfigured at run-time [9].

3.3 Architectural Aspects of SPL Versus SOA

Both SPL and SOA require defining the architectural context and composition rules with SPL architecture is often characterized as centralized, static, and specialized into concrete products, but SOA is characterized as decentralized. Composition rules are predefined in SPL, which describe common and variable behavioral characteristics of architecture, while in SOA composition or business rules are generally defined to govern the way in which a composition is constructed. SPL basically aims at providing a common architecture for reuse, whereas SOA lacks enough support for large grained software reuse at the architectural level.

Gomaa et al. [24, 53] discuss software architectural issues in SOA and describe various practices to develop reusable services in order compose systems from services efficiently. They draw attention that the architectural solution space offered by SOA promises to provide potentially significant benefits for reutilization. However, achieving SOA’s benefits may not be guaranteed just by implementing based on the SOA solution. Accordingly, the important software architecture and reuse issues should be addressed prior to creating a SOA [53]. Tsai et al. propose a classification schema of architectures for SOA-based applications in order to evaluate variety of architectures [56]. The slackly coupling characteristic and platform-independent view inherited in SOA may address many architectural issues that are open-design and integration problems. Furthermore, architecture style offered by SOA is potential to maximize reuse beside interoperability and flexibility; however, SOA lacks support to manage variability at the architectural level [13, 36]. Whereas SPL enables managing variability to improve reutilization reuse at such level.

3.4 Variability in SPL and SOA

The concept of variability refers to the ability of software systems or artifacts to be efficiently extended, modified, specialized, or configured (customized) for (re)use in the specific context for a particular application [57]. This characteristic enables for applying changes at different levels ranging from software architecture to implementation. Two important concepts related to variability discussed in the literature are variation points and variants [49, 57] with the former being placed in the design or implementation at which variants occur. Variants are the alternatives that can be selected at those variation points. Therefore, variability can specify a part of an architecture which remains variable, as variation points, or what is not completed at design time. Variability can be implemented at design time or run-time [54]. It is noteworthy that variability and flexibility are closely interconnected. Flexibility offers adaptation and changes of architecture, while variability deals with various version of architecture.

Variability in SPL encompasses all software artifacts from requirements to code [12, 57]. Therefore, there are numerous modeling methods proposed that with the objective of modeling variability within software artifacts and at different levels of abstraction. Van Gurp et al. discuss about the notion of variability in SPL [57], where variability is exposed at different levels: platform technologies and user expectations, requirements specifications, designs, component source code, compiled code, linked code, and running code. Variability in this context refers to the ability to select among these artifacts at various stages during product derivations.

Effective management of variability is essential for the success of SPLs [57]. It determines how flexibly new members of a given SPL can be obtained and defines SPL boundaries. The distinction between variability modeling and other techniques is based on the diversity between variability modeling and variability mechanism. Variability modeling techniques model the variability provided by the product line artifacts while variability mechanisms are commonly considered ways to introduce or implement variability in those artifacts. Several of these mechanisms have been proposed in the literature such as conditional compilation, patterns, generative programming, macro programming, and aspect-oriented programming.

Accordingly, variability in SPL is an essential concern in all phases of development life-cycle. Variability identification, modeling and management is rather a large field of research in SPL [11]. Most current works address identification and management of variability by modeling the concepts as features which considered as the first-class representation of variability and in terms of which the major advantages of discussing a software system in terms of features is that the concept of feature bridges the gap between the requirements and technical design decisions because software components rarely address a single requirement but rather an entire set of essentials (details are given in Sect. 21.5). There are number of well-studied feature-oriented approaches for domain analysis and modeling common and variable requirements in SPLE such as FODA (Feature-Oriented Domain Analysis) [29] and its extension FORM (Feature-Oriented Reuse Method) [30], RSEB (Reuse-Driven Software Engineering Business) [25], GPM (Generative Programming Methods) [16] and PLUSS (Product Line Use case modeling for Systems and Software engineering) [19]. Every method generally shares feature as the common concept used in the analyses of commonality and variability. Some approaches are architecture-centric such as Hoek [27], Koalish [4], and Thiel [55] some of which are configuration-based, e.g., COVAMOF [50] and Koalish [4]. Some of the approaches extend UML to model variability like VPM [58]. Some proposed approaches focus on separating variability representation from the representation of various SPL artifacts such as Bachmann [5].

The development of SOA-based applications is accomplished through different abstraction layers: business process or orchestration layer, service interface layer, and service implementation or component layer [47] with the business process layer or orchestration layer consists of composite services implementing coarse-grained business activities, or even an entire business process. The service layer is composed of self-contained and business-aligned services, which provide the implementation for fine-grained business activities. The service interface layer comprises the interface of services published by a service provider. Finally, the component layer (i.e., implementation layer) consists of a set of components that realize service interfaces and provide the implementation for services. Variability in SOA affects these different layers thoroughly. Chang and Kim [9] discuss four types of variation points which occur in a general four-layered SOA architecture: workflow variability, composition variability, interface variability, and business logic variability. Workflow variability is identified as variation of the control flow of a business process, i.e., tasks can be alternatively and optionally completed in a workflow depending on the individual service user. Composition variability is identified as variability when there is more than one possible service interfaces for activity construct in the business process which implement the service with either different logic or quality attributes. Interface variability occurs when the candidate services interfaces are different. Finally, components which realize and implement service interfaces by different logic impose logic variability.

Granularity Levels: Granularity in SPL refers to the degree of detail and precision of variability as produced by design or implementation artifacts. SPL variability may exist at different levels of granularity ranging from entire components to single lines of code [16, 31]. SPLE takes a top-down approach and decomposes artifacts into fine grained artifacts, whereas a bottom-up compositional approach is often adopted in SOA to combine artifacts into larger entities-service into composite services (i.e., business processes) that finally form the application. Decomposition or top-down modeling means that an SPL architecture specifies the decomposition of a family into architectural components. However, there are also hybrid approaches, such as product populations modeled using Koala [45], where the mixture of bottom-up and top-down approaches are leveraged. In SOA, generally there is no particular architecture specifying the decomposition.

In SOA, granularity specifies the scope of variability in functionality exposed by a service. A component which provides an implementation for a service interface can be of various granularity levels that software developers can always encapsulate the entire functionality of a solution into a single service is possible due to the well-known ‘fractal’ nature of services, where a higher-level service can encapsulate lower-level services to any level of granularity [8]. However, a fine-grained service is more easily reused; in distinction, coarse-grained service is more difficult to be reused [47, 53]. Nevertheless, services with high-level interfaces increase the reusability because providing interfaces with a coarse-grained granularity masks specialized or implementation-specific methods, thereby, this enables a service adaptable and reusable by multiple applications. Moreover, from the perspective of service-oriented design and development, creating and designing high-level, coarse grained interfaces that implement a complete business process is desirable [20, 47]. However, there is a trade-off between fine-grained and coarse-grained.

Services at different levels of granularity can be generally classified into different categories [34]: basic services, intermediary services, process-centric services and public enterprise services. Basic services that represent the elements of a vertical domain are simple logic-centric or data-centric services. Data-centric services handle persistent data and logic-centric services encapsulate algorithms for complex calculations or business rules. Intermediary services are designed to bridge a technical gasp in architecture. They provide service links with other services or application front-ends and services in gateways, adapters (mapping message formats to enable interoperability), facades (providing a different view on one or more services), and other functionality-adding services (extending functionality of existing services without altering them internally). In SOA, process-centric services to control and maintain the state of the enterprises business processes which uses basic or intermediary services to perform task and deal with business data. These services separate process logic from representation layer and encapsulate the process complexity for a single point of administration. A common example is an online shopping process, which includes filling the shopping cart, ordering products, and executing billing. Public enterprise services offered to partner companies as an in-house-system interface which, in turn, have the granularity of business documents and are coarse-grained integrate enterprises (B2B).

4 Running Example

To illustrate the concepts and the approach presented in the following sections, we select a part of case study of a family of online marketplace portals providing applications for online trading like eBay.Footnote 1 The portal, as an SOSPL, can be customized and deployed based on different business requirements of targeted stakeholders. Figure 21.1a presents a service scenario of e-payment processes-part of a large product family that defines a common framework for online payment provided in online marketplace. For the simplicity, a high-level view of the payment process is represented, and the details are omitted.

Fig. 21.1
figure 1

a) A holistic view of e-Payment process family. b) e-Payment process variants example

Full size image

Different methods of online payment can be considered for different instances of products from a family. Therefore, the number of possible payment method variations of a reference payment process, as a catalog and template, can be derived and customized according to the stakeholders’ requirements and business objectives. Some services are indispensable and prerequisite of the payment process (e.g., Credit Card payment feature as the dominant online payment), which should be included for all the stakeholders’ service product instance where as, some functional services (e.g., Smart Card e-Check and Debit Card) or extra-functional services (e.g., Logging and Monitoring) can be determined as optional that can be included or excluded based on stakeholders’ needs (see Fig. 21.1b). As a case in point, Stakeholder A may require additional features for having highly-secured payment transactions by including a fraud protection service, whereas this service is not required to be included in the payment process of the final customized portal for Stakeholder B. In another scenario, Stakeholder C could ask the payment process to be supported by a Mobile-based Notification service in addition to the common payment notification services such as the Mail-based Notification service. Therefore, in the context of a product family, a business process should be imposed inevitably by variants (optional and mandatory services) which are required to be managed, specialized and customized in order to meet different stakeholders’ functional or quality requirements.

5 Applying SPLE for Development of Service-Oriented Software Product Lines

It is already mentioned that even though SOA has been widely adopted, there are still no systematic methods to support modeling and managing variability during the development of SOA-based applications and further service management, which calls for a well-defined development process and understanding variability in functional and non-functional requirements in the course of development.

This section outlines the activities of a proactive methodology. The proposed method is an extension of a traditional software product-line life-cycle in order to support development and customization of a family of SOA-based applications. The proposed top-down method follows a two-life-cycle approach that separates two core activities related to Service-Domain Engineering and Service-Application Engineering (see Figs. 21.2 and 21.6). Service-domain engineering constructs and evolves the reuse infrastructure by analyzing the requirements and scoping the product line as a whole and producing any common , reusable business processes and services. On the other hand, service-application engineering derives individual services (i.e., customized services) from the reference architecture. Domain and application engineering life-cycles can rely on fundamentally different processes, namely, plan-driven and agile methods. In the following, we describe the major activities and their artifacts for three major development phases: (1) analysis (requirement engineering), (2) design, and (3) implementation and testing.

Fig. 21.2
figure 2

Service-Domain Engineering of an Service-Oriented Software Product Line

Full size image

5.1 Service-Domain Engineering

The overall service-domain engineering processes of an SOSPL is depicted in Fig. 21.2. These activities (D1–D6 in Fig. 21.2) are performed iteratively. Domain analysis in SOSPL mainly encompasses product-line requirements engineering stage (D1) along with the analysis of variability by using feature modeling (D2). A feature model, as a software artifact outcome of the feature modeling process, includes the knowledge of variability associated to the functional and non-functional requirements and describes the permissible configuration space further guiding the customization process and determining how the reference business process model should be tailored according to the stakeholders’ requirements in the application engineering life-cycle. During the domain design phase (D3), a reference business process model (also known as business process family) is designed and constructed for the product line architecture based upon the outcomes of the requirement engineering phase (D1). The model mapping (D4) establishes the mapping relationships between the features within the feature model and the corresponding activities specified within the reference business process model. The activities of the reference business process are delegated to the service(s) in SOSPLs. In as much as non-functional (quality) requirements may also vary for different stakeholders, variability in the quality properties of services should also be captured and specified during the construction of an SOSPL (D5). To this end, features in the feature model are annotated by quality ranges which are supported by the entire product line architecture [40], progressively helping service engineer and developers to evaluate the impact of variant features selected according to the quality characteristics that services provide. In the final phase, the reference business process model is realized and implemented either by binding to the existing services or by developing new services. In the following, we detail these activities.

5.1.1 Product Line Requirements Analysis

Similar to traditional requirements engineering, domain requirements engineering should at least include the following activities [52]: (1) elicitation in which the product line business goals and stakeholders’ requirements are discovered and scoped; (2) specifications in which the requirements are analyzed in detail; (3) validation in which the requirements are validated and consistency and completeness are checked, and (4) management in which the requirements can be managed in terms of changes or refinements. In addition to these activities, domain requirements engineering captures commonality and variability between the requirements of several stakeholders. Moreover, an important activity of the requirements analysis of an SOSPL is to define the product line scope [13, 44, 49] and decide on the boundary of the product line.

A successful scoping which is determined by factors such as the knowledge of similar domain services and future stakeholders’ demands is required to be performed carefully because a scope-either too large or too small-will impair the capability of a SOSPL in achieving the goals of stakeholders [12]. A goal-oriented domain analysis can be employed at the early stage of the requirement analysis in order to capture the product line goals for requirement elicitation and to further align the final service products with the business goals and intentions of both the stakeholders and service providers. This is accomplished at the different levels of abstraction by goal modeling about which interested readers can further read in  [3]. The outcome of this phase is the requirements models which can be described by goal models, use-cases, documentations and details, which are used subsequently for the variability analysis of the product line under development.

5.1.2 Variability Analysis and Modeling

The product line requirement engineering activity follows the variability analysis and modeling of the entire family in order to identify common and variable features. A feature is commonly defined as a visible incremental functionality and quality in software system(s) [29]. Nevertheless, depending on the stage of development it may also refer to a requirement or a coarse-grained or fine-grained component in the system(s) which provide the required functionality from different technical views. The emphasis in the variability (i.e., feature) analysis is on optional features, because optional features substantially differentiating one member of the family from the others.

In SOA, services constituting the orthogonal concept to the components notion, are characterized as the loosely coupled building blocks of software. A services encapsulates functionality and provides individual non-functional properties (i.e., QoS) through a well-described and published interfaces. From this view in the context of SOSPL, we define a feature as an increment in service functionality [1], which reflects stakeholders’ both functional and non-functional requirements; wherefore, a feature, based on the granularity levels, a feature can be realized and associated to a composite service at the high-level business processes, or associated and realized by an atomic service at the lower-level.

Fig. 21.3
figure 3

Feature model of e-Payment (conforming stakeholders’ requirements model)

Full size image

Feature-oriented development [16, 29, 30] is widely employed as a means for analysis, management, and visualization of commonality and variability in SPLE in terms of features at different abstraction levels. In essence, feature modeling organizes features of a software product family into a model called feature residing between the requirement model and the design specification model (i.e., the reference business process model described in Sect. 21.5.1.3). Figure 21.3 shows a part of a feature model representing the variants (e.g., optional and alternative features) that characterize a requirements model. These features are selected to derive service products during the application engineering. Moreover, this model serves as a catalog of the variability space offered by a product family to accommodate the idiosyncrasies of the stakeholder enterprise or company.

Feature Model: A feature model consists of both formal semantics and graphical representation (e.g., feature diagram) and encompasses the knowledge of configuration (i.e., customization) for a product line. A feature model is a hierarchical decomposition of features in terms of parent-child relations on different levels of abstraction. As some of the features are not assumed to be present in every product during the application engineering, this differentiation is expressed by the indication of feature types and their relationships. Contrary to a mandatory feature is always selected if their parent is selected , an optional feature may or may not be selected. For instance, in Fig. 21.3, all the products should include the Credit Card feature as a mandatory feature. Other payment methods Fig. 21.3 are specified as optional features.

A feature cardinality and group cardinality can also be determined in cardinality-based feature modeling [17]. A cardinality associated to a feature determines the lower and upper bound of the number of features required in any product in a product family. In the SOSPL context, this attribute specifies the number of service instances that should be linked to a given service at run time. Cardinality can be defined as an interval, from zero to a given value.

Or feature groups with defined cardinality indicate that at least \(k\) and at most \(k'\) features that can be included out of the \(n\) features (\(k \le k' \le n\)) in a group if the parent is selected. Moreover, Alternative feature groups with specified the cardinality indicate that that only \(k\) out of \(n\) features in the group must be included if the parent is selected. Back to the simplified feature model example from Fig. 21.3, all the products should include the Payment Notification features. Also, all the final derived service products should include at least two methods of notification according to the feature model.

Furthermore, because features are not always independent integrity constraints (i.e., the includes and excludes) can be defined over features of a feature model to model dependencies and relations among them. They are the means to describe that the presence of a certain feature in the product imposes the presence or exclusion of another feature (see Fig. 21.3).

Feature models are an efficient abstraction of variability derived from the domain and stakeholders’ requirements. They also help to derive the design and the development of variability through all the stages of the development including service identification and design, and further customization [13, 41].

In the feature-oriented analysis phase, which subsequently guides the identification of candidate services with right granularity, we organize feature based on the following criteria:

  • Features supporting a particular business process can be grouped and abstracted as a higher-level feature on a coarse-grained level (e.g., Payment)

  • Features supporting specific functional or non-functional services can be grouped and abstracted as a higher-level feature (e.g., Payment Notification and Logg ing services)

  • A feature which incrementally realize a feature at the upper-level, then becomes as a sub-feature at the lower-level

  • Features at the leaf-level are realized by fine-grained services

5.1.3 Reference Business Process Model

The previous activities, domain decomposition, top-down variability analysis and modeling provide an insight into a target domain in terms of product features. A feature model is generated as an output of the domain analysis. This model is then used to derive reference architecture and develop reusable components (business processes and services) in the course of the domain design. The activities of the design phase produce an architecture-independent model that defines reference architecture as the behavioural model of features for the entire family and specifies how features are composed at run-time.

A template-based approach has been widely adopted in SPLE for creating reference models. In the case of SOSPLs, such a reference model is designed as a template for the entire service products family in a superimposed way [15]. A reference business process model, as a model template, describes and specifies the execution sequence of services for all instances of the product line. That is, a reference business process model is a union of all the business processes of the product line. It provides the common business logic for orchestration and choreography of services, which implement features. The reference model comprises functional interfaces specifying services capabilities, pre and post conditions of the services, and configuration properties representing the data needed to configure a service before its use, and service bindings. The reference business process model can be modeled by using process-oriented modeling languages (e.g., BPMN, EPC, and/or YAWL), and incrementally refined and optimized. For example, Fig. 21.4 illustrates a part of reference business process model, where variability and configuration knowledge have been modeled and encapsulated in given feature model in Fig. 21.3.

The reference business process model configured through the selection/elimination of features from the feature model during the application engineering and executive instances are derived (see Fig. 21.1b). In other words, due to the fact that architectural variations in the reference model are encoded as features, various parts of the reference business process model are organized in variation points. These variation points are managed and configured by means of feature models. It should be noted that we distinguish between design and runtime variability. Feature models capture and encapsulate only architectural variability at design time. In contrast, business process models describe behavioral variability, i.e., how features are composed, which drives runtime variability through composition patterns (discussed in the next section).

Fig. 21.4
figure 4

A part of reference business process model

Full size image

Furthermore, feature model configuration (i.e., specialization and customization) is performed during the build-time. The configuration can be done through the process of staged-configuration [18] where features further are prioritized and selected according to the (non-)functional requirements of the stakeholders [41]. All configured service products, which are instances of the family, have to conform to the reference architecture.

5.1.4 Feature Resolution and Mapping Model

During the design phase, feature resolution is the activity of analysing and connecting the feature model and the reference business process model in order to specify explicit mapping links between the two models: feature and reference business process models. The outcome of this activity constitutes a mapping model including links between features in the feature model activities in the reference business process model. This mapping model enables the configuration of the reference business process model through feature section during application engineering. From one point of view, this mapping model also provides the traceability links between the requirements and implementation [15, 51].

A mapping model can simply consist of boolean expressions specifying presence or removal of a modeling element (e.g., activity (abstract service)) in a model template (i.e., a reference business process model in our case) based on the selection of features in the feature model [15]. In our approach, we consider a boolean variable \(\varvec{\psi }_{i}\) corresponding to each feature \(f_{i}\). This approach uses presence conditions (PC) as annotation properties for each activity within the reference business process model. The PC of an activity is formulated as a boolean expression of \(\varvec{\psi }_{i}\) variables corresponding to the features mapped to the activity (see Fig. 21.3 and 21.4). Both the feature and activity constructs refer to model elements of feature models and reference business process models. Thereby, when domain engineers map features to activities, the activities’ PCs are defined. In application engineering, when a feature \(f_{i}\) are removed from the configuration, their corresponding \(\varvec{\psi }\) variables are set to false.

Feature resolution also helps to identify cross-cutting concerns related to general non-functional requirements. For example, feature Monitoring with given mapping annotation \(\varvec{\psi }_{i}\) in Fig. 21.3 is mapped to activity Monitoring as an extra-functional abstract service in the reference business process model (see Fig. 21.4). Based on the selection of features from the feature model in application engineering, the reference business process model is configured (Fig. 21.1b).

5.1.5 Non-functional Specifications

The domain design phase is also followed by the specification of non-functional properties based on the non-functional requirements (NFRs) analysis. This is due to the fact that NFRs are interlaced and related to functional requirements. Variability in NFRs influences the SOSPL design and implementation. Non-functional variations often exhibit different types and levels of quality properties (e.g., normal and strong authentication or security). For instance, NFRs for feature Credit Card can include cost, security, availability and reliability or they can also entail defined domain-specific non-functional aspects such as usability and convenience of use. Furthermore, in application engineering, non-functional variations directly impact the selection of appropriate services from candidate services, all of which provide equivalent functionalities but with different degree of non-functional properties related to the service quality specification. To this end, there are a number of proposals [7], in which feature models are extended to support feature attributes. Such attributes can comprise non-functional properties which can be measured (e.g., cost, availability, latency, bandwidth, etc).

In the context of SOSPL, these non-functional properties can be viewed as QoS properties, which are associated to each feature. Mapping models interconnecting feature and business process models enable for propagation of quality property values of concrete service sets, which are bounded to activities (abstract services) within in the process model. Based on the underlying implementation of a set of functionally equivalent services, which may be available for each feature, ranges of values of quality properties can be further specified and aggregated for each feature. Particularly, during the domain engineering lifecycle, determining the implied QoS ranges \(q^R\) for individual features \(f_n\) helps domain engineers ensure that the product line architecture will fulfill and deliver the upper and lower bounds of the values of the quality requirements requested by the stakeholders. Moreover, quality range computation enables for keeping track of the product line quality ranges even after the specification of the service quality has changed. For example, in Fig. 21.5, sets of candidate services provide different range of quality \(q^R\) for each features. The range of the \(k\mathrm{{th}}\) quality property for feature \(f_n\) can be hierarchically computed. In [40], we introduce a generic evaluation model and method for aggregation and computation of ranges of quantified values of quality properties defined for product line architectures.

Fig. 21.5
figure 5

Non-functional specification and aggregation for evaluating quality range supports by product line architecture

Full size image
Fig. 21.6
figure 6

Application Engineering of an Service-Oriented Product Line

Full size image

5.1.6 Reference Business Process Model Implementation

The domain design phase produces a reference business process model and architecture for a family of service products (i.e, SOSPL). In the domain implementation and realization, the reference business process model is realized and implemented. This activity involves implementing and testing the detailed architecture of the family modeled by reference model. Abstract services specified by the reference business process model are implemented by using component models such as Java class, Enterprise Java Beans, or .Net components. However, some of the services needed for the implementation might already be available; for instance, can be either found in a service catalog or retrieved through a service discovery process, and some of the services could potentially be built by partly reusing or modifying existing solutions.

5.2 Service-Application Engineering

This section describes a holistic view to the application engineering life-cycle. This lifecycle includes the major phases of service customization and derivation from the business process family. Regardless of the chosen variability modeling approach, the ultimate of in-service-application engineering is to employ the variability defined in domain engineering by selecting shared assets similarly developed in domain engineering. Figure 21.6 depicts a high-level application engineering process which starts with the elicitation and capturing of both the functional and non-functional requirements of an individual stakeholder through the application-requirement-analysis phase (A1). In the application design phase (A2), features are prioritized based on the stakeholder’s captured preferences and business objectives concerning the optional features and quality needs. There after, the feature model is specialized through the decision-making process of selecting optional features. Subsequently, the reference business process model is configured and corresponding services are selected and bound in the deployment and integration phase (A3). The details of these application engineering phases can be found in [41].

5.2.1 Application Analysis

This phase focuses on the elicitation of requirements of a particular stakeholder for deriving customized process variants, which can be deployed as the final product. The preferences of the stakeholder are captured and later utilized for feature prioritization and selection. Similar to the requirements engineering phase in service engineering methodologies like SOMA [2], activities in the application analysis phase capture requirements for a single service (application). However, the application analysis activities reuse the family requirements models to develop requirements models of a target service. For example, assuming a family requirement model is represented in a goal model, the service goal model is developed through reasoning on the family goal model based on the inputs of current stakeholders [3]. Validation and verification of the application requirements model with respect to the stakeholder’s needs and product line constraints are performed. In the context of marketplace portals, stakeholders of a target service application may request payment, shipment, order management, and manage customer functionalities as well as high security and low cost. The detail of stakeholders requirements can be achieved by applying label propagation algorithms on the marketplace family goal model.

5.2.2 Application Design and Implementation

During this phase, the feature model is utilized to manage and select variants that constitute service product instances. This is accomplished through the feature prioritization and selection of sub-processes. This activity includes the selection of the best and at the same time permissible combination of optional features along with the selection of the corresponding services that would optimally satisfy the stakeholder’s functional and non-functional requirements. Several (semi-) automatic and manual feature model configuration techniques have been proposed to guide the final product configuration (i.e., customization) according to the requirements and preferences of stakeholders. Automatic configuration approaches employ AI optimization techniques such as Genetic Algorithms (GAs), Bayesian Belief Networks, and Constraint Satisfaction Optimization Problem (CSOP) to create the final customized product [7]. On the other hand, manual configuration techniques through staged-configuration [18] provide specialization steps for service engineers helping them resolve variability in the process of family customization (see Sect. 21.6). After configuring the feature model, due to the established mappings between the feature model and the reference business process model, a concrete business process for a target service-oriented application and its realizations are derived from the family design and implementation models. However, since there may be some requirements which could not be satisfied by existing assets (i.e., services) contained in the developed SOSPL architecture, further refinement of instantiated service products from the reference model can be performed, and new required services can be implemented. In our running example, according to the requirements of the current application derived in the previous stage, application engineers can configure marketplace feature model and derive a business process model for the service-oriented application under development. Also, proper services based on the requested quality of services (e.g. high security and low cost) are selected.

5.2.3 Application Deployment

This phase focuses on creating an executable business process and deployment of the customized services in the production environment after validating the customized services against the application requirement specification. After the deployment of the final service product on to the stakeholders’ environment, the execution of the customized services is monitored to ensure the compliance of the service execution to stakeholders’ requirements and any service level agreements.

6 Discussion

The development, management and evolution of many modern software systems rely on the notion of variability and suitable design techniques. SPLE research has devoted a considerable amount of resources to the development of various approaches to dealing with variability analysis, modeling, management, customization and related challenges over the last decade. These approaches can be employed in the design and development of variant-rich service-oriented applications (referred to as SOSPLs in this chapter).

Feature-oriented analysis enables for capturing variability in services at different levels of abstraction in order to support managing variability and leverage it for customization. Variability can be considered in terms of four different general levels of abstractions in service-oriented development [47]: requirements, business process models, service interface model and service component. In that sense, variability at a lower-level of abstraction realizes variability at a higher level. As described earlier in the chapter, we leveraged feature modeling for managing variability by focusing on the requirements and business processes at the higher levels of abstraction. However, feature models also can be employed for modeling, representing and managing variability at the levels of service components, service interface to support efficient service management. For instance, in [21], Fantinato et al. employed feature modeling to manage and enable customization in service contracts.

Nguyen and Colman [42] propose a feature-based service customization framework for modeling and managing variability of complex Web service specifications. The proposed approach employed feature models as an extension to service description artifacts in order to facilitate the customization of service interfaces. In [43], the same authors adopt a feature-oriented approach to modelling variability in process-based service compositions and to enabling process customization. The approach extends the BPMN 2.0 metamodel to allow for defining variation points and variants within business process models. The extension is focused on modeling variability of three aspect of business process: control flow, data flow, and message flow. A variation point in a control flow is interpreted as any location in a process model at which different execution paths can be take place, and variants can be arbitrary process fragments. Variability in data flow is considered as a different way for storing data objects. Variability in message flow is identified as alternative conversations and interactions between two parties, i.e. the process and a partner service (or a consumer).

Koning et al. [32] investigate how variability can be incorporated into service-based systems in order to enable variability modeling and management. They describe how variability management helps to support run-time reconfiguration of systems by service replacement corresponding to the non-functional requirements of stakeholders. VxBPEL is proposed as an extension of Business Process Execution Language (BPEL) for to the process description and definition. VxBPEL allows for run-time variability and variability management in Web service-based systems. Variability information is defined in-line with the process definition. VxBPEL builds upon COVAMOF [50], a framework for modeling variability. Koning et al. note that the architectural modeling and management of variability in Web service-based systems provides the following advantages: enhances the extensibility of systems through service replacement; improves run-time flexibility for reconfiguration and rebinding of services (e.g., being able to optimize quality attributes through reconfiguration).

As already mentioned, improving reusability in service-oriented development is an often-stated goal in the literature. There are a number of important concerns that can influence highly-important analysis and design decision for the quality of service design. The major concerns include analysis and design for service reuse, service granularity management, and design of composable service [47]. Hence, several challenges have been unveiled for the development of service-oriented systems such as how to identify reusable services at the right level of granularity in order to facilitate service composition. Hence, the identification of service candidates is a challenging task in services engineering  [2, 47]. SPL approaches can be adopted to consolidate design principles and service identification during the course of service engineering.

Lee et al. [38] present a feature-oriented approach to the analysis, identification and development in order to improve reusability of service-based systems. The proposed approach provides guidelines about how to address the key issue of granularity and orchestration of services by using feature models. They show how reusable service can be identified and specified based on software features. The proposed method is based on analysis of features that may vary from a user’s point of view and will be subject to reconfigurations at runtime. Another approach to using feature-oriented analysis for service identification during the analysis and design phases is proposed by Chen et al. [10] whose main focus is re-engineering towards service-oriented systems and the remark of whom that feature-oriented analysis bridges the gap between the abstract architectural and source code level, whereas business processes are excluded.

Service-Oriented Modeling and Architecture (SOMA) proposed by IBM [2] has been developed as a generic development method for SOA-based applications. SOMA provides the guidelines for identification and specialization of services that realize and implement business processes through service composition. The authors of SOMA remarks that variability analysis in the practical SOA solution design is crucial for the initial finding-binding relationships between a service consumer (i.e., stakeholder) and a service provider. Moreover, it was noted that the publishing and discovery of relationships are often affected by variations, which are identified later in the design process. Hence, such variations may cause expensive fundamental re-design of SOA-based solutions [2]. To address this problem, the authors remark that a development life-cycle for SOA-based solutions should be extended by a variation-oriented analysis as an extra dimension that should be performed.

7 Conclusion

We can observe that the convergence of service-oriented and software product line engineering is gaining a considerable amount of attention and rapidly emerging as a viable and important software development paradigm. As we have discussed in this chapter, they both share common goals and promises to collaborate in the development of flexible, cost-effective software systems and to support a high level of reuse. Yet, their main goals are somewhat different. In this chapter, we discussed that how service-oriented development can benefit from SPLE approaches for variability modeling and management in the process of identification and design of variant-rich service-oriented applications.

By combining ideas of service-oriented development and SPLE, we expect to derive new software engineering approaches to make use of the best from both paradigms: (a) development of generic software architectures for highly adaptive Web services that can respond effectively to fluctuations in stakeholders’ (non-) functional requirements, and (b) development of shared architectures that could be reused in different instances (benefits from the SPLE principles).