=Paper=
{{Paper
|id=None
|storemode=property
|title=Aspect-Based Variability Model for Cross-Organizational Features in Service Networks.
|pdfUrl=https://ceur-ws.org/Vol-564/compositionvariability2010_submission_9.pdf
|volume=Vol-564
}}
==Aspect-Based Variability Model for Cross-Organizational Features in Service Networks.==
https://ceur-ws.org/Vol-564/compositionvariability2010_submission_9.pdf
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.