Authors
Zachary J. Oster, Syed Adeel Ali, Ganesh Ram Santhanam, Samik Basu, and Partha Roop
Mr. Oster, Dr. Santhanam, and Prof. Basu are affiliated with the Formal Methods Group in the Department of Computer Science at Iowa State University
Mr. Ali and Dr. Roop are affiliated with the Department of Electrical and Computer Engineering at the University of Auckland.
Abstract
To provide an effective service-oriented solution for a business problem by composing existing services, it is necessary to explore all available options for providing the required functionality while considering both the users’ preferences between various non-functional properties (NFPs) and any low-level constraints. Existing service composition frameworks often fall short of this ideal, as functional requirements, low-level behavioral constraints, and preferences between non-functional properties are often not considered in one unified framework. We propose a new service composition framework that addresses all three of these aspects by integrating existing techniques in requirements engineering, preference reasoning, and model checking. We prove that any composition produced by our framework provides the required high-level functionality, satisfies all low-level constraints, and is at least as preferred (w.r.t. NFPs) as any other possible composition that fulfills the same requirements. We also apply our framework to examples adapted from the existing service composition literature.
Publication/Downloads
- Original published version of paper: 10th Intl. Conference on Service-Oriented Computing, LNCS 7636, pp. 283-297, Springer, 2012.
Available on SpringerLink. - Self-archived version of the paper
Implementation information
We have implemented our service composition framework as a Java-based tool. Each module (NextPref, ServSelect, OrchAndVerif) is based on an existing tool developed by our group:
- NextPref takes as input a set of items and a conditional importance network (CI-net) specifying preferences over the items, then uses the NuSMV model checking engine to generate a lattice containing all subsets of a set of items. Using this lattice, NextPref can be used to obtain the most preferred subset of items being considered (usually all items) on the initial call and the next-most preferred subset of items (relative to the previous result) on all subsequent calls. This module has also been included in iPref-R, the qualitative preference reasoner currently being developed by our group.
- ServSelect is adapted from our work on automating reasoning with qualitatively-valued preferences in goal-oriented requirements engineering, published in ASE 2011 (authors: Oster, Santhanam, and Basu).
- OrchAndVerif is derived from our work on unified management of control flow and data mismatches in Web service composition, published in SOSE 2011 (authors: Ali, Roop, I. Warren, and Z.E. Bhatti).
Case studies used in our paper
Each of these goal models has been modified from the original version cited in the paper and on this page. Our intent was to be as faithful as possible to the original semantics of each goal model while adapting the models to better demonstrate the effectiveness of our framework. These case studies are primarily meant to serve as a "proof of concept" and an initial exploration of the applicability of our service composition framework.
Case study 1: HelpMeOut service
Included in paper as running example (Figure 1)Case study 2: Online Bookseller (adapted from Oster et al., ASE 2011)
In this case study, each leaf-level functional requirement (blue hexagon) is satisfied by exactly one available service. The choice of leaf-level requirements directly determines the services to be included in the composition.
The case study in our ASE 2011 paper is itself adapted from an example in Liaskos et al., RE 2010.
Goal model (functional requirements and NFPs):
CI-net (NFP preferences):
- NFPs: HappyCustomer,ReduceTransactionCosts,PaymentTraceability,UseRobustLegalDocumentation
- Preferences:
- {UseRobustLegalDocumentation} ; {} : {PaymentTraceability} > {ReduceTransactionCosts}
- {ReduceTransactionCosts} ; {HappyCustomer} : {UseRobustLegalDocumentation} > {PaymentTraceability}
- {} ; {UseRobustLegalDocumentation} : {PaymentTraceability} > {HappyCustomer,ReduceTransactionCosts}
LTSs for services in repository:
Behavioral constraints:
- !(BooksDeliveredWithReceipt) || AF(SendPrintedReceipt)
If books will be delivered with a receipt included, then a printed receipt must be sent. - A(!(BooksDelivered) U PaymentReceived)
Books must not be delivered until payment is received.
Case study 3: Multimedia Delivery (adapted from Oster et al., ICWS 2011)
This case study provides two services for almost every leaf-level functional requirement (blue hexagon). The services for each FR provide the same functionality, but contribute differently to the NFPs under consideration. The objective in this case study is to choose component services in order to get the NFP profile that is most preferred by the user(s). As you will see in the goal-model diagram, this is a complex task even for a problem of relatively small size such as this one.
The case study in our ICWS 2011 paper is itself adapted from an example in Wagner and Kellerer, ACM Multimedia 2004.
Goal model (functional requirements and NFPs):
Download a higher-quality PDF of this goal model (approx. 14K)
CI-net (NFP preferences):
- NFPs: LowCost (C), HighThroughput (T), HighReliability (R)
- Preferences:
- {}, {LowCost} : {HighReliability} > {HighThroughput}
- {HighThroughput}, {} : {LowCost} > {HighReliability}
LTSs for services in repository:
Download a higher-quality PDF of these LTS diagrams (approx. 15K)
Behavioral constraint:
- !(w32) || (AF w61 && AF w81)
If service w32 is used in the composition, then neither service w61 nor service w81 must appear in the composition.
Ongoing work
Because there is a lack of testbeds or large-scale case studies that fit well with our model of the service composition problem, we are currently working on characterizing the scalability of our framework with randomly-generated services and composition specifications. There are, of course, several important problems to address with such an approach, including:
- Generating services that correspond to the leaf-level functional requirements
- Creating behavioral constraints that are meaningful in the context of the randomly-generated functional requirements
- Producing different levels of variability (i.e., different ratios of AND vs. OR nodes) at each level of the goal model; changing an AND node to an OR node closer to the root node of the goal model produces more variability (i.e., more possible compositions) than doing so closer to the leaf-level of the model