Service composition using product configuration ...

Service composition using product conguration technologies Case: supporting networked product development Mikko Raatikainen and Katrine Jokinen Helsinki University of Technology Software Business and Engineering Institute (SoberIT) P.O. Box 9210, 02015 TKK, Finland {Mikko.Raatikainen, Katrine.Jokinen}@tkk.fi

In service oriented computing (SOC), applications are constructed by composing existing services. However, all compositions of components are not correct or meaningful even if they are syntactically correct. For example, an application needs to follow steps in a process in a meaningful order. We study feasibility to use product conguration in the composition of an application based on services. Product conguration introduces means for specifying rules and structure upon which valid applications are composed in SOC. We describe how Kumbang product conguration concepts can be applied to SOC. The results are demonstrated using a real case example of supporting networked product development. The example is modeled and congured using tool support developed for Kumbang. The approch is feasible, but requires some changes to be convenient. Abstract.

1 Introduction Service-oriented computing (SOC) is an approach to developing applications

with services as the fundamental elements [1]. The basic concepts of SOC, i.e. the concept of a service as a self-describing, platform-agnostic, computational element and the concept of service-oriented architecture (SOA) as a loosely coupled architectural style for developing service-oriented applications, are relatively well established [1, 2]. However, developing secure and dependable applications requires additional advanced concepts [3]. Toward this end, Extended SOA (xSOA) [4, 3] identies two layers on top of the basic concepts: Service composition, which consists of the roles and functionality for combining multiple services in to a single composite service; and service management, which deals with issues such as coordination, monitoring, and quality of service of the composite services. In particular, several web service standards, often referred as WS-*, propose several solutions for these layers [5]. Despite the identied need, the advanced concepts of SOC are still at their infancies [3, 6]. Several research problems exist even in service composition [7, 6]. That is, although services are conceptually easy to compose, challenges exist,

2

e.g., in ensuring service composition quality attributes such as security or performance, automation of composition, and verication of composition correctness [8, 6]. For instance, service composition can be invalid such that service composition does not work, but in addition all service compositions despite being functionally correct are not necessarily meaningful or violate rules of the business process. The challenges exist in the concepts to express these issues, and hence, also in tools and methods for service development. In this paper, we study the feasibility to use product conguration technology in supporting service composition. Product conguration technology provides a means and tools for mass customization on the basis of existing assets [9]. We use Kumbang product conguration conceptualization for software product families [10] as a basis for this study. We present a case example of supporting networked product development to exemplify the approach. The example describes an actual business case of service composition. The results show that the concepts of product conguration and SOC have several similarities, hence the existing and available concepts, methods, and tools seem to be feasible to use to support service composition. In particular, product conguration technologies seem to have strengths in the issues in which existing service composition technologies have deciencies. Examples of such issues include service composition verication and automation. However, extensions to better support quality attributes and behavior are needed and these extensions are currently being studied. The rest of the report is structured as follows. In section 2, concepts of SOC are outlined. Section 3 gives an overview of product conguration and Kumbang. Section 4 presents a comparison of SOC and product conguration concepts. The case example is introduced in Section 5. In Section 6, service composition with Kumbang in the light of the case example is described. Section 7 identies the benets and limitations of product conguration technology in service composition. Section 8 discusses related work and in Section 9 we draw conclusions and point directions for future work.

2 Service Oriented Computing Service-oriented computing (SOC) is dened as "the computing paradigm that utilizes services as fundamental elements for developing applications" [1]. Such a service is in place and has readily available functionality; it is a platform-agnostic, self-describing, location transparent computational element that supports rapid low-cost composition of distributed applications. Platform-agnostic means that services are technology neutral: they are implemented to be used from dierent infrastructures and locations. Self-describing means that a service must provide a service description consisting of all the relevant information required to use the service. This includes how to use the service, but also, e.g., quality attributes. A service implementation is then dierentiated from service description [11]. A service should also be loosely coupled, meaning roughly that services do not depend on other services and do not require knowledge of the internal structure of other services [4].

3

Services can be simple services or composite services [1]. Composite services called are such services that consist of other services combined to a new service. Service composition is built on top of the basic capabilities of services. Currently, service composition approaches are not established and key requirements are not captured [8]. Compared to traditional software engineering, service composition, however, has two main dierences [8]: Service composition is based only on service description rather than, e.g., access to code or documentation; and location of services is not specied. Service-oriented computing dierentiates between provider and consumer roles of a service [12]. Both of these roles are logical constructs and a service can simultaneously be a provider and consumer. The main responsibility of a provider is to publish a description of the service and to provide the service for use of other services. Consumers must be able to nd the descriptions of the services they require and must be able to bind to them. Services are bound together. Binding means that two services are connected through interfaces [1]. The service-based model relies on ultra-late binding when services are congured to meet a specic set of requirements at a point in time, execute and then disengage [13]. Service-oriented architecture (SOA) is an architectural style whose goal is to achieve loose coupling among interacting services [12]. That is, SOA denes a style rather than requires special elements or protocols between services. SOA accomplishes loose coupling by requiring two constraints [12]. First, the services have only a small set of simple interfaces. Simple interfaces and extensible messages are required in order to make services easy to use and usable over time. Second, only descriptive messages constrained by an extensible schema are delivered through the interfaces. A descriptive message means that the message does not contain information of how to accomplish, e.g., some data manipulation but only the data to be manipulated. Several advanced concepts beyond these basic concepts have been proposed to SOC, especially in the context of web services. The term WS-* is often used to refer to dierent extensions, but these concepts are unestablished [5]. In addition to simple service composition level, extensions have been proposed to cover composition of more abstract concepts [14, 6]. For example, Orriens et al. [14] present a business collaboration development framework and modeling methods including language for specifying rules for it. The framework takes into account dierent levels of abstraction and dierent point of views. Service composition can then be generated automatically from such high level model.

3 Product Conguration and Kumbang Product conguration technology is an approach to provide means and tools for mass customization [9]. A product is assembled from a xed set of well-dened components, and it is assumed that these components interact with each other in a predened way [15]. Instead of explicitly enumerating all possible products, the products are associated with a conguration model that contains information

4

on possible products. This model denes a set of pre-designed components, rules on how these components can be combined into valid products, and rules for achieving the desired requirements for the customer [16]. Most of the complexity of solving the conguration problem lies then in representing conguration knowledge, since the conguration model must explicitly state all the relations and constraints among dierent components [15]. Although originally product conguration was applied to traditional, i.e. mechanical and electronic products, recently product conguration has been applied to software, and in particular, software product families [1719]. A software product family refers to a set of products that follow the same structure, called software product family architecture and are based on a set of reusable assets, such as software components [20]. Such architecture and assets contain variability meaning the ability of a system to be eciently extended, changed, customized, or congured for use in a particular context [21]. The software product family architecture and assets are developed in a special software product family development phase; the products of a software product family are derived by reusing and resolving variability following the constraints of variability and potentially developing additional software [22]. Product conguration technology expresses such variability constraints. Kumbang [10] is a domain ontology for modeling variability in software product families using product conguration technologies. Kumbang is based on a synthesis of dierent software architecture modeling methods, in particularly Koala[23], and feature modeling approaches [24] in addition to product conguration concepts. Kumbang dierentiates between a conguration model, which describes a family and contains variability, and a product description, which is a model of a product individual derived from a conguration model by resolving variability. The elements in a conguration model are referred to as types, while the elements in a product description are referred to as instances. Kumbang includes concepts for modeling variability from both a structural and feature point of view. More specically, the modeling concepts include components and features with inheritance structure and compositional structure, attributes, the interfaces of components and connections between these, and constraints. A component is a distinguishable entity. A feature is an end-user visible characteristic of a system [24]. Attributes are name-value pairs. Interface describes a set of services. A compositional structure is achieved through the concepts of a subfeature denition and part denition that state what kinds of parts can exists for a feature or component, respectively. Constraints can be specied within components and features. Implementation constraints are a special class of constraints between features and components. The semantics of Kumbang is rigorously described. A language based on the Kumbang ontology, likewise called Kumbang, has been dened. Kumbang has been provided with formal semantics by dening and implementing a translation from Kumbang to WCRL (Weight Constraint Rule Language) [25], a generalpurpose knowledge representation language with formal semantics.

5

Kumbang has currently two types of tool support: Kumbang Modeler and Kumbang Congurator. Kumbang Modeler is a tool for developing a conguration model by assisting in dening the types, structures of the types and constraints [26]. Kumbang Congurator is a tool supporting product derivation, e.g., by checking the consistency of the conguration, i.e., whether the requirements entered so far are mutually compatible; deducing the consequences of the requirements entered so far, e.g., by automatically choosing an alternative that has been constrained down to one; and reecting the consequences in the user interface. The deduction that Kumbang Congurator does is based on an eective inference engine called smodels [25].

4 Comparison of SOC and Kumbang Concepts Concepts in SOC and Kumbang have many similarities. Several of the dierences are in used terminology rather than in the conceptual foundation. In the following, we compare the concepts in terms of similarities and dierences in more depth. The comparison is summarized in Table 1.

Table 1: Comparison of SOC and Kumbang SOC

Kumbang

Services as basic elements Service composition to form larger elements Connections through service interfaces

Components as basic elements Part denitions to for lager elements

Consumer and provider roles Description and implementation Message passing communication through interfaces SOA as loosely coupled architecture style No counterpart

Connections through component interfaces Required and provided interfaces Types and instances Any kind of communication through interfaces Component based architecture Feature; Types and instances; Inheritance; Constraints; Attributes

The basic elements are services in SOC, and components and features in Kumbang. Services are specied relatively strictly (cf. Section 2) compared to components, which are dened relatively loosely. That is, components can conform to dierent kinds of elements. Services can be considered as a special class of components. Features are specied more strictly, and they do not have a direct counterpart in SOC. Typically, however, Kumbang components are associated with a piece of code while services refer to processes. This, in fact, is the main dierence between Kumbang and SOC.

6

Services can be simple or composite. A composite service consists of several other services. Similarly, Kumbang supports compositional structure of components through part denitions. In practice, service composition and part denition refer to same concept: one aggregating element combines a set of other elements and hides these other elements allowing the composite element being accessed only though the aggregating element. In addition to compositional structure, components can have inheritance structure that is not applied in SOC. SOC dierentiates between services as consumers and providers roles. Kumbang does not address dierent roles of components. Kumbang, however, dierentiates between required and provided interfaces. Hence, a Kumbang component can be considered to be in either provider or consumer role depending on the type of interface accessed. SOC dierentiates between description and implementation of a service. Description refers to a service interface and implementation refers to an actual execution instance of a service. However, Kumbang makes this distinction even clearer by dierentiating not only between instance and implementation, but also between the types and instance of the components. In both Kumbang and SOC, communication takes place through interfaces. Interfaces are based on message passing. Nevertheless, interfaces in Kumbang are typically simpler and require a function name, which, however, does not have more specic semantics, such as reference to an actual function implementation. SOC denes SOA as a special architectural style. Kumbang, in turn, does not require any specic architectural style, although it is built on the basis of component architecture. In particular, neither SOA nor Kumbang use the concept of connectors in architecture. Consequently, SOA can be considered as a special case of the architecture Kumbang supports. Kumbang contains concepts that do not have a counterpart in services: dierentiating between conguration model and conguration, constraints, attributes, and the aforementioned concept of a feature and an inheritance structure. However, the dierence between conguration model and conguration, and constraints can be used to specify rules for service composition. Attributes and inheritance structure do not seem to have direct use in SOC.

5 Service Composition Modeling with Kumbang As the comparison of concepts showed, SOC and Kumbang have several similarities. Hence, the rules and structure for service compositions can be modeled with Kumbang. Such a conguration model explicates valid service compositions. Valid service compositions can then be developed as long as they adhere to the conguration model. Service composition can then be supported by Kumbang Congurator. Service composition conguration is modeled as follows. Services are modeled as component types and composite services are modeled using part denitions. Interfaces are modeled as interface types and attached to services. The function names can be, for example, same as the interface types. An extensive description

7

of interfaces similar to services needs to be attached to Kumbang interfaces separately. Services are in consumer or provider roles depending on whether they contain required or provided interfaces. Constraints are used to explicate further rules for service compositions. The following constructs of Kumbang are not needed to be used: feature and attributes types, and functions in interfaces. Kumbang can be used to model basic connectivity of one interface of a service to another interface of another service. However, current concepts of Kumbang do not contain constructs for modeling complex behavior of composite service. For example, dierentiation between synchronous or asynchronous calls, or parallel calls cannot be expressed using basic concepts of Kumbang. Therefore, these kind of concerns need to be taken into account by the person making the conguration model. Developing a conguration model can be complex, but needs to be done only once. Thereafter, several dierent compositions can be derived. Typically, such a conguration model is produced by domain experts. On the contrary, dierent compositions can be derived practically by anyone since adherence to the conguration model ensures that only correct conguration are derived.

6 Case: Networked product development Product development is increasingly being conducted in networks of collaborating companies. This requires ecient and controlled product data exchange between the companies. Product data is often stored in product data management (PDM) systems, and the data exchange requires transferring data from PDM system of one company to PDM system of another company. This can be achieved with PDM system integration and standard processes for product data exchange in the network [27]. Service oriented architecture for supporting these processes and PDM system integration is illustrated in Figure 1. The gure describes the services needed for each member company of the product development network. The Networked PDM service is composed of three services. The Data exchange management service provides an interface for dening rules for the data exchange. It receives events from other services and decides what to do about them based on the predened rules. The Design document update service and Design change service create messages for exchanging updated documents or design change related data. The Messaging service is composed of services providing messaging with partner companies based on dierent standards. This gure includes services for RosettaNet[28] and ebXML[29] messaging. Other standard messaging services can be added depending on the standards dierent partners want to use for messaging. There are also two basic services that the Networked PDM service uses: The Data service is a wrapper for the PDM system: it provides system access through four interfaces for other services: read data, write data, get le and save le. The Notication service is used for notifying people of new documents or design change messages that require their attention. The service provides e-mail and

8

SMS notication interfaces. For example, if a Design change request is received, the notication service sends an e-mail message to the person responsible for the drawing being changed and informs that this person has 24 hours to analyze the request and to create a response. The services have WSDL interfaces that are used for exchanging messages between the services. The interfaces are marked with letters A through M in Figure 1.

Fig. 1: Service oriented architecture to support networked product data management

We will use a design document update as an example of conguring a composite of these services. The Customer (brand owner) has outsourced the mechanical design of a product to the Design supplier. The Design supplier has dened rules stating that approved versions of all design documents must be sent to the Customer. Now the Design supplier creates a new version of a drawing. When the new version is approved, the data service sends the event information to the

9

Networked PDM service. The Data exchange management service evaluates predened rules for data transfer and decides that this approved document version has to be sent to the Customer. The Design document update service requests the drawing le and metadata from the Data service and creates a standard message of them. The Data exchange management service passes this message to the Messaging service's RosettaNet interface. The RosettaNet messaging service transforms the received message into RosettaNet standard format and adds RosettaNet messaging related data to the message. This RosettaNet message is then sent to the Customer using RosettaNet Integration Framework. We modeled these services with Kumbang and derived congurations of these compositions. Hence, Kumbang Congurator automates service composition as follows. Selections for which only one possibility exists are automatically made such as all needed services are added to the conguration and interfaces between PDM data service and networked PDM service (AE) are connected. Those interfaces that cannot be automatically connected such as interface L and M inside Messaging Service has to be connected manually. However, adding the RosettaNet messaging service means that the interfaces L and M can be automatically connected. In addition, since the The RosettaNet messaging service in only optional service, Kumbang Congurator deduces that conguration has become complete i.e. all required services are selected and interfaces are connected. In fact, in this example user needed to only select the correct messaging service to achieve a complete conguration. Finally, the conguration is correct. For example, interface L cannot access Internet directly, but need to be connected through the Messaging Service.

7 Benets and Limitations in Service Composition 7.1 Benets A major benet of Kumbang is that it provides existing means and tools for composition verication. Special composition verication is, in fact, not necessary since a composition is correct if it adheres to the conguration model. That is, composition verication is done while the composition is created. In addition, automatic composition can be done since models based on Kumbang are computer understandable. Kumbang Congurator tool already exists for this purpose. Kumbang Congurator supports and automates service composition as described in Sectioni 3 and exemplied above. Both verication and automatic composition seem even to be scalable in to large service composition consisting of a great number of service and interfaces and rules how to compose service. That is, although the problem can be computationally complex, all reported cases and practical problems show feasible performance test results [30]. Verication and automatic composition also provide a means for very quick change of service composition. That is, new service composition can be developed with the conguration tool and necessary service composition specication can be generated automatically. However, current implementation does not provide means for dynamic composition.

10

Due to verication and automatic composition, deriving compositions does not require technical knowledge. Instead, the conguration model and tool support ensure that only correct compositions are created. Although we did not use features in service composition, features could be used in a higher level of abstraction than services, and service composition could be derived from features. This is similar with dening business processes and deriving corresponding service compositions from them. Features, however, do not seem directly applicable in SOC. Nevertheless, features in Kumbang provide an example and mechanisms to implement service composition generation from abstract concepts. Furthermore, Kumbang seems extensible with other concepts, such as business process modeling, better applicable in SOC.

7.2 Limitations Kumbang does not currently contain constructs for complex behavior. Instead, the person specifying the conguration model is responsible for taking behavior into account. However, this should not be an issue since she is responsible for creating the correct rules. In fact, SOC in general does not take into account where behavior is specied whereas in web service standards behavior is specied in separate orchestration or choreography specication, such as BPEL. Kumbang is currently being extended so that, even, behavior could be taken into account. Kumbang does not contain constructs for quality attributes that is an important aspect of service composition. Rather, similarly as in behavior, the person responsible for the conguration model should take quality attributes of resulting conguration into account. A major issue with respect to quality attributes is composition. Few quality attributes can be, for example, added to each other to nd out the quality attribute value of a composition. As a rst initiative toward quality attributes, Kumbang concepts have been extended with security engineering concepts in KumbangSec [31]. In order to address security, KumbangSec conceptualizes assets, principals, threats and countermeasures following ISO/IEC 9126 standard [32]: Assets refer to protected information by countermeasure, principals are actors in the system, a threat exploits vulnerability, and countermeasures are imposed in the software in order to reduce vulnerabilities. Kumbang relies on a conguration model that describes valid congurations. However, developing such a conguration model can be dicult and requires extensive domain knowledge. In addition, such a conguration model needs to be developed beforehand. However, in a typical SOC scenario services are business processes of an enterprise as in the case example, hence the conguration model seems to be feasible to be developed beforehand to explicate rules for service compositions. On the contrary, dierent service compositions can then be derived when changes to processes are needed.

8 Related Work Service composition is still relatively immature [8]. That is, the basic concepts of SOA are established but the layers on top of them, including service composition,

11

still contain several research challenges [6]. Service composition is, in fact, studied mainly in the context of web services, i.e. the implementation of SOC (cf. [8, 33]). These studies, however, focus more on notations rather than on general concepts, methods, or tools for service composition. Furthermore, there is scarcely tool support. Five requirements for web service composition approach are connectivity, QoS properties, composition correctness, scalability and automatic composition [8]. Connectivity refers to reliable connection between interfaces of services. QoS properties refer to, e.g., security and dependability. Composition correctness refers to the verication of a composition. Scalability means that the approach needs to work with a large number of services and connections. Finally, automatic composition means computer support or complete automation of composition based on general goals. According to a survey of existing service composition approaches [8], connectivity is usually supported, automatic composition and QoS properties are scarcely addressed, correctness is not addressed in current practical approaches while theoretical approached provide support, and scalability is usually not good. As described earlier, Kumbang provides support to composition correctness and automatic composition, scalability seems to be good, and QoS properties are currently being studied. While Kumbang provides tools and mechanisms for service connectivity, it lacks advanced concepts for expressing complex behavior. However, Kumbang does not require any special means to express connectivity. Instead, any existing approach such as BPEL can be used. In fact, Kumbang can be used to provide assistance in the areas in which other approaches have deciencies rather than replacing them. Compositions are currently static whereas dierent kinds of dynamic aspects are still research challenges [6]. These include autonomic composing of services, e.g., self-conguring, self-optimizing, self-healing, and self-adapting Currently, there does not seem to be either practically applicable tools or platforms to support dynamic compositions. That is, currently we need, for example, to export a conguration management script such as a BPEL description before execution. At best, service compositions can be dynamic, but service composition specications are done statically. While Kumbang concepts seem to provide a means for even dynamic inferences for correct composition hence providing a basis for required tool support for dynamic composition, this should be studied more and requires implementation changes to Kumbang Congurator. Besides simple service composition, extensions have been proposed to cover more abstract composition. Orriens et al. [14] present a business collaboration development framework and modeling methods including language for specifying rules for it. The framework takes into account dierent levels of abstraction and dierent points of view. Another approach is business-driven automated composition that is still a research challenge [6]. Business-driven automated composition roughly means that requirements are specied at the business level and service composition is done automatically and hidden from users, on the basis of these requirements. Shi et al.[34] make such an approach with their S-BMW development platform, which is capable of capturing basic business knowledge

12

in a business view and transforming it to IT knowledge with intelligent rules. However, the IT view is only a skeleton that requires further user enrichment to automatically generate deployable BPEL les. As described in Section 6, features in Kumbang are similar to these. That is, they provide a high level view to system, and a mapping to implementation units. In addition to Kumbang, there are other approaches in product conguration [19, 17, 18]. Similarly as Kumbang, these approaches seem to have deciencies in service composition, but nonetheless, seem feasible to be extended to be applicable in SOC. For example, the approach in [19] does not address explicit component interfaces and connections, which are seen as important characteristics of service. Furthermore, very few approaches address quality attributes explicitly, making them inusable for predicting non-functional properties.

9 Conclusions In this paper we studied feasibility to apply product conguration technologies in service oriented computing. In particular, we applied Kumbang as an example product conguration technology. We outlined basic concepts of service oriented computing (SOC) and Kumbang, and compared these. The concepts are relatively similar and it seems to be feasible to model services using Kumbang. In order to test the feasibility to use Kumbang for service composition modeling, we successfully modeled a case example in the domain of networked product development support for design document updates between two companies. Based on the model, we derived dierent service compositions. In general, Kumbang provides concepts and tools for service composition. That is, the problem that product conguration and Kumbang address is similar to the problems in service composition. Since there currently exists concepts, methods and tools for product conguration, such as Kumbang, SOC can benets for applying these to assist in service composition. However, product conguration is not to replace service composition concepts, but to assist. We identied benets of using Kumbang in service composition. Kumbang ensures that component composition is valid by requiring that the composition adheres to the rules and structure of a conguration model. Since Kumbang is based on well dened conceptual foundation, tool support has been feasible to develop: Kumbang Modeler can be used to specify the conguration model that explicitly and declaratively describes all possible legal service compositions; and Kumbang conguration supports and automates service composition. The tool support has been shown to be ecient also in terms of performance. Hence, Kumbang seems also to be scalable for large service compositions. There were also drawbacks of using Kumbang in service composition. Kumbang concepts, despite conceptually being similar to services, are still more component-based development oriented. Kumbang is inconvenient in modeling complex behavior; hence certain service compositions require extra eort. Kumbang lacks support for quality attributes, which are important for service composition. However, Kumbang is currently being augmented to take into account

13

other concepts than features and components, and support for quality attributes is being developed. Finally, conguration modeling requires extensive domain knowledge for the person doing it. The study resulted in several interesting directions for future work. First, Kumbang should take behavior better into account. Second, service compositions have been proposed to include abstract concepts such as business processes from which detailed composition can be made. The idea is similar with features in Kumbang; hence Kumbang seems to be relatively easily extended to take such abstract concepts into account. Third, the study strengthens the need for taking into account quality attributes in Kumbang.

Acknowledgements The authors acknowledge the nancial support of Tekes, the Finnish Funding Agency for Technology and Innovation, and the Academy of Finland.

References 1. Papazoglou, M., Georgakopoulos, D.: Guest editor introduction: Service oriented computing. ACM SIGSOFT Software Engineering Notes 46(10) (2003) 2428 2. Milanovic, N., Malek, M.: Search strategies for automatic web service composition. International Journal of Web Services Research 3(2) (2006) 3. Papazoglou, M.: Extending the service-oriented architecture. Business Integration Journal 7(1) (2005) 4. Papazoglou, M.: Service-oriented computing: concepts, characteristics and directions. In: Proceedings of the Fourth International Conference on Web Information Systems Engineering. WISE. (2003) 5. Vinoski, S.: Ws-nonexistent standards. IEEE Internet Computing 8(6) (2004) 9496 6. Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F., Krämer, B.J.: Service-oriented computing: A research roadmap. In Cubera, F., Krämer, B.J., Papazoglou, M.P., eds.: Service Oriented Computing (SOC). Number 05462 in Dagstuhl Seminar Proceedings, Internationales Begegnungs- und Forschungszentrum fuer Informatik (IBFI), Schloss Dagstuhl, Germany (2006) . 7. Phippen, A.D., Taylor, J., Allen, R.: Issues in moving from web services to service orientation. Internet Research: Electronic Networking Applications and Policy 15(5) (January 2005) 518526 8. Milanovic, N., Malek, M.: Current solutions for web service composition. IEEE Internet Computing 8(6) (November 2004) 5159 9. Faltings, B., Freuder, E.C.: Conguration (guest editor's introduction). IEEE Intelligent Systems 13(4) (1998) 3233 10. Asikainen, T., Männistö, T., Soininen, T.: Kumbang: A domain ontology for modelling variability in software product families. Advanced engineering informatics journal Accepted (2007) 11. Arsanjani, A.: Service-oriented modeling and architecture (2004) http://www128.ibm.com/developerworks/webservices/library/ws-soa-design1/.

14 12. He, H.: What is service-oriented architecture? (2003) http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html. 13. Bennett, K.H., Munro, M., Xu, J., Gold, N., Layzell, P.J., Mehandjiev, N., Budgen, D., Brereton, P.: Prototype implementations of an architectural model for servicebased exible software. In: Hawaii international conference on system sciences. (2002) 14. Orriens, B., Yang, J., Papazoglou, M.: A rule driven approach for developing adaptive service oriented business collaboration. In: SCC '06: Proceedings of the IEEE International Conference on Services Computing, Washington, DC, USA, IEEE Computer Society (2006) 182189 15. Sabin, D., Weigel, R.: Product conguration frameworksa survey. IEEE Intelligent Systems 13(4) (1998) 4249 16. Tiihonen, J., Soininen, T., Niemelä, I., Sulonen, R.: A practical tool for masscustomising congurable products. In: Proc. of International Conference on Engineering Design (ICED'03). (2003) 17. Männistö, T., Soininen, T., Sulonen, R.: Product conguration view to software product families. In: International Workshop on Software Conguration Management (SCM-10) at ICSE 2001. (2001) 18. Myllärniemi, V., Asikainen, T., Männistö, T., Soininen, T.: Kumbang conguratora conguration tool for software product families. In: IJCAI-05 Workshop on Conguration. (2005) 19. Hotz, L., Wolter, K., Krebs, T., Nijhuis, J., Deelstra, S., Sinnema, M., MacGregor, J.: Conguration in Industrial Product FamiliesThe ConIPF Methodology. IOS Press (2006) 20. Bosch, J.: Design and Use of Software Architecture. Addison-Wesley (2000) 21. Svahnberg, M., van Gurp, J., Bosch, J.: A taxonomy of variability realization techniques. Software  Practice and Experience 35 (2000) 22. Clements, P., Northrop, L.M.: Software Product Lines: Practices and Patterns. Addison-Wesley (2001) 23. van Ommering, R., van der Linden, F., Kramer, J., Magee, J.: The koala component model for consumer electronics software. Computer 33(3) (March 2000) 7885 24. Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, S.: Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21, SEI (November 1990) 25. Simons, P., Niemelä, I., Soininen, T.: Extending and implementing the stable model semantics. Articial Intelligence 138(1-2) (2002) 26. Koivu, H., Raatikainen, M., Nieminen, M., Männistö, T.: Kumbang modeler: A prototype tool for modeling variability. In: Software and Services Variability Management - Concepts, Models and Tools Workshop. (2007) 27. Borgman, J., Sulonen, R.: A case study of the impacts of preliminary design data exchange on networked product development project. In: Proceedings of International Conference on Engineering Design (ICED 03). (2003) 28. RosettaNet. http://www.rosettanet.org/ visited May 2007. 29. ebXML. http://www.ebxml.org/ visited May 2007. 30. Tiihonen, J., Soininen, T., Niemelä, I., Sulonen, R.: Empirical testing of a weight constraint rule based congurator. In: ECAI 2002 Conguration Workshop. (2002) 31. Myllärniemi, V., Raatikainen, M., Männistö, T.: Kumbangsec: An approach for modelling functional and security variability in software architectures. In: 1st International Workshop on Variability Modelling of Software-intensive Systems (VaMoS). (2007)

15 32. ISO/IEC 9126-1: Software engineeringproduct qualitypart 1: Quality model (2001) 33. Staab, S., van der Aalst, W., Benjamins, V.R., Sheth, A., Miller, J.A., Bussler, C., Maedche, A., Fensel, D., Gannon, D.: Web services: Been there, done that? IEEE Intelligent Systems 18(1) (2003) 72 34. Shi, X., Han, W., Huang, Y., Li, Y.: Service-oriented business solution development driven by process model. In: Proceedings of the 2005 The Fifth International Conference on Computer and Information Technology (CIT05). (2005)