focus Software product line engineering (SPLE) is a paradigm of software reuse Combining Service Orientation with Product Line Engineering

Transcription

1 focus s o f t w ar e pr o duc t lin e s Combining Orientation with Product Line Engineering Jaejoon Lee and Gerald Kotonya, Lancaster University Developing effective service-oriented product lines can meet the growing demand for dynamic product reconfiguration. This article addresses the challenges involved and describes a possible solution. Software product line engineering (SPLE) is a paradigm of software reuse for developing a family of products with reduced time to market and improved quality. Most SPLE approaches, however, have focused on developing statically configured products using core assets. 1 That is, all variations are instantiated before a product is delivered to the customers, making it difficult for them to make any changes to the product. However, various application areas are increasing the demand for dynamic product reconfiguration. Dynamic product reconfiguration involves making changes to a deployed product configuration at runtime. Examples include dynamically adding, deleting, or modifying product features and making dynamic changes to architectural structures. Researchers have studied dynamic product reconfiguration for various application areas, including self-healing systems, 2 context-aware computing, 3 software component deployment, and ubiquitous computing. 4 Detecting a change in operational context could trigger a product reconfiguration to provide context-relevant services or meet quality requirements such as performance. Thus far, these dynamic reconfiguration approaches have focused on the specific problems of each application area (for instance, behavior models for dynamic changes, context recognition from software or hardware environments, and autonomous management of software component versions). However, some researchers are beginning to investigate development issues for reusable and dynamically reconfigurable core assets, called dynamic software product lines (DSPLs). 5 A service-oriented product line (SOPL) is a DSPL application domain that s built on services and a service-oriented architecture. 6,7 An example of an application area for an SOPL approach is a virtual office (VO). 6 A VO includes many business peripherals with various services that interact with one another and that respond to their various environments to assist office workers. However, such a system presents several software engineering challenges. First, VOs must be highly self-adaptive so that they can dynamically reconfigure their behavior to respond to changes in the environment and to coordinate with other services in the vicinity. For example, an office worker might use different types of devices (a notebook, a PDA, or a mobile phone) at various locations in an organization (an office room, a meeting room, or a product showroom). The VO system must support the current tasks ( checking, video conferencing, or presentation) as much as possible by using and coordinating available devices and / 1 0 / $ I E E E May/June 2010 I E E E S O F T W A R E 35

2 Table 1 Comparison of the major engineering activities of software product line engineering and service orientation Major life-cycle phases Engineering paradigm Analysis Design and implementation Product deployment and maintenance Main engineering goals Software product line engineering n Commonality and variability analysis n Product line requirements analysis n Product line architecture and components design with variation points n Production plan n Valid product configuration n Systematic reuse of core assets orientation n identification n orchestration specification n Information broker n protocol n provider and consumer registration n matching n System agility through runtime flexibility services, regardless of which devices are used and where they re located. Second, a VO s longevity implies that products should evolve over time. New devices and services could be added, removed, or updated, and the overall requirements governing how available services should work together could change. At the same time, the VO system must continue to function effectively and satisfy its overall goals. These first two challenges concern the service orientation (SO) characteristics of a VO system. However, we also must shorten the time to market by systematically reusing core assets of the VO system the third challenge and this is an SPLE characteristic. Therefore, establishing an SOPL of the VO system is the key to successful deployment of multiple VO products for various organizations having their own specific requirements. In this article, we identify the main challenges we experienced in developing an SOPL, and then briefly describe a possible solution that combines feature-oriented analysis with a QoS-aware SO framework. SPLE and SO Paradigms SPLE and SO have different engineering goals. So, the activities at each software life-cycle phase differ as well. Table 1 summarizes the major engineering activities of these two paradigms. SPLE s main engineering goal is the development of core assets that enable systematic reuse. To achieve this goal, the analysis phase focuses on identifying product line commonality and variability, and using this information to specify product line requirements. The product line architecture and components provide an infrastructure for efficiently instantiating various products of that product line. Ensuring a valid, working, environment-relevant product configuration is critical to deploying and maintaining a product because an invalid configuration could lead to a system crash or malfunction. SO s main goal, on the other hand, is system agility through runtime flexibility to cope with rapidly changing business environments. The key idea of SO is software as a service, which promises agile and flexible system development through a dynamic runtime architecture that allows for adding third-party functionality on demand. The service-oriented architecture is the conceptual structure for realizing this vision. 8 The analysis phase s major focus is identifying and defining how to orchestrate services in an application. A service broker provides runtime support for service discovery and selection. As such, key development issues include design considerations and constraints for efficient, dependable, and correct matching between service consumers and providers. Challenges to Building an SOPL We experienced four major challenges in building an SOPL: different notions of first-class objects as engineering drivers (features versus services), dynamic characteristics of a service-based system, involvement of third-party service providers, and variation (product configuration) control and management. Different Notions of First-Class Objects Features and services are two different notions of key engineering drivers in software development under the SPLE and SO paradigms. Features are abstractions of a product line s user- or developervisible characteristics. 9 Feature orientation to analyze a product line s commonality and variability appeals to many product line engineers because 36 I E E E S O F T W A R E w w w. c o m p u t e r. o r g / s o f t w a r e

3 features are an effective medium for supporting communication among a product line s diverse stakeholders. 9 Products are typically discussed and described in terms of features gathered from market surveys, individual customers, research labs, or technology roadmaps. Therefore, it s natural for people to express commonality and variability of product lines in terms of features. Also, a feature model provides a basis for subsequent development, parameterization, and configuration of various reusable assets such as product line requirement models, reference architectural models, and code. Features. Feature modeling identifies a product line s features by identifying externally visible product characteristics in a product line and organizing them into a model. Product features are identified and classified in terms of capability, domain technology, implementation technique, and operating-environment features. Capability features are user-visible characteristics that can be identified as distinct services, operations, and nonfunctional characteristics. Domain technology features represent ways of implementing services or operations. Implementation technique features are generic functions or techniques for implementing services, operations, and domain functions. Operating-environment features represent the environments where the applications are used. Common features among different products are modeled as mandatory features, whereas different features among them may be optional or alternative. Optional features represent selectable features for a particular product line s products, and alternative features indicate that no more than one feature can be selected for a product. In addition, composition rules supplement the feature model with mutual dependency and mutual-exclusion relationships to constrain the selection from optional or alternative features. s. A service in SO is a collection of capabilities grouped together within a particular functional context. 8 The service contains the logic required to carry out these capabilities and provides a service contract describing which are available for invocation. The advertisement and discovery of services is a key principle of SO and an integral part of the service-oriented architecture model. In this model, service providers publish descriptions of their services to a registry. The registry then advertises these services to consumers. consumers typically use a standard service discovery protocol such as Universal Description, Discovery, and Integration (UDDI) to locate services in the registry. 8 From a consumer perspective, the process of identifying and specifying services can be either top down or bottom up. A top-down approach involves identifying an organization s broad functional domains and then identifying high-level candidate services associated with those domains. This approach lets developers understand the system s business context and establish the serviceoriented system boundaries. In a bottom-up approach, the developer typically begins with a use-case analysis of small system components or the business process. In this approach, the developer determines an initial list of services only after conducting a significant use-case analysis for common functional scenarios and subsystem identification. This is usually the case with large projects at a functional domain or department, or at the business unit level. In practice, both approaches are often used simultaneously. In addition, service ontologies can automate the advertisement and discovery of services. 10 An ontology lets consumers and providers share a common set of terms for describing service qualities and constraints. Also, service descriptions include a service-level agreement (SLA) that concerns the terms and conditions of service provision and use that is, what consumers can expect from a provider and restrictions on what consumers can demand from that provider. Comparison. Capability features (services, operations, and nonfunctional characteristics) are, thus, similar to services in an SO. However, features identify a product line s commonality and variability and configure reusable assets, whereas services identify a collection of functionalities along with an SLA of providers and specify an ontology for automated service advertisement and discovery. Hence, on the one hand, dynamic and automated feature binding considering the features quality attributes is basically missing in SPLE. On the other hand, product line variations are difficult to capture explicitly using the notion of services in SO. Dynamic Characteristics of a -Based System -based systems are distributed and composed of various services that can be discovered and replaced at runtime. This dynamic characteristic of SO is closely related to QoS and dynamicservice orchestration. Quality of service. QoS has traditionally been as- May/June 2010 I E E E S O F T W A R E 37

4 Most SPLE approaches focus on configuring product line variations before deployment and don t consider dynamicservice composition. sociated with telephony and computer networking. Certain applications, such as voice over IP (VoIP), might require QoS because such applications have various requirements concerning network data flow (latency, jitter, number of dropped packets, and so on). -based systems consider qualities as constraints on a service s functionality, so mechanisms are necessary to guarantee the expected system quality at runtime. 7 SPLE usually addresses quality issues statically during system design and implementation. Static quality management approaches rely on predicting system properties on the basis of its constituent components properties. 11 If, however, we simply statically predict resource use when developing a service-based system, the product might not have the resources to function correctly at the necessary quality level at runtime. To address this issue, we first statically define QoS in terms of features, with a maximum limit of available resources for each product. We then use this information when the product starts negotiating with service providers to select available services at runtime. Dynamic-service orchestration. To automate the advertisement, discovery, and negotiation of services, participants in a service-based system must share a common set of terms for describing service qualities and constraints. 10 A standard description method facilitates processes such as service advertisement, discovery, selection, composition, substitution, negotiation, and runtime service monitoring. 7 The most prominent standard is the Web s Description Language, which provides a service s location and a functional description of the service s input and output messages. 12 Most SPLE approaches focus on configuring product line variations before deployment and don t consider dynamic-service composition. One way to address this problem is to distinguish between statically configured services (static services) and dynamic services during feature analysis. The configuration of static services can be tailored to each product. However, dynamic services might rely on third-party providers. So, a product must search for such a dynamic service when needed at runtime using the service-oriented architecture. Our proposed solution specifies static services, along with the tasks that constitute them, as workflows, and thus also specifies these services pre- and postconditions, invariants, and dynamic-service interfaces. Finally, by integrating and parameterizing dynamic services at runtime, our solution lets users access static services with dynamic ones. Involvement of Third-Party Providers SPLE promotes systematic reuse within an organization and usually doesn t consider external organizations when developing reusable assets. Moreover, relying on third-party providers and promoting the use of their services was out of scope for SPLE. The closest thing to third-party involvement that SPLE considers might be the use of commercial off-the-shelf (COTS) components. In SO, however, third-party involvement is one of the main drivers that makes this approach attractive, and it leads to several initiatives, including service negotiations, service monitoring, and service reputation systems. negotiations. Negotiation refers to a communication process that supports coordination and cooperation. 13 In terms of a software-as-a-service model, negotiation involves the interaction between a service consumer and one or more service providers identified through discovery, or providers that are already known to the service consumer. Negotiation with service providers can lead to SLAs for services that better meet consumer requirements. monitoring. monitoring is another process for detecting service failures and SLA violations at runtime. This is an increasingly important research issue, as continually more companies conduct business over the Internet. monitors can determine whether services meet the terms and conditions of the SLAs between service consumers and providers. 14 An SLA contains specific guarantees for the QoS that a consumer expects a provider to supply. SLAs must be monitored and audited for service provider compliance to provide real QoS guarantees to the consumer. 14 The SLA could also contain conditions of use that the service provider imposes on the consumer, and service monitors could ensure compliance with these conditions as well. Emergent system qualities can result from the service composition process, and from changes in the runtime environment. These emergent qualities require a dynamic runtime quality assurance approach that service monitors can facilitate. reputation systems. In a service-oriented marketplace, transactions often occur between parties that haven t previously interacted. Reputation systems are collaborative mechanisms that address trust issues between such parties, and they help distinguish between low- and high-quality service providers. 15 Including provider reputation in the service selection criteria benefits the quality assurance process. 38 I E E E S O F T W A R E w w w. c o m p u t e r. o r g / s o f t w a r e

5 QoS framework. Traditional SPLE approaches don t consider these three key aspects of dynamicservicprovision, but SOPL methods should incorporate them. Therefore, we propose a QoS-aware framework that provides automated runtime support for service discovery, negotiation, monitoring, and service provider rating. QoS awareness lets consumers handle recovery from SLA violations, service failures, and runtime environment limitations by renegotiating and substituting problematic services. Variation Control and Management In SO, given the emergence of a service marketplace where multiple providers supply functionally equivalent services that implement a common service type, nonfunctional QoS properties are the criteria for distinguishing one provider from another. providers, therefore, need a standard method for describing the nonfunctional characteristics of the services they offer. Several recently proposed ontology-based initiatives can reduce the ambiguity of describing nonfunctional attributes and enable better service selection. 10 However, in SPLE, it s also important to explicitly tailor a product s configuration to consumer needs. For example, if a specification stipulates that a product configuration must not include a service feature, the associated service shouldn t be bound to that product even though the service providers are available at runtime. Our approach adapts the C2 architecture style, which provides flexibility through a layered structure and modular components, called bricks. 6 In this approach, we establish an explicit mapping relation between features and architectural components (bricks) so that selecting the features for a product generates a corresponding product configuration. After configuring a product architecture, the developer integrates reusable components into each brick by following the specifications described in the components, such as selecting precoded components, filling in skeletons, or instantiating parameterized templates. Our Feature-Based Approach Our approach provides a possible solution for developing core assets in a SOPL. 6,7 This approach overcomes the challenges we discussed earlier by identifying appropriate dynamic services, adapting feature analysis to supplement service identification techniques, adapting service orientation to enhance the runtime flexibility of product lines, and Feature analysis Feature model analysis Workflow services Dynamic services Quality of service (QoS) goals Workflow specification and development Dynamic services, QoS, strategy specification s to be searched strategies incorporating variation points into services to more explicitly control product line configurations. Figure 1 shows the main activities in this approach. Feature Analysis By using both feature and service analysis, we can reconcile the different notions of first-class objects. Feature analysis identifies externally visible characteristics of the products in a product line in terms of features and organizes them into a feature model. This model captures a product line s commonality and variability by using different types of features: mandatory, optional, and alternative. Figure 2 shows a feature of a VO product line. Analysis and Specification analysis provides a mechanism for mapping the feature model onto services (addressing the dynamic characteristics of service-based system challenges). This activity classifies features into one of two categories: workflow services and dynamic services. Workflow services define service transactions (behaviors), whereas dynamic services are used to execute workflow services at runtime. The next activities (see Figure 1) specify and develop the workflow services, as well as the identified dynamic services and their QoS levels. A workflow service s behavior can t be changed at runtime, but the foremost concern is the correctness of its behavior when it uses dynamic services. The availability of dynamic-service features shared by workflow services depends on the ser- Workflow control components System integration and deployment ratings brokering and monitoring Negotiated services Figure 1. Activities of our serviceoriented product line development approach. 7 Arrows indicate the data flow and show which work products each activity uses. May/June 2010 I E E E S O F T W A R E 39

6 Environment visualization Smart business trip Composition rules: Auto log-on feature requires an RFID-based user positioning method. Virtual office Follow me Virtual printer Access point based User-positioning method Mandatory feature Optional feature Alternative feature Composed of Figure 2. A feature model of a virtual office. Auto log-on vice providers. The system must search for and integrate dynamic services into the system at runtime. Dynamic services are specified using pre- and postconditions, along with invariants that must be satisfied when those services are provided. Depending on their availability, dependent dynamic services might be bound to workflow services. Moreover, the system must check a precondition regarding whether a feature is selected for a particular product configuration. If the feature isn t selected for that product configuration, the service can t be provided, even though the service provider is available at runtime. To automate the advertisement, discovery, and negotiation of dynamic services, participants in a service-oriented architecture must share a common set of terms for describing service qualities and constraints. Our approach incorporates a pluggable ontology that combines an XML quality schema with a service strategy schema. 7 This ontology facilitates the description of services and service contracts in terms of functional attributes and nonfunctional qualities. It also provides a way to describe a service instance. The service description includes a lease description, a service contract, and universally unique identifiers (UUIDs) for both the service instance and the service provider. The service contract can have any number of service quality and operation contract elements. The former describe individual service-level qualities; the latter describes each invokable operation Smart fax Generalization or specialization RFID based that the service provides. The quality description schema allows for expressing arbitrary qualities in terms of constraints, measurement units, values, and types. The strategy schema enables the expression of strategies, which describe ideal services and service compositions. Strategies also specify acceptable limits on the values of service- and operation-level quality constraints. 7 System Integration and Deployment In the C2 architecture style, a brick can have its own thread, and it can send and receive messages to and from other bricks through its top and bottom ports. We ve extended the C2 style to include two different types of bricks: workflow and dynamic service. Workflow bricks deploy orchestrating services, whereas dynamic-service bricks deploy dynamic services. For dynamic services, it s possible to deploy either a real service or a proxy to an external service as a brick. Additionally, a configurator manages dynamic reconfiguration of the deployed product at runtime. The runtime system interacts with service providers through an automated negotiation broker. This broker incorporates a consumer strategy with pluggable QoS negotiation, a QoS ontology, and SLA evaluation, as well as a provider-rating system to ensure service acceptability. Our proposed QoS-aware framework facilitates system integration and deployment. Through this framework, dynamic-service consumers and providers supply the broker with templates specifying strategies for the SOPL services they require or provide. For consumers, the strategy describes the ideal QoS requirements of the functional services they wish to use. The negotiation broker incorporates an engine builder, which uses the templates to assemble a customservice broker engine for processing negotiation messages and service proposals. The proposal engine creates and evaluates service proposals, and matches a consumer with a service provider by considering the QoS requirements. The QoS framework also provides a servicemonitoring system, which actively monitors the quality of negotiated services for emergent changes, SLA violations, and failures. The framework s primary monitoring approach is a passive model, which transparently intercepts service requests and responses between service consumers and providers. This monitor is always aware of the QoS requirements and triggers a new negotiation whenever the SLA is violated at runtime. Finally, the framework includes a reputation system that provides consumers with a method of shar- 40 I E E E S O F T W A R E w w w. c o m p u t e r. o r g / s o f t w a r e

7 ing service experiences, and adds additional criteria to the service negotiation process. We re exploring better ways to tailor the service granularity of an SOPL to enhance reusability. We also plan to incorporate consumer context monitoring to improve quality assurance. References 1. J. Bosch et al., Variability Issues in Software Product Lines, Proc. Software Product-Family Eng., LNCS 2290, Springer, 2002, pp D. Garlan and B. Schmerl, Model-Based Adaptation for Self-Healing Systems, Proc. 1st Workshop Self- Healing Systems (WOSS 02), ACM Press, 2002, pp S.S. Yau et al., Reconfigurable Context-Sensitive Middleware for Pervasive Computing, Pervasive Computing, vol. 1, no. 3, 2002, pp J.P. Sousa and D. Garlan, Aura: An Architectural Framework for User Mobility in Ubiquitous Computing Environments, Proc. 3rd IEEE/IFIP Conf. Software Architecture: System Design, Development, and Maintenance, Kluwer Academic Publishers, 2002, pp S. Hallsteinsen et al., Dynamic Software Product Lines, Computer, vol. 41, no. 4, 2008, pp J. Lee, D. Muthig, and M. Naab, An Approach for Developing Oriented Product Lines, Proc. 12th Int l Software Product Line Conf. (SPLC 08), IEEE CS Press, 2008, pp G. Kotonya, J. Lee, and D. Robinson, A Consumer- Centered Approach for -Oriented Product Line Development, Proc. Working IEEE/IFIP Conf. Software Architecture (WICSA 09), IEEE Press, 2009, pp T. Erl, -Oriented Architecture (SOA): Concepts, Technology, and Design, Prentice Hall, K. Lee, K. Kang, and J. Lee, Concepts and Guidelines of Feature Modeling for Product Line Software Engineering, Proc. Software Reuse: Methods, Techniques, and Tools, LNCS 2319, Springer, 2002, pp G. Dobson, R. Lock, and I. Sommerville, QoSOnt: A QoS Ontology for -Centric Systems, Proc. 31st Euromicro Conf. Software Eng. and Advanced Applications, IEEE CS Press, 2005, pp F. Lunders et al., Using Software Component Models and s in Embedded Real-Time Systems, Proc. 40th Ann. Hawaii Int l Conf. System Sciences (HICSS 07), IEEE CS Press, 2007, p. 286c. 12. E. Christensen et al., Web s Description Language (WSDL) 1.1, World Wide Web Consortium (W3C) note, Mar. 2001, J. Yan et al., Autonomous Level Agreement Negotiation for Composition Provision, Future Generation Computer Systems, vol. 23, no. 6, 2007, pp A.C. Benjamim et al., Independently Auditing Level Agreements in the Grid, Proc. 11th Hewlett-Packard OpenView Univ. Assoc. Workshop (HPOVUA 04), Hewlett-Packard OpenView Univ. Assoc., 2004, pp A. Jøsang, R. Ismail, and C. Boyd, A Survey of Trust and Reputation Systems for Online Provision, Decision Support Systems, vol. 43, no. 2, 2007, pp About the Authors Jaejoon Lee is a lecturer in the School of Computing and Communications at Lancaster University. His research interests include software product line engineering, software architecture, and service-based software engineering. Lee has a PhD in computer science and engineering from Pohang University of Science and Technology. Contact him at j.lee@ comp.lancs.ac.uk. Gerald Kotonya is a senior lecturer in the School of Computing and Communications at Lancaster University. His research interests include software architecture, and serviceoriented and component-based software engineering, especially novel ways of architecting, visualizing, and evolving self-managing, hybrid, service-oriented systems. Kotonya has a PhD in computer science from Lancaster University. He s a chartered engineer and a member of the IEEE Computer Society. Contact him at gerald@comp.lancs.ac.uk. Selected CS articles and columns are also available for free at COMPUTING THEN Learn about computing history and the people who shaped it. computer.org/ct May/June 2010 I E E E S O F T W A R E 41