Aspect-Based Variability Model for Cross-Organizational Features in Service Networks Stefan Walraven, Bert Lagaisse, Eddy Truyen & Wouter Joosen DistriNet, Dept. of Computer Science K.U.Leuven, Belgium {firstname.lastname}@cs.kuleuven.be ABSTRACT and gives service consumers the opportunity to select differ- Different clients have different needs, therefore adaptability ent variants of a service. In addition, a service provider can and variability are crucial properties for service compositions provide fine-grained customization capabilities for a service, to fit those varying requirements. This is hard to achieve without having to create new services for each customiza- in a cross-organizational context where services are imple- tion. mented and deployed by different organizations (e.g. com- panies, administrative domains, . . . ): a feature, for example A feature is a distinctive mark, quality, or characteristic of security, cannot be condensed into a single module that is a software system or systems in a domain [12]. Features applicable to all the different services. This paper proposes define both common facets of the domain as well as differ- an aspect-based variability model for representing cross-or- ences between related systems in the domain. They make ganizational features in service networks such as systems of each system in a domain different from others. Features systems or service supply chains. We argue that cross-or- are also used to define the domain in terms of the manda- ganizational features should be managed in a multi-layered tory, optional, or alternative characteristics of these related architecture, distinguishing between policy and mechanism. systems. Aspect-oriented software development (AOSD) [9] Such a multi-layered architecture is completely lacking in often has been put forward as a possible solution to enable AOSD currently. Based on this tenet, we first describe a modularization and composition of features [20, 17, 15]. technology-independent feature ontology that is well-defined for a domain or a specific service network and map it to an However, services are mostly used in a service composi- aspect-based feature implementation. tion consisting of services from different organizations. In such a cross-organizational context, a feature cannot be con- Categories and Subject Descriptors densed into a single feature module any more. The reason is C.2.4 [Computer-Communication Networks]: Distrib- that service implementations are black boxes, implemented uted Systems—Distributed applications; D.2.11 [Software and deployed by different organizations, and only the in- Engineering]: Software Architectures—Service-oriented ar- terface descriptions are available [1]. But this doesn’t ex- chitecture (SOA); D.2.13 [Software Engineering]: Reus- clude the need to share semantically compatible features able Software between those different services. A typical example of a cross-organizational crosscutting feature is security. When implementing an access control concern in an application, General Terms for instance, security actions need to be performed for every Design, Documentation, Management interaction between application components. However in a cross-organizational application, it is difficult to defend that Keywords a single module, for instance an aspect, should encapsulate AOSD, Variability modelling, Service engineering, Feature- the implementation of the internal security mechanisms of oriented the organization involved as well as the global security policy governing how security must be addressed in the overall in- 1. INTRODUCTION teraction between organizations. The latter security policy Recent trends in service engineering aim to combine the ben- belongs to a level of abstraction above the internal security efits of feature-based and service-based approaches [5, 14, 1, mechanism. 19]. This combination increases the reusability of services Therefore this paper proposes an aspect-based variability model for representing cross-organizational features in ser- vice networks such as systems of systems or service supply chains. We argue that cross-organizational features should be managed in a multi-layered architecture. Such a multi- layered architecture is completely lacking in AOSD currently. The remainder of this paper is structured as follows. In section 2, we further illustrate and motivate the need for a variability model for cross-organizational features in AOSD. such as feedback by email or by mobile text messages. Sim- Section 3 elaborates the overall approach and presents the ilarly, a client can select prioritized processing. By having application of the approach to an example. We discuss re- this feature injected, the client’s requests are prioritized over lated work in section 4 and conclude in section 5. other requests. However, the prioritizing feature requires the billing feature: prioritizing requests comes at an expense. 2. MOTIVATION & ILLUSTRATION In this section we further motivate and illustrate the impor- Figure 2 presents the stock trading service composition in- tance of an aspect-based variability model for cross-organi- cluding the prioritized processing feature. We see that the zational features in service networks. stepwise feedback feature affects both the QuotesPortalSer- vice, to retrieve customer account information, and the We present an example in the e-finance domain (see Fig. 1). QuotesOrderService, to perform the prioritizing. A more A bank offers a stock trading service to inspect, buy and trivial case is the secure communication feature: encryp- store stock quotes. To be able to provide this service, it tion and decryption operations should be performed at both cooperates with the stock market, which in turn cooperates sides of the connection. This clearly illustrates that a single with a settlement company. So the stock trading service is a feature, often consisting of a client and server functionality composition of the services provided by these three compa- part, can affect multiple services in a service composition. nies. Each participant can take up two roles in a composi- QuotesPortalService retrieve SettlementService tion: service consumer (client) and service provider (server). customer For example the bank company is a server for the bank cus- information Prioritized Acquisition Settlement Processing tomers, but consumes the QuotesOrderService of the stock market. perform settle process prioritizing up QuotesPortalService QuotesOrderService SettlementService register Order process Order prepare Transaction Registering Processing Preparation Bank Customers QuotesOrderServer Bank Company Stock Quotes Market Settlement Company Figure 2: Services affected by the stepwise feedback feature. Order Order Transaction Registering Processing Preparation However, each company in a cross-organizational service network has its own IT administration and trust domain, Figure 1: Illustration of the stock trading service and will not allow external parties to add or update fea- composition. ture implementations. The services provided by the different partners are black boxes, loosely-coupled and independently maintained by the company’s own administrators. This During a typical session, a client inspects stock quote data, black-box scenario hinders the feature modularization and inspects the stored stock quotes in his custody account and composition in a cross-organizational context [1]. There- potentially buys or sells some stocks. Clients can issue a fore a feature cannot be condensed into a single module stock order by using the web service portal facility of their any more. Cross-organizational features need to be split up bank. The bank service acquires the client’s order and for- in client-side and server-side aspects, independently imple- wards it to the stock market. Processing the order request mented with possibly different AO-technologies. However, a in the stock market consists of three sequential functional uniform high-level representation of those features is crucial steps. Firstly, the client order is registered in the stock mar- to be able to share them in a particular application domain ket by the OrderRegistration unit and then forwarded to or service network. the OrderProcessing unit. Secondly, at regular time in- tervals, the OrderProcessing unit searches for matches be- tween buying and selling offers. If two orders match, they 3. APPROACH are forwarded to the TransactionPreparation unit, which In this section we present our approach to achieve a multi- delegates the actual trade of goods to the settlement com- layered architecture for the uniform representation of cross- pany. organizational features in AOSD. A multi-layered architec- ture, distinguishing between policy and mechanism, is a Since different clients have different needs, this service com- core tenet of the body of research on cross-organizational position can be customized with respect to agreed features coordination architectures. We shortly review the state- such as prioritized processing, billing, stepwise feedback, log- of-the-art in this field. Subsequently, based on this tenet, ging, non-repudiation, transaction support, secure commu- we propose that aspect-based variability is first described nication, authentication, authorization and secure server- at the level of a technology-independent feature ontology side storage. Choosing different features results in differ- that is well-defined for a domain or a specific service net- ents variants. If selected, the stepwise feedback feature, for work. Each organization implements this feature ontology instance, informs the client about the progress made in pro- independently using an AOP technology of its choice. The cessing its requests, at the level of the individual services as mapping between the independent feature ontology and the well as the different sequential units within a service. Several aspect-based implementation is then specified as part of the alternatives are available for the stepwise feedback feature, second layer of the model. Finally, we show how this feature ontology is used for cross-organizational service customiza- 3.2 High-level Feature Ontology tion. The conceptual model in our approach for specifying cross- organizational features consists of a feature ontology. Sim- 3.1 Cross-organizational Coordination Archi- ilarly to the conceptual model of the cross-organizational coordination architectures, this feature ontology should be tectures high-level and independent from the aspect-based implemen- Our approach is inspired by the design principles of cross- tation to enable organizations in service networks to imple- organizational design. In the field of cross-organizational ment cross-organizational features using an AOP technol- coordination architectures, a layered system architecture is ogy of their choice (see Fig. 3). In order to be successful, a core principle of the reference model [31]. This reference the feature ontology must have a clear scope on which par- model distinguishes between (i) the type of agreements that ticular application domain or area it applies, for example, are established, (ii) the language for describing the agree- a specific market such as financial services or an individual ments, and (iii) the middleware for establishing and execut- (long-running) business relationship between multiple orga- ing the agreements. nizations. The language for describing how the interactions between The specification of such a common feature ontology is di- two or more independent services are to be done is further vided into a base level and one or more application-specific refined into a conceptual and a computational model [31]: levels. The base ontology is a framework and vocabulary for specifying application-specific ontologies. An application- 1. A conceptual model provides the modeling concepts specific ontology contains a catalog of features that can be to describe the regulations at a sufficient high-level of used within a certain cross-organizational service network. abstraction that is independent from the organizations Application-specific ontologies are hierarchically structured: internal processes and data. the application-specific ontology of a specific service compo- sition imports and extends the ontology of the application 2. A computational model offers behavioral concepts that domain. are mappable to implementable actions in the under- lying software system that can be enforced upon con- A feature ontology can be seen as a high-level, technology- tracted services. independent agreement between the parties involved (typi- cally a service consumer and service provider). This agree- The conceptual model of the language should be as inde- ment prescribes the intended behavior of the feature and pendent as possible from the computational model to enable clearly sets out the roles that different parties involved have that different organizations can implement the same agree- to play, as depicted in Fig. 3. These roles are described by a ment differently depending on their choice of implementa- name (e.g. Service Consumer) and a set of responsibilities. tion platform, while adhering to the terms of the agreement. These responsibilities specify constraints on behavior (the specification of an algorithm to be used) and interfaces (mes- When multiple independent organizations interact with each sage types and operations that are required or provided). other, they have to integrate their business processes in order Further, composition rules can be specified that prescribe to be able to operate, gain added-value and survive in a mar- which features depend on other features and which features ket. To enable this, a certain agreement must be complied can’t be executed during the same request due to feature by all participating organizations in the business relation- interference. ship. We think that a common feature ontology can be part Listing 1: Example of high-level features. of this agreement. Therefore, it is plausible to assume that feature P r i o r i t i z e d P r o c e s s i n g { services in a service network can share a common feature dependsOn : B i l l i n g ; ontology. r o l e ServiceConsumer { Conceptual Model r e s p o n s i b i l i t y retrieveCustomerAccount { dependsOn conflictsWith p r o v i d e s : CustomerAccount ; } } role S e r v i c e P r o v i d e r { Feature i responsibility performPrioritizing { r e q u i r e s : CustomerAccount ; Service Service p r o v i d e s : AccountableItem ; Consumer Provider } Role Role } Mapping to aspect-based implementation } Computational Model Aspect X.i Aspect Y.i For example, the PrioritizedProcessing feature from Fig. 2 needs two roles: a service consumer who retrieves customer account information, and a service provider, responsible for performing the prioritizing. The service provider role re- Figure 3: Aspect-based variability model. quires a CustomerAccount attribute, which will be provided by the service consumer role. After the prioritizing, the ser- Conceptual Model vice provider role will provide a AccountableItem attribute dependsOn conflictsWith - interface WSDL - message types that will be used by the Billing feature. The feature de- Service binding - ports scription is presented in Listing 1. It also defines a com- features Feature i position rule that prescribes that PrioritizedProcessing Service Service requires the Billing feature. Service Consumer Provider Service Role Role Consumer X Provider Y Mapping to 3.3 Mapping to Aspect-based Implementation aspect-based implementation Computational Model The mapping between the high-level feature ontology and Aspect X.i Aspect Y.i the aspect-based implementations is specified on the level of the service platform, hiding the implementation details for external parties. The use of AOSD [9] enables a clean separation of concerns, in which the core functionality of a Figure 4: Using the Variability Model for Web Ser- service is separated from any feature behavior. Therefore vices. they are implemented separately from each other as com- posite entities containing a set of aspect-components, pro- WSDL also defines services as collections of network end- viding the behavior of the features (so called advice). This points, or ports. A port is nothing more than the address or advising behavior can be dynamically composed on all the connection point to the web service (typically a http URL). components of a service – at client-side and at server-side. To be able to use our feature ontology, the WSDL should be extended with the set of available features (see Fig. 4). By capturing the semantics of the features in a high-level feature ontology, the different features can be implemented The variability model is accessible to the clients of the ser- independently by each of the service providers using their vice application and allows them to select a desired set of favorite service platform and AO-composition technology. features. Configuration of features across the service net- Hence, the different services in the network may have their work happens through instantiation of service bindings. A own optimized aspect-based implementations of the different service binding is a declarative specification, specifying the features, and the most appropriate feature implementation web service location, the selected port and which features in each service may depend on environmental circumstances. are desired (see Listing 3). This decentralized feature management allows a variety of service platforms using different AO-composition technolo- Listing 3: Example of a service binding. gies to be interconnected. In addition, the implementation of servicebinding { the different features and the software composition strategy URI : h t t p : //www . s t o c k t r a d i n g e x a m p l e . be ; are open for adaptation by each of the local administrators. port : StockTradingServiceSoapEndpoint ; However, the feature implementations have to satisfy certain features : PrioritizedProcessing , Billing ; constraints, enforced by the feature ontology. } Each feature implementation mapping within a specific orga- nization is described by means of a declarative specification 4. RELATED WORK that specifies: (i) the feature and role that is implemented, We first discuss the work in the context of cross-organiza- (ii) the aspect-component that implements the particular tional service provisioning. Next we discuss the related re- role, and (iii) optionally an AO-composition for weaving the search in the domain of service composition. aspect-component into the internal processes and data of the organization (see Listing 2). Cross-organizational coordination architectures. A multi- layered architecture, distinguishing between policy and mech- Listing 2: Example of a feature implementation anism, is a core principle of the body of research on cross-or- mapping. ganizational coordination architectures. Firstly, agreements must be represented digitally by means of a language that featureImplementationMapping PPImpl { offers the necessary concepts for describing and enforcing implements : P r i o r i t i z e d P r o c e s s i n g ; agreements. Second, coordination middleware must be de- r o l e : ServiceConsumer ; veloped in order to establish agreements dynamically, and ao−component : PPAOComponent ; to enforce the agreements or detect violations against it. ao−c o m p o s i t i o n { ... The current state-of-the-art on cross-organizational coordi- } nation architectures in the general area of SOA consists } of policy-based and contract-based frameworks. Contract frameworks (such as BCL [21], [11], [26], GlueQoS [32], T- BPEL [29] and SLAng [28, 27]) focus mostly on negotia- 3.4 Using the Feature Ontology for Cross-Or- tion, enactment and monitoring, while policy-based archi- ganizational Service Customization tectures (e.g. Ponder [7] and LGI [22]) focus exclusively The Web Services Description Language (WSDL) is an XML- on enforcement. These coordination architectures estab- based language that provides a model for describing web lish agreements dynamically between two or more organi- services. The web service is defined by an interface, describ- zations, but fail to support the coordination of system-wide ing the operations that can be performed and the message customizations of service compositions. Our approach deals types that are required/provided by these operations. The with this by providing an aspect-based variability model for cross-organizational features, managed in a multi-layered ar- WS-standards such as WS-Coordination [24], WS-Policy [2] chitecture. and WS-Security [23], but we intend to offer a complemen- tary approach for consistent customization of features in or- Service composition. Previous research focussed already on chestrations. For example, in our approach we use a per- automated composition of web services into composite web request tagging solution to achieve coordination between the services [10, 6, 13]. For this purpose, matchmaking algo- client and the different web services. In case more complex rithms search for matching web services based on their in- coordination schemes are needed (e.g. if coordination mes- put/output, the interaction protocol and functional behav- sages don’t follow the message flow), our approach can be ior, using a forward or backward chaining algorithm and a combined with WS-Coordination. This coordination speci- discovery service. The matchmaking process can be either fication was originally defined for coordinating transaction centralized (i.e. planning a complete composition at once), or protocols, but is extensible for all kinds of coordination pro- decentralized, allowing each web service in the composition tocols in a web service environment. to decide individually which web services to select in pro- viding the required services for processing the request. This 5. CONCLUSION AND FUTURE WORK functional matchmaking process is originally based upon In this paper, we proposed an aspect-based variability model WSDL information in the UDDI directory to select the ap- for representing cross-organizational features in service net- propriate services. In more recent work, the matchmaking works. Our approach consists of a multi-layered architec- process is based upon QoS properties of the different web ture, mapping a technology-independent feature ontology services [32, 33, 34, 16, 4, 8]. Here, non-functional prop- onto an aspect-based implementation. erties such as security, reliability and performance are used by the matchmaking algorithm to select the most appropri- The approach supports maintaining the compatibility of fea- ate service. For example, in [33], Zheng et al. propose a ture implementations across a service network of indepen- quality-driven approach to select component services dur- dent organizations. The common feature ontology can also ing the execution of a composite service. For this purpose, be leveraged to support client-specific customization of cross- they define a web service quality model based upon five non- organizational features across such service networks. As only functional properties and a global quality-driven selection limited tests have been performed, further validation and algorithm formulating these properties as a linear optimiza- evaluation of our approach are necessary. tion problem. In this approach, every service is assumed to have one particular QoS profile, described in the quality model. [18] presents an heuristic algorithm for composing 6. REFERENCES services to achieve global QoS requirements in dynamic ser- [1] Apel, S., Kaestner, C., and Lengauer, C. vice environments. Research challenges in the tension between features and services. In SDSOA ’08: Proceedings of the 2nd A common denominator in this research domain is the us- international workshop on Systems development in age of ontologies [3] to store semantic information about SOA environments (New York, NY, USA, 2008), web services to automate the matchmaking of services in ACM, pp. 53–58. a web service composition based upon functional and non- [2] BEA Systems, IBM, Microsoft Corporation, functional properties [25, 16, 30]. In our approach, we use SAP AG, Sonic Software, and VeriSign. Web ontologies and semantic information to describe features as Services Policy Framework (WS-Policy). http: first class entities rather than describing web services with //download.boulder.ibm.com/ibmdl/pub/software/ their properties. In this way, the information about the fea- dw/specs/ws-polfram/ws-policy-2006-03-01.pdf, tures is web service independent. Thanks to this ontology, March 2006. automated reasoning can be done about the customization [3] Berners-Lee, T., Hendler, J., and Lassila, O. of the orchestration on a per-request basis, without consid- The Semantic Web. Scientific American 284, 5 (2001), ering the actual web service composition. 34–43. [4] Bilgin, A. S. A DAML-based repository for The GlueQoS middleware-based approach of Wohlstadter qos-aware semantic web service selection. In IEEE et al. [32] manages dynamically changing QoS requirements International Conference on Web Services (ICWS of web services by delaying QoS commitments of the ser- 2004) (2004), IEEE Computer Society, pp. 368–375. vices. Each service describes its QoS preferences, and a [5] Cohen, S., and Krut, R., Eds. Proceedings of the middleware-based resolution mechanism searches for a sat- First Workshop on Service-Oriented Architectures and isfiable set of QoS features to inter-operate for services that Software Product Lines (May 2008), Carnegie Mellon encounter each other for the first time. Similar to our ap- University - Software Engineering Institute. proach, GlueQoS uses a fixed ontology for classifying fea- [6] Constantinescu, I., Faltings, B., and Binder, W. tures and describing their interactions and possible interfer- Large scale, type-compatible service composition. In ence. However, their selection of features is fully decentral- IEEE International Conference on Web Services ized and on a per-collaboration basis (optimally suited for a (ICWS 2004) (2004), pp. 506–513. highly dynamic web service composition), but lacking sup- [7] Damianou, N., Dulay, N., Lupu, E., and Sloman, port for client-specific customization and consistent process- M. The ponder policy specification language. In ing throughout cross-organizational service compositions, as Policies for Distributed Systems and Networks (2001), our approach does. Springer, pp. 18–38. [8] Felfernig, A., Friedrich, G., Jannach, D., and Finally, our approach does not pretend to replace existing Zanker, M. Semantic configuration web services in the cawicoms project. In ISWC ’02: First Kulkarni, S., and Cole, J. Inter-Organisational International Semantic Web Conference on The Collaborations Supported by E-Contracts. In Building Semantic Web (2002), Springer, pp. 192–205. the E-Service Society (2004), Springer, pp. 413–429. [9] Filman, R. E., Elrad, T., Clarke, S., and Akşit, [22] Minsky, N. H., and Ungureanu, V. Law-governed M. Aspect-Oriented Software Development. interaction: a coordination and control mechanism for Addison-Wesley, Boston, 2004. heterogeneous distributed systems. ACM Trans. [10] Foster, H., Uchitel, S., Magee, J., and Kramer, Softw. Eng. Methodol. 9, 3 (2000), 273–305. J. Compatibility Verification for Web Service [23] OASIS Web Services Security (WSS) TC. Web Choreography. In IEEE International Conference on Services Security (WS-Security). Web Services (ICWS 2004) (2004), IEEE, http://www.oasis-open.org/committees/tc_home. pp. 738–741. php?wg_abbrev=wss, February 2006. [11] Hoffner, Y., Field, S., Grefen, P., and Ludwig, [24] OASIS Web Services Transaction (WS-TX) TC. H. Contract-driven creation and operation of virtual Web Services Coordination (WS-Coordination). enterprises. Computer Networks 37, 2 (2001), 111–136. http://docs.oasis-open.org/ws-tx/ Electronic Business Systems. wstx-wscoor-1.2-spec-os.pdf, February 2009. [12] Kang, K. C., Cohen, S. G., Hess, J. A., Novak, [25] Paolucci, M., Kawamura, T., Payne, T. R., and W. E., and Peterson, A. S. Feature-oriented Sycara, K. Semantic matching of web services domain analysis (FODA) feasibility study. Tech. capabilities. In ISWC ’02: First International Rep. 21, Software Engineering Institute, Carnegie Semantic Web Conference on The Semantic Web Mellon University, Pittsburgh, PA, 1990. (2002), Springer, pp. 333–347. [13] Lassila, O., and Dixit, S. Interleaving discovery and [26] Shrivastava, S. Tapas final report. Tech. rep., composition for simple workflows. In Semantic Web Technical Report Project deliverable D20, 2005. Services, 2004 AAAI Spring Symposium Series (2004). [27] Skene, J., and Emmerich, W. Engineering Runtime [14] Lee, J., Muthig, D., and Naab, M. An Approach Requirements-Monitoring Systems Using MDA for Developing Service Oriented Product Lines. In Technologies. In Trustworthy Global Computing SPLC ’08: 12th International Software Product Line (TGC) (2005), vol. 3705, Springer, pp. 319–333. Conference (Sept. 2008), pp. 275–284. [28] Skene, J., Lamanna, D. D., and Emmerich, W. [15] Lee, K., Kang, K. C., Kim, M., and Park, S. Precise Service Level Agreements. In ICSE ’04: Combining feature-oriented analysis and Proceedings of the 26th International Conference on aspect-oriented programming for product line asset Software Engineering (Washington, DC, USA, 2004), development. In Software Product Line Conference, IEEE Computer Society, pp. 179–188. 2006 10th International (0-0 2006), pp. 10–112. [29] Tai, S., Mikalsen, T., Wohlstadter, E., Desai, [16] Lee, Y., Patel, C., Chun, S. A., and Geller, J. N., and Rouvellou, I. Transaction policies for Towards intelligent Web services for automating service-oriented computing. Data & Knowledge medical service composition. In IEEE International Engineering 51, 1 (2004), 59–79. Conference on Web Services (ICWS 2004) (2004), [30] Trastour, D., Bartolini, C., and pp. 384–394. Gonzalez-castillo, J. A Semantic Web Approach [17] Loughran, N., and Rashid, A. Framed Aspects: to Service Description for Matchmaking of Services. In Supporting Variability and Configurability for AOP. In Proceedings of the International Semantic Web In Software Reuse: Methods, Techniques and Tools Working Symposium (SWWS) (2001). (2004), Springer, pp. 127–140. [31] Truyen, E., and Joosen, W. A reference model for [18] Mabrouk, N. B., Beauche, S., Kuznetsova, E., cross-organizational coordination architectures. In Georgantas, N., and Issarny, V. QoS-aware International Conference on Enterprise Distributed service composition in dynamic service oriented Object Computing Workshops (2008), IEEE, environments. In Middleware ’09: Proceedings of the pp. 252–263. 10th ACM/IFIP/USENIX International Conference [32] Wohlstadter, E., Tai, S., Mikalsen, T., on Middleware (New York, NY, USA, 2009), Rouvellou, I., and Devanbu, P. GlueQoS: Springer-Verlag New York, Inc., pp. 123–142. Middleware to Sweeten Quality-of-Service Policy [19] Medeiros, F. M., de Almeida, E. S., and Interactions. In ICSE ’04: Proceedings of the 26th de Lemos Meira, S. R. Towards an Approach for International Conference on Software Engineering Service-Oriented Product Line Architectures. In (Washington, DC, USA, 2004), IEEE Computer Proceedings of the Third Workshop on Society, pp. 189–199. Service-Oriented Architectures and Software Product [33] Zeng, L., Benatallah, B., Dumas, M., Lines (SOAPL) (2009), S. Cohen and R. Krut, Eds., Kalagnanam, J., and Sheng, Q. Z. Quality driven pp. 151–164. web services composition. In WWW ’03: Proceedings [20] Mezini, M., and Ostermann, K. Variability of the 12th international conference on World Wide management with feature-oriented programming and Web (New York, NY, USA, 2003), ACM, pp. 411–421. aspects. In SIGSOFT ’04/FSE-12: Proceedings of the [34] Zeng, L., Benatallah, B., Ngu, A. H. H., Dumas, 12th ACM SIGSOFT twelfth international symposium M., Kalagnanam, J., and Chang, H. QoS-aware on Foundations of software engineering (New York, middleware for Web services composition. IEEE NY, USA, 2004), ACM, pp. 127–136. Transactions on Software Engineering 30 (2004), [21] Milosevic, Z., Linington, P. F., Gibson, S., 311–327.