Software Product Lines and Service Oriented Architectures: can they be connected?

Software Product Lines

Software Product Lines

Software Product Lines

Software Product Lines

and Service Oriented

and Service Oriented

and Service Oriented

and Service Oriented

Architectures: can they be

Architectures: can they be

Architectures: can they be

Architectures: can they be

connected?

connected?

connected?

connected?

Bibliographical study

Paul-Alexandru Istoan

[email protected]

Supervisor: Jean-Marc Jezequel

[email protected]

INSA, IFSIC, IRISA, Triskell Project

February 2009

Introduction

Service-oriented architecture (SOA) and software product line (SPL) are currently two approaches that get a lot of attention in research and practice. They both promise to aid in the development of flexible, cost-effective software systems and to support a high level of reuse.

These approaches to software development share a common goal. They both encourage an organization to reuse existing assets and capabilities rather than redeveloping them again and again for new systems. These approaches enable organizations to gain enormously on reuse. They are able to achieve many desired benefits such as productivity gains, decreased development costs, and improved time to market, higher reliability, and competitive advantage [17].

We can state their distinct goals as:

• SOA: “enable assembly, orchestration and maintenance of enterprise solutions to quickly react to changing business requirements”

• SPL: “systematically capture and exploit commonality among a set of related systems while managing variations for specific customers or market segments”.

At the same time, from a different perspective, they are quite different from one another: while Software Product Lines focus on one producer alone developing a set of systems based on a common platform, most members of the SOA community propose systems consisting of loosely coupled services [1]. In any case, the services are usually developed by various companies. In general, services are dynamic computational elements composed into applications, whereas the products in a software product family are usually derived by reusing and resolving variability in static elements, often referred to as components.

Contributions about the possible connections between both development approaches, SPLs and SOAs, are starting to emerge in the software community. Current research directions focus mainly on trying to find pertinent answers to questions like “can web services support product lines using a service-oriented architecture?” or “How can use of product line practices support web services and service-oriented architectures?”.

The purpose of this report is to present a state of the art perspective on what has been done so far and which are the major trends for service-oriented architectures and software product lines.

Therefore, the rest of this report will be structured in the following way: a brief description of Software Product Lines in Section 1. Section 2 will provide an overview of the concept of Service Oriented Architecture. In Section 3 we focus on a systematic comparison of SPL and SOA. We also try to see what the possible connections between them might be and understand how one might help the other. Finally, Section 4 draws conclusions for future directions to take in combining service-oriented architectures and software product families.

1. Software product lines

Software product lines, or software families, are rapidly emerging as a viable and important software development paradigm [2]. Important companies, such as Hewlett-Packard, Nokia, or Motorola, are proving that using a product line approach for software can generate important quantitative and qualitative improvements in productivity, time to market and customer satisfaction. This practice can also efficiently satisfy the current need for mass customization of software. Being a relatively new concept, product lines are rapidly evolving as a practical and important software development paradigm. Their growing success is due to their ability to offer companies ways to exploit their software products’ commonalities to achieve economies of production.

Formally, a software product line is “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 that are developed from a common set of core assets in a prescribed way” [2].

The main idea behind Software Product Line (SPL) is to capture the essential concepts of “commonality” and “variability” between a set of software products sharing a common, managed set of features that satisfy the specific needs of a particular market segment. Rather than describing a single software system, the model of a software product line describes the set of products in the same domain. This can be accomplished by distinguishing between elements common to all the products of the line, and elements that may vary from one product to another. It also relies on the reusability of core assets, which form the basis of the product line, rather than working from scratch. These core assets may include the architecture, reusable software components, domain models, requirements statements, documentation and specifications, test plans, test cases and process descriptions [3].

Adopting the SPL approach implies performing two main activities: 1) The domain engineering activity is characterized by:

- collecting, organizing, and storing past experiences in building systems in the form of reusable assets in a particular domain,

- providing an adequate means for reusing these core assets when building new systems 2) The application engineering activity consists in building systems based on the results of Domain Engineering. We select the requirements from the existing domain model, which matches the customer’s needs. We assemble applications from the existing reusable components.

Figure 1 presents a graphical representation of the general process of Product Line Engineering, as found in the literature [4].

The remainder of this section will present an overview of the two major aspects of SPL engineering mentioned above.

Domain engineering deals with the “common set of core assets” serving as a base to

develop features “that satisfy the specific needs of a particular market segment or mission”. It starts with a domain analysis phase that identifies commonalities and variability amongst SPL members. The next step, the domain design, consists in establishing the product line architecture. Finally, during the domain implementation, the

architecture defined during the domain design as software components will be implemented [5].

Figure 1: the general process of product line engineering

There are two popular techniques to define software product lines requirements: Feature Modeling and Use Cases.

As presented in [6], a feature is “a prominent or distinctive user-visible aspect, quality or characteristic of a software system or systems”. Variability amongst features is usually depicted using a FODA feature diagram. It is represented as a tree whose root denotes a feature which is progressively decomposed using mandatory, optional, alternative and OR-features. In feature diagrams, mandatory features are features which are always included in every product. Feature that are not necessarily included in every product are qualified as variables. Variation points are features that have at least one direct variable sub feature. In order to make them more expressive, certain extensions have been added to feature diagrams, like: annotation with cardinalities, attributes as a way of representing choice, relationships like consists-of or is-generalization-of, grouping features in categories and a mechanism of modularizing these diagrams.

Use Cases [7, 22] are a popular notation to describe requirements of a software system in such a way that the final user can understand and modify these descriptions. They are hence excellent candidates to perform the elicitation of a SPL behavior. Standard use case constructs can be used to represent variability amongst use cases: the use of extend relationship, extensions points and include relationship, as illustrated by [23]. However, major shortcomings with this approach come from the fact that use cases were initially meant to describe scenarios of a single system, not a collection of systems differentiated by variants. Therefore, several extensions were proposed to extend both textual and UML-based use case notations in order to improve variability support amongst software product lines.

An approach, called Product Lines Use Cases, is introduced in [24] in order to extend use cases with the explicit description of variability. They propose to add three types of

tags: alternative, optional, parametric to model variants in the use case text which have to be substituted by the actual value for a given product.

A major contribution comes from the introduction of extensions to the UML notation for variability support. Gomaa [23] uses the following stereotypes: <<kernel>> to distinguish the use cases that must be supported in all products; <<alternative>> to distinguish the use case for which a choice must be made; <<optional>> used to define use cases required by some but not all members; of the family.

It may be interesting to combine feature diagrams and use cases, the former providing a clear overview of the variations handled within the SPL while the latter provides a more fine-grained description of product behavior via scenarios.

Application Engineering: also known as product derivation, it is the specific activity

of developing the set of software intensive systems from the common set of core assets. The PL derivation consists in generating from the PL model the UML class diagram of each product. According to the derivation technique used, currently available approaches to support product derivation can be organized in two main categories: configuration and transformation.

Product Configuration [25] originates from the idea that product derivation activities should be based on the parameterization of SPL core assets. When all SPL members can be completely characterized an automated derivation process can be devised. Product derivation relies on selecting product features according to the variants offered by the product line requirements description. Then, a configuration tool selects and assembles core assets automatically according to a decision model. This decision model contains the necessary constraints and traceability information in order for the configuration tool to make the right decision to generate a viable particular product.

Several configuration-based approaches for product derivation based their decision models on feature models. In [26] the FODA approach is extended in order to support the description of domain assets at the design level. This idea is also explored in [27] through the concept of “staged configuration”: every time the user makes a choice in the feature model, a new feature model is computed according to user choices at a lower stage. There are also configuration approaches that do not base their decision model on feature model. In [28], we have a decision model that relates features to their realizing software and hardware assets and the contextual information which provides additional constraints in a single model.

Product Derivation by Transformation introduces MDE techniques in order to support product derivation. Although an ongoing research area, by providing models as useful abstractions to understand assets and transformations able to use them as first-class artifacts for product generation, MDE approaches will clearly play a major role in SPL engineering and product derivation in the near future.

[KMHC05] proposes, for product derivation, to instantiate, via MDA transformation mechanisms, a framework embodying core assets on the basis of a decision model and according to the variants selected for a specific product. Then, for application parts which are not implemented in the framework, an integration phase takes place, resulting in a single product model.

The most promising approach so far comes from [3]. Ziadi and Jezequel put the emphasis on product derivation at the design level both for static and behavioral aspects,

unlike the other approaches that focus on the whole SPL engineering activities. Static models are described in terms of UML class diagrams. The derivation process uses a decision model taking the form of a design pattern to display the variants available for each product. In a first derivation step, variants are selected in this model and relevant classes are automatically selected. In the second and third steps, unused variants are removed and the model is optimized. Behavioral derivation is based on the synthesis of state machines from scenarios that have been algebraically formalized at the domain engineering level and automatically derived using a partial evaluation technique.

In recent years, the attention is turning towards developing automated product derivation techniques. This is because of the lack of flexibility of automated product derivation approaches. They do not allow products meeting unforeseen, customer-specific, requirements. Moreover, approaches that consider this issue do not provide adequate methodological guidelines nor automated support. In [30], the authors proposed a product derivation (PD) process which is a tradeoff between automation and flexibility. They demonstrate how by combining well-known PD approaches, it is possible to provide tool support automating a significant part of this process. The paper also proves the utility of MDE techniques for SPL engineering.

2. Service oriented architectures

Modern enterprises need to respond effectively and quickly to opportunities in today’s constantly changing and increasingly competitive global markets. In order to assure business agility, enterprises are advised to expose their various in-house applications found spread throughout the enterprise in a highly standardized manner. A current approach for addressing these critical issues is embodied by services that can be easily assembled to form a collection of independent and loosely coupled business processes. The rapid evolution of Web services as a support for business integration has driven major technological advances in the area of service-oriented architectures (SOA). [8]

A SOA is also designed to allow developers to overcome many challenges in an enterprise like application integration, transaction management, and security policies. The goal of SOA, as mentioned in [9] is to eliminate these barriers so that applications integrate and run smoothly. In this way, a SOA can deliver the flexibility and agility that business users require, and satisfy the ongoing and changing needs of businesses.

OASIS (the Organization for the Advancement of Structured Information Standards) defines SOA in the following way: “A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations”. [10]

SOA is a means of designing software systems to provide services to either end user applications or other services through published and discoverable interfaces. There are therefore several guiding principles that define the ground rules for development, maintenance, and usage of the SOA. In [11], Thomas Erl presents the guiding principles for an efficient SOA design:

1. Standardized service contract: "Services within the same service inventory are in compliance with the same contract design standards."

2. Service loose coupling: "Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment." 3. Service abstraction: "Service contracts only contain essential information and

information about services is limited to what is published in service contracts."

4. Service reusability: "Services contain and express agnostic logic and can be positioned as reusable enterprise resources."

5. Service autonomy: "Services exercise a high level of control over their underlying runtime execution environment."

6. Service statelessness: "Services minimize resource consumption by deferring the management of state information when necessary."

7. Service discoverability: "Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted."

8. Service composability: "Services are effective composition participants, regardless of the size and complexity of the composition."

The SOAs and Web service solutions support two key roles: a service requestor (client) and service provider, which communicate via service requests. Therefore, a role reflects a type of a participant in an SOA [12]. Service requests are messages formatted according to the SOAP protocol. The SOAP request is received by a run-time service (a SOAP “listener”) that accepts the SOAP message, extracts the XML message body, transforms the XML message into a native protocol, and delegates the request to the actual business process within an enterprise. Requested operations of Web services are implemented using one or more Web service components. Web service components may be hosted within a Web services container, which provides facilities such as location, routing, service invocation, and management and also the implementation of the service interface [13]. A service container can host multiple services, even if they are not part of the same distributed process. Finally, the response that the provider sends back to the client takes again the form of a SOAP envelope carrying an XML message. There is a loosely coupled relationship between requester and provider, which is very important over the Internet where two parties may reside in different organizations or enterprises.

SSOA services are visible to the service client, but their underlying Web components are

not. The service consumer does not need to be aware of the implementation of the service, as long as it supports the required functionality, and offers the desired quality of service. The service provider is more interested in the design of components, their service exposure and management. It provides a view that offers a perspective on how to design the realization of the component that offers the services, its architectural decisions and designs. [8]

A service requester will have to directly interact with a service provider. This exposes service requesters to the potential complexity of discovering, exploring, negotiating, and reserving services between different service providers. As an alternative approach, an organization could provide this combined functionality directly to the service requester. The role of service aggregator is introduced, which combines the role of service requester and provider. The service aggregator thus performs a dual role. First, it acts as an application service provider as it offers a complete “service” solution by creating composite, higher-level services, which it provides to the service client. Service aggregators can accomplish this composition using specialized languages like BPEL and

BPML [14]. Second, it acts as a service requester as it may need to request and reserve services from other service providers. This process is shown in Fig 1.

An important question that arises and needs to be addressed is how does a service requester determine which one out of a number of potential application service providers should be selected for their service offerings? SOA technologies, such as UDDI, and security and privacy standards such as SAML and WS-Trust, introduce another role to address this issue, called a service broker [8]. They are trusted parties that force service providers to adhere to information practices that comply with privacy laws and regulations and industry best practices. In this way, service providers are guaranteed to offer services that are in conformity with local regulations, and therefore provide a more trusted relationship with customers and partners.

A service broker maintains an index of available service providers. It keeps a registry of application service providers and the quality of their services, in order to provide additional information about their services. This may include differences about the reliability, the quality of the service, service level agreements, and many others. As an example, Fig 2 shows a SOA where a service broker acts as an intermediary that is interposed between service requesters and service providers.

In order to extend the basic SOA architecture to support capabilities such as service orchestration, “intelligent” routing, provisioning, and service management, guarantee the integrity of data and security of messages, Papazoglou proposes in [8] the extended SOA (xSOA). The xSOA is an attempt to streamline, group together and logically structure the functional requirements of complex applications. The xSOA is a stratified service-based architecture. It separates functionality into three planes: service foundations at the bottom, service composition in the middle, and service management and monitoring on top. Each layer defines a set of constructs, roles, and responsibilities and leans on constructs of its predecessor layer to accomplish its mission [15]. The logical separation of functionality is based on the need to separate basic service capabilities provided by the conventional SOA from more advanced service functionality needed for composing services and the need to distinguish between the functionality for composing services from that of the management of services.

The bottom layer in the xSOA is identical to the basic SOA(see Fig. 2). It defines an interaction between software agents as an exchange of messages between service requesters (clients) and service providers. These interactions involve the publishing, finding and binding of operations, as earlier presented. The service foundations plane also consists of a service oriented middleware backbone that realizes the runtime SOA infrastructure. It connects heterogeneous components and systems and provides multiple channel access to services over various networks including the Internet. It lets application developers define basic service functionality in terms of the description, publishing, finding, and binding of services. This backbone is called the Enterprise Service Bus (ESB) [8,15]. The ESB has two major features. Firstly, it promotes loose coupling of the systems taking part in integration. Secondly, the ESB can break up the integration logic into distinct easily manageable pieces. The ESB is a standards-based message bus designed to allow the implementation, deployment, and management of SOA-based solutions. The main focus is on assembling, deploying, and managing distributed SOA. The ESB provides the distributed processing, standards-based integration, and enterprise-class backbone required by the extended enterprise [16]. It is designed to improve the operations between large applications and other components by means of standards-based adapters and interfaces. The ESB is responsible for the proper control, flow, and translations of all messages between services, using any number of possible messaging protocols. An ESB groups applications and provides integration of components to create assemblies of services that form composite business processes. All in all, it provides an implementation backbone for the SOA.

The service composition layer in the xSOA contains the necessary roles and functionality for the aggregation of multiple services into a single composite service. Resulting composite services may be used by service aggregators as basic services in further service compositions or as applications/solutions by service clients. Terms like “orchestration” and “choreography” are currently used to describe business interaction protocols and the way services interact at message level. Some of the most challenging issues for service composition that arise in the near future might be: dynamic and adaptive processes, quality of service aware service composition or business driven automated composition [15].

Managing loosely coupled applications in an SOA presents even more challenging requirements. Failure or change of a single application component can bring down numerous interdependent enterprise applications. The addition of new applications or components can overload existing components, causing unexpected degradation or failure of seemingly unrelated systems. Service management includes many interrelated functions like: service-level agreement (SLA) management; auditing, monitoring, and troubleshooting; dynamic services (or resources) provisioning; service lifecycle/state management and service scalability and extensibility. All these functions are grouped in two main categories: service operation management and service market management. Application performance depends on the combined performance of cooperating components and their interactions. To counter such situations, enterprises need to constantly monitor the health of their applications. Service monitoring involves monitoring instances of business processes, viewing process instance statistics and status, suspending, resuming or terminating selected process instances.

Future research promises to focus on the use of autonomic service capabilities in conjunction with service-level management, and can include configuring, self-adapting, self-optimizing and self-protecting management of services.

3. SPL and SOA – comparison and possible connections

Having presented Software Product Lines and Service-Oriented Architectures, it would be useful now to compare these concepts and investigate the commonalities and differences between them. To ease this comparison, we could use the following criteria: • Goal: What exactly is the concept trying to achieve?

• Defining features: What are the main characteristics of the concept?

• Technical methods and elements: Which Software Engineering methods and elements are used to develop systems in this concept?

• Organizational methods and elements: How is software development organized according to this concept and which are the key steps in the development process?

• Field of application: In what kinds of software is this concept primarily applied? • Reuse methods and entities: All three concepts focus reuse in one way or another as their goal, but the methods and entities that are reused differ substantially.

• Level of Abstraction: Which is the primary unit of analysis for reuse? Not only methods and entities, even the level of abstraction differs significantly.

• Examples: some examples for real-world applications of each concept.

The table below will provide a brief overview of this comparison, guided by the criteria mentioned above and some others.

Criteria Software Product Lines Service-Oriented Architecture

Goal

Planned exploitation of

commonalities within related systems -> reuse

Use of services of fine granularity within (enterprise) system landscapes -> flexibility

Defining features

Variability; Family of related systems based on common architecture

No common architecture, services are encapsulated and loosely coupled

Technical methods and

elements

Variation points and mechanisms, scoping, application engineering, domain engineering

Reliance on generally accepted standards, additional service registration and authentication services

Organizational methods and

elements

Two life-cycle models: first domain engineering to develop the assets to be reused, then application

engineering to derive the actual systems

Development as well as hosting of the services can be distributed, only the light-weight interface and some additional services (registry, authentication…) are provided

Reuse methods and entities

Logical reuse of all kinds of assets (components, test cases, analysis & design models), but only within the product line

Services are physically reused, potentially by anyone, and can be combined with other services into more

complex services

Level of abstraction

Primarily family of systems and secondarily systems within the family

Single services (atomic or composed of services)

Examples Nokia cell phones,

Cummins diesel engines

Telecommunications provider

Modeling Main focus is on modeling the

domain and describing the variability of a software product family.

Focuses mainly on modeling the products, i.e., service compositions.

Approach Typically decomposes artifacts into fine grained artifacts(top-down modeling)

Bottom-up compositional approach to combine artifacts into larger entities

Modeling Notations UML, feature modeling Relies mainly on XML-based notation

Establishment Characterized by different modeling initiatives

Standards in service-oriented

computing are not clearly established

A major difference that is worth mentioning between the two concepts is that typically services are dynamically computational elements whereas software product families deal with static elements. The advantage of dynamics is that they can reduce complexity. We can observe however, that product line architecture could also support a dynamic

variation mechanism by using plug-ins or some other plug-and-play architecture. For example, dynamic class loading in Java allows selection of classes when needed, based on product and user context at the time of class selection. Dynamic link libraries and reflection offer runtime selection for variation. In a mixed product line/SOA, other dynamic issues emerge. These include detection of available or unavailable services and responses to these conditions. Testing and reliability in a dynamic environment also affect validation. A tested service operates within some known bounds, but dynamic selection may pose a context outside the tested bounds. The SOA and product line connection can benefit from sharing experience results in this area [17].

As presented in the chapter concerning SOA, the most common implementations of SOA-based systems use Web services as a suitable integration technology. A Web service is a software system designed to support interoperable machine-to-machine interaction over a network using Web standards protocols [18]. The real strength of Web services is obtained when combining and orchestrating them in order to deliver value-added services. In this context, Web Service Flows (WS-flows) are a common way of implementing composite Web services in SOA. Roughly speaking, a WS-flow process defines an executable business process in which participants are Web services. In [19], we are introduced to a proposal for managing variability in WS-flows in the context of SPLs and SOAs. In particular, the paper first introduces WS-flow and BPEL. Secondly, it describes and classifies the main variability points in WS-flow. The goal is to provide the starting point for a knowledge base about variability in WS-flows that can be later used for both: 1) evaluating the different mechanisms for implementing variability in WS-flow and 2) identifying factors that affect the selection of such variability mechanisms.

Identification of variability points in WS-flows was limited to service invocation and the process workflow structure. A service invocation is defined as “an activity in which workflow invokes another service and exchanges messages with it returning control back to the workflow” [19]. The process workflow structure “determines all the aspects related to the way in which the process is executed: the execution order, the data exchanged between participants, the business rules, the errors treatment, etc.” The four main variability points identified for service invocation are: binding time, partner selection criteria, message exchange, and protocols. Binding time offers the selection of services to be invoked at design time or runtime. Partner selection criteria helps to determine which of the available services offering the same functionality will be selected for invocation. Evaluation context enables the selection criteria to be hard coded or delegated. Definition time enables the selection criteria to be modified at design time or runtime. Four different protocols may be used for service interactions over the network. The two main variability points in process workflow structure are control flow and data flow. Control flow is the workflow structure that determines the tasks to be executed and the execution order. Data

flow covers the exchange of data between services. There is still a need for a

classification of variability points in WS-flow to serve as a starting point for handling variability through services in the context of SPLs and SOA.

In [20], the authors deal with the well-known challenge of defining reusable software assets. For SOA, a service is the basic building block for system construction. Thus integrating existing services, developed in potentially different contexts by different people, means software reuse. They apply the concepts of product line engineering to the SOA paradigm, enabling the efficient construction and evolution of service centric

software systems. The approach to identify or specify reusable services of a SOA-based system contains the following steps:

- feature and feature binding analysis, which organize the system features into a product line features model that includes identified binding units (representing major functionality of a system) and relative binding times;

- the service analysis examines the feature model and feature binding information to identify molecular services (computational-oriented services that represent a predefined task) and orchestrating services (behavior-oriented services that define a sequence of tasks);

- molecular services are the basic building blocks, reused as-is by the orchestrating services. Molecular services have pre-/post-conditions, and represent domain-specific services;

- the orchestrating service represents a workflow for dependable orchestration of molecular services. Each workflow is based on a service behavior specification with pre-/post-conditions and invariants.

The key property of this approach is its support for identifying reusable services at the right level of granularity abstraction.

Another interesting example of how SPL and SOA can help each-other can be found in [21]. The authors propose a way to transfer the advantages of SPL towards SOA by building a SOA systems line suitable to customers or market segments needs in a specific application domain. They start from a deep analysis of the business processes identifying in them commonality and variability typical of the SPL paradigm. The key concepts they use are the “Business process line”(BPL) and the “Decision model”. A BPL realizes processes able to adapt themselves to different customer needs. Each process of a BPL can be then transformed into the corresponding SOA system: if the business processes are adaptable to the customer needs then the generated SOA system, it will result in its turn suitable to the specific customer requirements. The paper also presents in depth the way in which we can pass from SPL to BPL, by using process configuration and specialization. As for BPL Decision Models, they describe two kinds of relations:

1. between the business capabilities (characterizing the customer needs) and the suitable processes elements (that have to be integrated in the target business process)

2. between the customer requirements and the specific peculiarities of the processes elements previously integrated in the target process.

Trying to establish the possible SOA-SPL connections leads inevitably to two major topics: including services within product line architecture and developing a service as a product line. To include services in a product line, it’s possible to include a variation point in the architecture implemented as a component or as a service. A specific configuration could select the component or the service, depending on the specific functional or quality features needed by the application and satisfied by each alternate. In this context, services could address possible selection features like: the need for dynamic variation, rapid construction of product line systems or to exploit the availability of existing services where appropriate [17].

A second connection could arise by designing services as a product line. In this context, services themselves would be configurable according to architecture variations or specific features. For example, the SOA product line may be a mortgage service product line. A bank or other lending institution could acquire access to a specific instance, defining the

specializations it needs to the SOA product line developer. Alternatively, the entire product line capability could be acquired, and the bank or lending institution could tailor the service in multiple ways dependent on customer categories, local banking regulations, or other variations.

Conclusions

The goal of this paper was to familiarize the reader with the key concepts of Software Product Lines and Service Oriented Architectures by providing a brief overview of the two notions in the first two chapters. It also tried to provide a systematic comparison of the two concepts in chapter 3, by unveiling their points in common but also the existing differences. The comparison shows that the two concepts share a number of characteristics, but differ significantly in other characteristics. And where they differ, they sometimes actually complement each other in a very natural way. A look at the comparison of software product line and service-oriented modeling methods identified key issues in: the perceived static focus of software product lines versus the dynamic focus of service oriented computing; variability modeling in services; the creation of standards for software product lines similar to those being developed for services

However, the key issue on which research in this field is focusing now is to establish and exploit the possible connections between these two concepts, in order to be able to harness and efficiently exploit their power. Work in this area tackles features and variability issues by examining how software product line practices might support the management of variability in service-oriented applications. There are applications that address the challenges of dynamically managing services in an SOA based system.

Moreover, other research cover problems like the use of services within product line architecture, developing a service as a product line, reusable services and the meaning of a service product line.

Questions like “Can services support product lines using an SOA?” or “How can use of product line practices support services and SOAs?” still raise a lot of debate and interest in the SOA-SPL community. Although answers have been found and a lot of steps forward take, there is still a great amount of work to be done in this area.

References:

[1] Andreas Helferich, Georg Herzwurm and Stefan Jesse : Software Product Lines and Service-Oriented Architecture: A Systematic Comparison of Two Concepts

[2] P. Clements and L. Northrop : "A Framework for Software Product Line Practice"

[3] Tewfik Ziadi and Jean-Marc Jezequel : Software product lines, chapter Software Product Line Engineering with the UML: Deriving Products, Springer Berlin Heidelberg, 2006

[4] Tewfik Ziadi, Jean-Marc Jézéquel, and Frédéric Fondement : Product Line Derivation with UML [5] Gilles Perrouin : Architecturing software systems using model transformations and architectural framework, PhD Thesis, 2007

[6] K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson : Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, November 1990

[7] Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard : Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley Professional, 1992.

[8] Mike P. Papazoglou, Willem-Jan van den Heuvel : Service oriented architectures: approaches, technologies and research issues. Springer-Verlag 2007

[9] Alonso, G., Casati, F., Kuno, H., Machiraju, V.: Web Services: Concepts, Architectures and applications. Springer, Heidelberg 2004

[10] http://en.wikipedia.org/wiki/Service-oriented_architecture [11] Thomas Erl : SOA Principles of Service Design, Prentice Hall

[12] Krafzig, D., Banke, K., Slama, D.: Enterprise SOA: Service Oriented Architecture Best Practices. Prentice-Hall, Englewood Cliffs 2005

[13] Dhesiaseelan, A., Ragunathan, V.: Web Services Container Reference Architecture (WSCRA). In: Proceedings of the International Conference on Web Services, IEEE, pp. 806–805, 2004

[14] Arkin, A.: Business process modeling language (BPML). Last Call Draft Report, BPMI.Org, November 2002

[15] Michael P. Papazoglou, Paolo Traverso, Schahram Dustdar, Frank Leymann : Service-Oriented

Computing: State of the Art and Research Challenges, Computer, Vol. 40, No. 11. (2007), pp. 38-45. [16] Chappell, D.: Enterprise Service Bus. O’Reilly Media, Inc., Sebastopol (2004)

[17] Shalom Cohen, Robert Krut : Proceedings of the First Workshop on Service-Oriented

Architectures and Software Product Lines, 2007, Kyoto, Japan

[18] G. Alonso, F. Casati, H. Kuno, and V. Machiraju. Web Services: Concepts, Architectures and Applications. Springer-Verlag, 2004.

[19] Segura, Benavides, Ruiz-Cortés and Trinidad : A taxonomy of variability in web service flows [20] Jaejoon Lee, Dirk Muthig, Matthias Naab, Minseong Kim, Sooyong Park : Identifying and Specifying Reusable Services of Service Centric Systems through Product Line Technology

[21] Nicola Boffoli, Danilo Caivano, Daniela Castelluccia, Fabrizio Maria Maggi, Giuseppe Visaggio: Business Process Line to develop Service-Oriented Architectures through the Software Product Line paradigm, SOAPL 2008

[22] Alistair Cockburn : Writing Effective Use Cases. Addison-Wesley Professional, 2001.

[23] Hassan Gomaa. Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures. Addison Wesley Longman Publishing Co., 2004.

[24] Alessandro Fantechi, Stefania Gnesi, Giuseppe Lami, and E. Nesti. A methodology for the derivation and verification of use cases for product lines. In SPLC, pages 255–265, 2004

[25] Charles W. Krueger. Easing the Transition to Software Mass Customization. In PFE ’01: Revised Papers from the 4th International Workshop on Software Product-Family Engineering, pages 282–293, London, UK, 2002. Springer-Verlag.

[26] Kyo C. Kang, Sajoong Kim, Jaejoon Lee, Kijoo Kim, Euiseob Shin, and Moonhang Huh. FORM: A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures, 1998.

[27] Krzysztof Czarnecki, Simon Helsen, and Ulrich Eisenecker. Staged Configuration through Specialization and Multilevel Configuration of Feature Models. Software Process: Improvement and Practice, 10(2):143–169, 2005.

[28] T. Krebs, K. Wolter, and L. Hotz. Model-based Configuration Support for Product Derivation in Software Product Families. In Mass Customization, Concepts - Tools - Realization, GITO-Verlag, 2005

[29] Soo Dong Kim, Hyun Gi Min, Jin Sun Her, and Soo Ho Chang. DREAM: A Practical Product Line Engineering Using Model Driven Architecture. In ICITA ’05: Proceedings of the Third International Conference on Information Technology and Applications (ICITA’05) Volume 2, pages 70–75, Washington, DC, USA, 2005.

[30] Gilles Perrouin, Jacques Klein, Nicolas Guelfi and Jean-Marc Jézéquel : Reconciling Automation and Flexibility in Product Derivation, 12th International Software Product Line Conference, 2008