A Life-Cycle Model for Software Service Engineering

A Life-Cycle Model for Software Service Engineering Erik Wittern1 and Robin Fischer2 1

eOrganization Research Group FZI Research Center for Information Technology [email protected] 2 eOrganization Research Group Karlsruhe Institute of Technology (KIT) [email protected]

Abstract. Applying existing life-cycle models to software service engineering, we identify shortcomings: they do not focus on engineering activities, lack a clear underlying definition of software services, do not address both service roles of consumer and provider, and assume longevity and sequence of activities. We present a life-cycle model for software service engineering to tackle these shortcomings. We illustrate the model’s prescriptive use by applying it to assess software service variability and software service standardization. Keywords: Software service engineering, service variability, cloud standards.

1

Introduction

The Internet has fundamentally changed the nature and delivery of services. Providers of software services can effortlessly serve a tremendous amount of globally distributed consumers. Methods and tools, best practices, and structureproviding methodologies are required for providers to efficiently develop and provision services. Service consumers require support to master consumptionrelated tasks like service selection, service integration, or system scaling. Software service engineering is the systematic application of methods and tools for the creation and provision of a software service. Life-cycle models structure service engineering. Their nature is descriptive in that they capture common service engineering approaches. In addition, life-cycle models are prescriptive in that they guide providers in service development and provision and consumers in service consumption. They denote relevant activities at different stages of the life-cycle and recommend their order. Despite the important role that life-cycle models play, we find that current models have flaws with regard to service engineering. Many models have broad focus (e.g., include organization aspects), hampering their applicability to software service engineering. Also, the service concept underlying most service life-cycle K.-K. Lau, W. Lamersdorf, and E. Pimentel (Eds.): ESOCC 2013, LNCS 8135, pp. 164–171, 2013. c Springer-Verlag Berlin Heidelberg 2013

A Life-Cycle Model for Software Service Engineering

165

models is not made explicit or is too generic. Many models focus on provider activities, leaving the consumer side open. Finally, many models imply a longevity and sequence of activities that does not necessarily reflect reality. To overcome these problems, we discuss software service in section 2. We relate to existing work in section 3. In section 4, we present our software service life-cycle model. We illustrate its prescriptive use by discussing a) activities to support service variability and b) software service standardization in section 5. Section 6 concludes our findings and gives an outlook to future work.

2

Tems and Definitions

Generic Services. A service, generically, is “[...] an abstract resource that represents a capability of performing tasks that form a coherent functionality from the point of view of providers entities and requesters entities. To be used, a service must be realized by a concrete provider agent.” [14]. The involvement of two roles, namely provider and consumer, is a universal characteristic of services. Generically, the provider performs activities for the sake of the consumer. In return, the consumer compensates the provider, e.g., in form of payments. Some authors identify additional roles (cf. [7]), like service creator or the service broker in Web services. Because these roles are only sensible in particular contexts, we concentrate on the two fundamental roles (and assume the provider to have also created the service). Considering services as activities reveals their procedural nature. Services take an input, often provided by the consumer in form of information or physical goods, and transform it. Services enable consumption on demand. Service consumers can invoke a service (only) when they actually need them. Software Services. Given these fundamental characteristics of services generically, we now focus on software services. We define a software service as a deployed capability that is realized by software and provided and consumed on-demand over networks. This conceptual view of software services is illustrated in Figure 1. On the left side, software depicts the implementation of a capability to be provided as a service. The capability that the software realizes can be an application, a platform, or even an infrastructure. The implementation contains the specification of interfaces. The interfaces are, however, not accessible before the software is deployed. Through deployment, the capability is made accessible to consumers, transforming software into a software service. Technically, through deployment the software is packed (e.g., within a jar or virtual machine) and loaded into an execution environment (e.g., a Web server or virtual infrastructure). The interfaces defined as part of the software are made accessible to consumers by the execution environment as service interfaces. The necessity of software services to be deployed is important to differentiate them from classical software products. The concept of software services comprises sub-ordinate service classes, two of which we introduce in the following. Web services denote software that provides

166

E. Wittern and R. Fischer

Execution environment Specification, design, implementation

Software (status: offline)

Deployment

Software service (status: deployed)

Specification, design, implementation, deployment, operation

Service interfaces

Fig. 1. Software service engineering

interoperable machine-to-machine interaction over a network [14]. Atomic Web services provide a single functionality while composite services compose multiple Web services. Composite Web services can, again, be offered as service, making composition a recursive operation [5]. Another class of software services are cloud services. Cloud computing is about on-demand provisioning of scalable, networkcentric, abstracted IT infrastructures (IaaS), platforms (PaaS) and applications (SaaS) with a pay-per-use model, utilizing virtual processing and storage resources [2]. While cloud services build on Web service standards, cloud standard challenges remain, e.g. managing virtual compute or data resources.

3

Related Work

Life-cycle models define phases that a software or service goes through from its conceptualization to its discontinuation. The goal of such models is to provide an overview and order of tasks that are relevant for provision and consumption. Software life-cycle models have long been guiding the practice in the software engineering domain. They define a set of related activities whose execution leads to the creation of a software product. These activities typically are specification, design and implementation, validation, and evolution [13]. Sequential, noniterative descriptions, often referred to as waterfall models, were first formally described in the 1970s [12]. Recommending approaches foresee that activities are repeatedly executed to refine software or to continuously approve and adapt it. For example, the correspondingly named spiral model [4] or the development models used in agile development [1] are cyclic by nature. An example of a flexible and iterative software life-cycle model is Rational Unified Process (RUP). It includes four phases, namely inception, elaboration, construction, and transition, and activities performed in them, referred to as workflows [9]. Software life-cycle models focus on engineering tasks. Service life-cycle models are diverse, addressing different service types and different scopes. IT governance, applies service life-cycle models to prescribe the introduction and enforcement of company-wide policies for adopting and operating service-oriented architectures [7]. The Information Technology Infrastructure Library (ITIL) encompasses the phases service design, transition, and operation as well as a variety of related processes. The Web service development life cycle denotes a methodology to software service engineering, fostering analysis, change, and evolution


167

of Web services [11]. Engineering cloud service comprises requirements, discovery, negotiation, orchestration, and consumption and monitoring phases [8]. Recently, DevOps proposes the integration of development and operation activities independent of a service’s status [6]. Assessing how the presented service life-cycle models reflect software service characteristics, we notice the following shortcomings: Missing focus on consumption: IT governance and management models provide holistic views, encompassing organizational aspects. Agile and DevOp methods focus on parallel provider activities. However, integration of engineering-related aspects of consuming software services is missing. Coupling activities with service status: In service engineering, activities can be performed independent of the service’s status. For example, while a service’s status is running, providers and consumers may perform design activities to evolve the service or, respectively, plan its consumption. Current models assume coupling of service status and activities. Implied longevity of activities: Frequently used phases imply that a service remains in a corresponding engineering activity for long time. However, activities may in reality only be short-lived, e.g. deployment to cloud infrastructure can be a matter of seconds.

4

Our Software Service Life-Cycle Model

Our software services life-cycle model is inspired from existing approaches in software engineering (especially the RUP) and (Web) service engineering. It considers three dimensions: (1) two service status, (2) five types of activities, and (3) two roles, namely providers and consumers. Service Status are offline or deployed. While a service is offline, it is not available for consumers. The two status are mutually exclusive, i.e. a service may only be in one status of the two status at a given time. A service’s status impacts how activities are performed in software service engineering. For example, changing a deployed service requires deployment activities to be performed so that continuous service availability is ensured. A service’s status is global in that it affects both provider and consumer activities. Activity Types include specification, design, implementation, deployment, and operation. An overview of the set of provider and consumer activities and their typical sequence is provided in Figure 2. Similar to software engineering [13], specification activities define requirements and constraints on service provision or consumption. Both, provider and consumer check the technical feasibility and perform, e.g., requirements analysis, specification, or validation. Providers will focus more on the realizability of a service, while the consumer will, e.g., analyze whether to consume a service. Consumers perform a service candidate identification in cohesion with the feasibility and requirements activities.

168


Operation Consumer - Invoke service - Monitor operation (QoS) - Trigger service adaptation - Terminate consumption

Specification

Provider - Monitor & maintain service - Ensure QoS - Realize adaptation - Discontinue service

Consumer - Feasibility study - Requirements analysis, specification, & validation - Identify service candidates

Deployment Consumer

Provider - Feasibility study - Requirements analysis, specification, & validation

Design

Provider - Deploy software - Undeploy service - Redeploy service

Consumer - Select service - Conceptualize consumption - Participate in provider's design

Provider - Define service concept (e.g., ontology, workflows, architecture, components, interfaces)

Implementation Consumer - Implement client - Integrate service (e.g., migrate data)

Provider - Implement software - Test & validate software

Fig. 2. Common provider and consumer activities

In design activities, service providers conceptualize the service and its provision. Results are the service’s architecture, components, data models, or algorithms. In contrast to software design, software service design activities include service interfaces, deployment, and runtime methods and tools. The consumers’ design activities plan and conceptualize service consumption. Based on requirements, preferences, and service candidates, service selection is performed. New interfaces or systems to integrate the service with are conceptualized. Service providers apply implementation activities to realize the service based on designs. Implementation includes the development of the software artifact, its testing, and validation. Service consumers realize the envisioned service consumption. Contracting must be performed with the provider, specifying e.g., the service’s price or service level agreements (SLAs). The consumer’s implementation activities also include the creation of client components. Integration efforts may be required to utilize a new service with existing services or systems. When utilizing services to host systems or data, e.g., cloud infrastructure services, migration of these systems and / or data is required [10]. Deployment activities transfer the software implementation to a deployed status. We differentiate deployment from implementation activities as they do not necessarily co-occur. For example, recurring deployment of once implemented cloud services is a common approach to realize horizontal scalability [2]. undeployment transfers a service’s status back to being offline. Provider-side operation activities ensure ongoing service provision matching quality of service (QoS) properties. The provider maintains the service, reacting e.g., to errors, changing amounts of requests and resulting performance impacts, or adaptation needs. When the provider decides to discontinue the service provision, corresponding activities, e.g., data retrieval or consumer notification, may be required. The consumer’s operation activities include, foremost, the actual invocation of the service. Furthermore, consumers may trigger service adaptation, e.g., in reaction to changed context. When terminating consumption, consumers may have to retrieve their data or actively dissolute running contracts. Figure 1 summarizes the relationship of status, activities and software services. Gray arrows indicate activities on the service. While the service is offline,


169

specification, design, implementation activities can be performed. Deployment activities lead to a transition of the status. While the service is in deployed status, any activity can be performed. This characteristic of our life-cycle model allows, e.g., consumers to perform design activities while a service is deployed. Such flexibility is not supported by existing service life-cycle models.

5

Applying the Software Service Life-Cycle Model

We illustrate the usage of our model in a prescriptive way for software service engineering in this section. Software Service Variability Service variability denotes the capability of a service to be provisioned in variants. Variant selection depends on context, e.g., on consumer or provider requirements and preferences or external factors. We use our life-cycle model to structure these activities (see Figure 3). For providers, offering service variability begins with feasibility assessment as a specification activity. In design activities, providers conceptualize, assess, and select variants, using, e.g., methods from software product line engineering [15]. Providers implement selected variants to be offered to all consumers or customized variants offered only to a subset of consumers. Implemented variants are deployed, either in parallel or as a single service where variability is often realized through multi-tenancy [2]. Re-deployment furthermore realize variability. Operation activities concern the adaption of a service. Consumers specification activities concern the impact of variability for consumption. For example, the flexibility and configuration options that variability brings might strengthen the case for service consumption. Consumers’ design activities include selection of service variants. Configuration can be used to select a service variant through provision of predetermined information. Implementation activities concern client variants. Operation activities include assessing the consumption of the service variant and eventually triggering adaptation. Adaptation may be performed solely as an operation activity, if changing the service variant does not require re-deployment or selecting another service all together. Operation Consumer - Assess variant consumption - Trigger service adoption

Specification

Provider - Adapt service on demand

Consumer - Consider impact of variability on service consumption

Provider - Assess feasibility of providing service variability

Deployment Consumer

Design

Provider - (Re-) deploy selected variant

Consumer - Select service (considering variability) - Select & compose variants

Provider - Define & assess variants (e.g., utilizing modeling) - Select variant(s) to provide

Implementation Consumer - Implement variant-specific interfaces

Provider - Implement variants (for all consumers) - Implement consumer-specific variants (customization)

Fig. 3. Service variability activities throughout our life-cycle model

170


Software Service Standardization. Standards define rules, guidelines or features for generic and repeated use. Using standards in service engineering reduces complexity of decisions, e.g., while specifying or designing interfaces. Existing standards classifications assess standards according to main contributions. Selecting standards according to status, activity or role of the service engineering life-cycle, however, is not supported. Table 1 shows three standards for engineering cloud service that a recent study classified most mature [3]. While not being representative for the current state of standardization, we use these examples to illustrate the use how our life-cycle model in classifying standards for service engineering. The Cloud Data Management Interface (CDMI) defines an interface for storing and managing data in the cloud. CDMI affects specification and design activities of both provider and consumer in offline status. Providers benefit from adopting CDMI because it guides the specification and design of functional and managerial data interfaces. Likewise, consumers receive guidance for identifying their requirements or for evaluating general capabilities of potential cloud services. CDMI further provides guidance to consumers in designing a specific service consumption. The standard supports selection of services based on functional requirements through querying capabilities. Moreover, CDMI offers service consumers guidance for operating their cloud storage. For example, it addresses data management abstractions or access rights management capabilities. The Open cloud Computing Interface Core (OCCI) defines a set of interfaces and protocols to manage cloud compute resources. It supports the specification and design of software artifacts for providers and consumers. Similar to CDMI, OCCI defines functions for the discovery of a service’s capabilities. In doing so, OCCI supports consumers with design activities for deployed services, e.g., feature-based selection among a set of cloud compute services. The Open Virtualization Format (OVF) describes a file and exchange format for virtual appliances. It provides guidance for service providers and consumers for specifying and designing software features while the service is offline. Moreover, OVF supports consumers with operating the services as it provides the format that is used to import and export virtual machines. Table 1. Example: Classification of cloud standards Standard Scope CDMI

OCCI

OVF

Roles Provider, Cloud Data Management Consumer Interface Provider Provider, Interface and protocol for Consumer managing cloud infrastructures Provider Provider, File and exchange format for Consumer virtual appliances Consumer

Status

Activities

Offline

Specify, Design

Deployed Design, Operate Deployed Design Offline

Specify, Design

Offline

Specify, Design

Deployed Operate


6

171

Conclusion

We presented a software service life-cycle model for the engineering of service provisioning and consumption. It considers the dimensions service status, activities, and roles. Our model is capable to foster the discussion about activities related to service variability. It states and structures the activities of providers and consumer when engineering or consuming variable services. The presented classifications of cloud service standards allow to better understand these approaches in the context service engineering. Having influence on the evolution of software service engineering approaches or their uptake, our life-cycle model acts in a prescriptive way. We will use this model in future work as a framework to structure discussions about software service engineering approaches.

References 1. Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J.: Agile Software Development Methods. Review and Analysis. VTT Publications (2002) 2. Baun, C., Kunze, M., Nimis, J., Tai, S.: Cloud Computing. Web-Basierte Dynamische IT-Services, Springer-Verlag New York Incorporated (March 2011) 3. BMWi: The standardisation environment for cloud computing. Tech. rep. (2012) 4. Boehm, B.W.: A Spiral Model of Software Development and Enhancement. Computer 21(5), 61–72 (1988) 5. Curbera, F., Khalaf, R., Mukhi, N., Tai, S., Weerawarana, S.: The next step in Web services. Communications of the ACM 46(10), 29–34 (2003) 6. Humble, J., Farley, D.G.: Continuous delivery: reliable software releases through build, test, and deployment automation. Addison-Wesley, Upper Saddle River (2010) 7. Janiesch, C., Niemann, M., Steinmetz, R.: The TEXO governance framework. Tech. rep., SAP Research (2011) 8. Joshi, K.P., Finin, T., Yesha, Y.: Integrated Lifecycle of IT Services in a Cloud Environment. In: Proceedings of the Third International Conference on the Virtual Computing Initiative (ICVCI 2009), Research Triangle Park, NC (2009) 9. Kruchten, P.: The Rational Unified Process: An Introduction, 3rd edn. AddisonWesley (2004) 10. Menzel, M., Ranjan, R.: CloudGenius: Decision Support for Web Server Cloud Migration. In: Proceedings of the 21st International Conference on World Wide Web (WWW 2012), Lyon, France, pp. 979–988 (March 2012) 11. Papazoglou, M.P., Van Den Heuvel, W.J.: Service-oriented design and development methodology. International Journal of Web Engineering and Technology 2(4), 412– 442 (2006) 12. Royce, W.W.: Managing the Development of Large Software Systems. In: Proceedings of IEEE WESCON, pp. 1–9 (August 1970) 13. Sommerville, I.: Software Engineering, 9th edn. Addison-Wesley (2011) 14. W3C Working Group: Web Services Glossary (2004), http://www.w3.org/TR/ws-gloss/ (accessed February 21, 2013) 15. Wittern, E., Schuster, N., Kuhlenkamp, J., Tai, S.: Participatory Service Design through Composed and Coordinated Service Feature Models. In: Liu, C., Ludwig, H., Toumani, F., Yu, Q. (eds.) ICSOC 2012. LNCS, vol. 7636, pp. 158–172. Springer, Heidelberg (2012)