Recommended
Recommended
More Related Content
Similar to Ph.D. Thesis presentation
Similar to Ph.D. Thesis presentation (20)
Recently uploaded
Recently uploaded (20)
Ph.D. Thesis presentation
- 1. Quality-aware Service-Oriented Software Product Lines: Feature-Driven Process Configuration and Optimization Bardia Mohabbati Simon Fraser University Ontological Research Group December 10, 2013
- 2. Outline • Background • Motivation • Research Objectives • Related work • Approach Overview • Evaluation • Conclusions • Future Work 2
- 3. Service-Oriented Architecture (SOA) Roles and Operations Service Broker Find Service Requester • • • • Publish Bind Service Provider Enhancing architectural flexibility Loose coupling among interacting software applications Reusability of services Interoperability 3
- 4. Service-Oriented Architecture Layers Party 2 Party 3 Business-to-Business (B2B) Consumer Layer … SLA (Presentation Layer) SLA Party 1 + Governance Layer Information Architecture Layer Service Layer (Simple and Composite) Integration Layer (Orchestration & Choreography) Quality of Service (QoS) Layer + Process Layer QoS Policies QoS Policies + + QoS QoS QoS QoS QoS QoS QoS QoS QoS QoS Component Layer Variation Point Optional Dependency Operational Layer (Operational Systems) Technologies DBMS Data Warehouses Package Applications Legacy Applications 4
- 5. Motivation Configurable Business Process Models Payment Service s2 s8 s3 s1 s4 s9 s5 s10 s6 s7 s11 QOS Payment Service QOS QOS Stakeholder’s Preferences Payment Service QOS QOS Service Configuration QOS Variable functional and quality Payment Service QOS 5
- 6. Complexity of Variability Management 6
- 7. Research Objectives • Variability Modeling and Management • QoS Evaluation • QoS-aware Process Configuration S2(1) S2(2) . . . S2(23) Payment Services S4(1) S4(2) . . . S4(6) Notification Services Price Security Availability Execution Time Sk(1) Sk(2) . . . Sk(l) S6(1) S6(2) S6(3) S1(1) S1(2) . . . S1(l) Si(1) Si(2) . . . Si(18) Process Model Quality Ranges (quantitative/qualitative ) 7
- 8. Related Work (Configurable) Business Process Models Process Modeling Languages • Business Process Modeling Notation (BPMN) Extensions UML ADs + BPMN Puhlmann et al., (PESOA), 2005 Razavian et al. 2008 Reinhartz-Berger et al. (ADOM), 2009, 2010 • Business Process Execution Language (BPEL) VxBPEL Koning et al. 2005 • Yet Another Workflow Language (YAWL) C-YAWL van der Aalst et al. 2005 Gottschalk et al. 2008 • Event-Driven Process Chains Language (EPC) C-EPC C-aEPC C-iEPC Rosemann et al. 2003 Dreiling et al. 2005,2006 Reijers et al. 2009 La Rosa et al. 2011 8
- 9. Related work Software Product Line Engineering (SPLE) Software product line engineering Analysis Feature Model and Variability is a development paradigm to develop and maintain families of products while taking advantage of their common aspects and predicted variabilities – [Weiss and Lai 1999] ● Mendonca Feature Modeling Benavides et Decision●Modeling al. ● Zhang et al. ● Trinidad et al. ● White et al. ● Segura ● Batory et al. ● Zhang et al. ● Gheyi et al. ● Hemakumar ● Zhang et al. Orthogonal Variabilityet al. Modeling ● Gheyi ● Benavides et al. ● Osman et al. ● Trinidad et al. ● Pohl et al. ● Osman et al. 2005 ● Fan et al. ● Metzger et al. 2007 et al. et al. Kang et al. ● Kang et al. 1990 Deursen et al. ● Atkinson ● Storm 2002 et al. et.al (FORM) 1997 ● Jacobson et al. ● Schmid et al. 2004 ● Griss et al. 1998 ● Dhungana et al. 2010 ● Kang et al. 1998 ● Czarnecki et al. 2000 ● Hein et al. 2000 Kang et al. Curp et al. ● Mannion et al. ● Czarnecki et al. ● Gurp et al. 2001 (FODA) ● Massen et al. ● Batory et al. ● Riebisch et al. ● Cao et al. ● Sun et al. 2002 ● Benavides et al. ● Gomaa et al. 2004 ● Massen et al. ● Czarnecki et al. 2005 ● Wang et al. ● Moon et al. 2005 ● Massen ● Wang et al. et.al ● Djebii et al. ● Bachmeyer et al. ● Storm ● Mendonca et al. et al. ● Yan et al. ● Salinesi et al. ● White et al. ● Abo Zaid et al. ● Osman et al. ● Fernandez et al. ● Broek et al. ● Favaro et al. ● Thum 9
- 10. Approach Overview Service-Domain Engineering D1 Product Line Requirements Analysis Service-Application Engineering Requirements Models Service Application Analysis Service-Domain Analysis D2 Variability Modeling D3 Configurable Business Process Model Stakeholder’s Requirement Analysis Service-Application Requirement Specifications Feature Selection Configured Feature Model Service Selection Configured Reference Business Process Application IntegrationDeployment Service Product Feature Model Reference Business Process Model A1 Service-Domain Design D4 Feature Resolution (Mapping Schema) Non-Functional Specifications Feature Model enriched by Supporting Quality Ranges A2 Mapping Model D5 Service Application Design & Implementation Service-Domain Service Deployment Implementation D6 Reference Business Process Model Implementation A3 Service Discovery/ Implementation Binding 10
- 11. Approach Overview Service-Domain Engineering Domain Analysis ( Variability Model) Service-Application Engineering Application Requirement Analysis Mapping Stakeholder‘s Requirements Configuration . . . S3(5) . . . . . . S1(13) S4(9) Domain Design and Implementation S2(1) S2(2) . . . S2(20) Service Configuration and Integration Configured Service 11
- 12. Variability Modeling & Representation Service-Domain Engineering Feature Model (FM) fi Identity Federation ... Gateway Interface And f Payment Payment Method Fraud Detection Credit Card Credit Card PrePayment Validation Advertising Management Shipment Email Marketing Or ... fk Mobile Marketing ... Optional Mandatory fj Include Notification Exclude < 2−3 > SMS Debit Card Payment EmailVoicemail Alternative ψk ψ4 Phone Fax MMS USSD Mobile Coupon Mobile e-Card qiR ψn Quality range Mapping Legend Mobile-based Notification Reference Process Model (BP) Notification Activity Payment Method Gateway AND XOR OR Workflow Payment Service BP Notation 12
- 13. Mapping Model Service-Domain Engineering Annotation-based approach (Czarnecki et al. 2005) Feature Model (FM) ... fi Payment Gateway Interface ψ 2,3 ψ 2,2 ψ 2,1 Credit Card Credit Card PrePayment Validation ψ 2,3,1 ψ3 Payment Method ψ 2,3,2 Advertising Management Shipment ψ2 ψi Identity Federation And f Email Marketing Fraud Detection ... fk Mobile Marketing Alternative ψk ψ4 ... Optional Mandatory fj Include ψ 2,5 Notification ψ 2,4 Or Exclude < 2−3 > SMS Debit Card Payment MMS USSD Mobile Coupon Mobile e-Card qiR ψn ψ 2,3,3 EmailVoicemail ψ 2,5,1 Phone Fax Mapping Legend Mobile-based Notification ψ 2,5,2 Quality range ψ 2,5,3 Reference Process Model (BP) ψ 2,3,2 Notification ψ 2,5 ψ 2,3,1 Activity ψ 2,5,3 ψ 2,1 ψ 2,2 Payment Service ψ 2 Payment Method ψ 2,3,3 ψ 2,4 ψ 2,3 ψ 2,5,2 ψ3 Gateway AND XOR OR Workflow ψ 2,5,1 BP Notation
- 14. Quality Variability Service-Domain Engineering Quality range Execution Time f [40ms , 270ms] Payment Identity Federation Gateway Interface Payment Method Credit Card Credit Card PrePayment Validation Advertising Management Shipment Email Marketing Fraud Detection ... fk ψk ψ4 Mobile Marketing ... fj Notification < 2−3 > SMS Debit Card Payment EmailVoicemail Phone Fax Mobile-based Notification MMS USSD Mobile Coupon Mobile e-Card S4(1) S4(2) . . . S6(1) S6(2) . . . S6(l) S4(23) [5 , 17] S1(1) S1(2) . . . S1(20) [8 , 20] [12 , 30] [15 , 51] [17 , 48] Payment Method Payment Service S2(1) S2(2) . . . S2(18) Notification [3 , 23] [8 , 27] S4(1) S4(2) . . . [10 , 54] S4(6) [10 , 45] [40ms , 270ms] 14
- 15. Structural Variability and Composition Patterns Sequential Patterns f ... CP1: Sequence CP2: Loop Parallel Patterns f ... CP4: Parallel split – Multi merge (AND-AND) CP5: Parallel split – Discriminator (AND-DISC) CP6: Parallel Split – Simple merg (AND-XOR) CP7: Exclusive – Simple merg (XOR-XOR) CP8: Multi-choice – Simple merg (OR-XOR) CP9: Multi-Choice – Synchronization (OR-OR) ... CP3: Parallel split – Synchronization (AND-AND) CP10:Multi-Choice – Multi merge (OR-OR) CP11: Multi-choice – Discriminator (OR-DISC) Or-group f ... Alternative-group group Variability Patterns Composition Patterns Van Der Aalst et al. 2003 AND OR XOR Legend DISC (m/n) Activity 15
- 16. Service-Application Engineering Service-Application Engineering Service-Domain Engineering Domain Analysis ( Variability Model) Application Requirement Analysis Stakeholder‘s Requirements Configuration Mapping . . . S3(5) . . . . . . S4(9) S1(13) Domain Design and Implementation S2(1) S2(2) . . . S2(20) Service Configuration and Integration Configured Service 16
- 17. Configuration Requirements Service-Application Engineering 1. Functional properties 2. Non-functional properties 3. User’s preferences 4. Optimization 17
- 18. Configuration Problem Service-Application Engineering Configuration Problem: How to find an optimal decision that selects the right set of features and service implementations based on constraints defined in system and user’s preference about QoS? QoS High Price Priority Execution Time Security Availability Low f f f 2 1 f f f 4 5 6 S3(1) S3(1) 1(1) S3(2) S3(2) . 1(2) .. . .. S3(6) S3(6) 1(20) S5(1) S5(2) . . . S5(12) Sj(1) Sj(2) . . . Sj (6) S4(1) j(1) S4(2) j(2) . . . S4(6) j (9) f3 S2(1) 1(1) S2(2) 1(2) . . . S2(20) 1(20) f1 S6(1) k(1) S6(2) k(2) . . . S6(7) k(l) 18
- 19. Configuration Framework QoS-Aware Optimization and Configuration 3 2 1 Feature Model User’s Preference Mapping Tailored Service Process Model Configurator Process Model Analyzer Feature Selection Reference Process Model Feature Model Analyzer Preference Prioritization Optimization Model Service Binder Service Selection Optimizer Engine Service Broker Service Repository 19
- 20. Conditional Preference Service-Application Engineering Conditional Stratified AHP: Analytical Hierarchy Process (AHP) [Satty, 1981] Degree of importance Price W1 Security W2 Throughput W3 Execution Time W4 W1 ≻ W2 ≻ W3 ≻ W4 Numerical Scale QoS α1 α2 α3 α4 α5 α6 α7 α8 α9 : Equal importance : Weak importance : Moderate importance : Moderate plus : Essential or strong importance : Strong plus : Very strong importance : Very, very strong importance : Extreme importance α α2 α α8 α3 Security. HighSecurity. High , Execution Time. Medium ≻ 7Security. Low , Execution ≻ 1 Throughput Price. Low ≻ ≻ Price. , Execution Time. Medium ≻ Throughput . Low α9 α3 Execution Time. Low ≻ Price. Low , Throughput . High ≻ Price. Low The outcomes of the procedure are the QoS requirements ranked according to user’s preference. These rankings are used as the main instrument for measuring the level of satisfaction of user’s requirements with a particular configuration. 20
- 21. QoS-Aware Optimization and Configuration Service-Application Engineering Constraint Optimization Problem (COP) We model and formulate the configuration problem as a Mixed-Integer Linear Programming (MILP) model which is characterized by four constituents: •A set of decision variables (X) •Domain of variables (D={0,1}) •A set of constraints (C) •Objective function (U) The output of the MILP problem is the maximum (or minimum) value of the objective function (U) and the values of variables at this maximum/minimum. 21
- 22. Formalizing Feature Model in MILP Model Optimization Model fp fp fp fp < 1− n > fC fC fC2 ... fCn fC1 x0 < 1 −1 > f C1 fi fj fi fj fC2 ... fCn fr < 1 −1 > < 1− 2 > f1 f3 f2 x1 x2 f4 x3 < 1 −1 > f5 x5 x4 f14 x14 f15 x15 f18 x18 f19 x19 < 1− 3 > f6 f7 x6 f12 x12 x7 f8 x8 f9 x9 f10 x10 f11 x11 f13 x13 22
- 23. Service Assignment and Dependency Constraints Optimization Model ak a1 S1(1) S1(2) . . . a2 S2(1) S2(2) S2(3) aj a1 Sj(1) Sj(2) . . . S1(20) Sj (6) …. aj Sk(l) ak … a2 Sk(1) Sk(2) . . . an a3 Sn(1) Sn(2) . . . S3(1) S3(2) . . . S3(v) Sn(m) a3 an Service Assignment Service Dependency 23
- 24. Global & Local Quality Constraints Optimization Model ak a 1 S1(1) S1(2) . . . a2 a1 Sj(1) Sj(2) . . . S1(20) Sj (6) …. aj Execution time (ms) Throughput (Invocation/Sec.) Cost (Unit per invocation) Sk(l) ak … a2 Global Constraints Sk(1) Sk(2) . . . … S2(1) S2(2) S2(3) aj Local Constraints an a3 Execution time (ms) S3(1) S3(2) . . . S3(v) … Sn(1) Sn(2) . . . Sn(m) a3 an The overall process model for a particular service application can be subjected to m global QoS constraints as follows: 24
- 25. Optimization Model QoS-Aware Optimization and Configuration We formulate the problem of finding the optimal configuration of the process model as a maximization of objective function, which meets all the constraints specified in the model 25
- 26. Evaluation & Analysis of Approach Methodology and Experimental Framework Optimizer Engine Transformations Service Generator Feature Model Generator FAMA BS Process Model Generator Reader/Writer Preference Generator QoS Generator 26
- 27. Evaluation & Analysis of Configuration Performance and Scalability Experiment No. (I) (II) (III) Service Activity No. (na) Service Candidates No. (ns) 500 600 1000 [2,4, 8,..., 128] Process Model (PM) Variability Model (FM) Percentage Ratio (RCP) Sequence (SEQ) Parallel (AND) Multiple Choice (OR) Exclusive Choice (XOR) Intel Xeon Dual CPU 2.8 GHz processor with 8 GB of memory, IBM ILOG Cplex 12.1 25% 25% 25% 25% Percentage Ratio (RVP) Mandatory Optionality Or-group Xor-group Integrity Constraints 25% 25% 25% 25% 18% QoS No. (nq) 5 27
- 28. Evaluation & Analysis of QoS aggregation QoS-range Evaluation 28
- 29. Impact Analysis of Variability and Composition Patterns on Computational Cost Variability Patterns Composition Patterns 29
- 30. Impact Analysis of Structural Variability Patterns on Computational Cost Variability models: N= 4 Variability pattern ratios: Process models: N= 100 Activity : na = 300 Service : ns = 128 1 25%, 50%, 75%, 100% 2 5 (e) Between variability patterns 1 Optional 2 3 4 5 3 4 Mandatory Or-group Xor-group Integrity Constraints 30
- 31. Impact Analysis of Composition Patterns on Computational Cost Composition pattern ratios: Process models: N= 100 Activity : na = 300 Service : ns = 128 1 (a) 25%, 50%, 75%, 100% 2 Between composition patterns (b) 1 Sequential 2 3 4 Parallel-AND Parallel-OR Parallel-OX 3 4 (c) (d) 31
- 32. Conclusions Contributions • State-of-the-art analysis − A systematic mapping study • A method for design and development of configurable process models − Feature-oriented approach (modeling and managing variability of functional and quality properties) • QoS model and evaluation method − An extensible multidimensional QoS model − Quality-range aggregation and computation • QoS-aware business process configuration framework − Preference-based configuration and optimization − Automated decision support of variants in business process models 32
- 33. Future Work • Configuration and Customization Validation • Quality Management and Probabilistic Evaluation • Design & Run-time Variability Management 33
- 34. Thank you 34
Editor's Notes
- I provided some short notes for each slides. p.s. The © symbol indicates ‘click’
- Service-Oriented Architecture (SOA) provides an architectural style to build dynamic software architectures to develop scalable and flexible distributed applications and to address challenges such as integration, reusability, modularity and interoperability it enables enterprises and companies to offer their application functionality and enhance the adaptability to changes of new requirements of users SOA is based on the concept of service as basic blocks to compose, develop , and deliver software applications. SOA follows layered architecture
- In particular business sector or domain, © individual service consumers (or stakeholder in general) very often have common requirements © in terms of functionality of service ; however, the requirements could be slightly different from one consumer to another For instance, © service consumers have different preferences toward optional service features © and they also may have diverse quality preferences about the customized service © So, nowadays service providers require to develop multiple variants of their service to serve the specific needs of different customers And need to manage knowledge of variable requirements effectively to support configuration and customization and deploy customer-tailored services; so, Configurable process models are essential for realizing such a service-oriented product line These processes as you are looking at them are generally ©
- much more complex and unmanageable and imposes heavy human effort to configure and customize for different service consumer This thesis presents a set of approaches and recommended algorithms to deal with this complexity
- We had three major objectives for this research The first objective was developing a model-driven method to manage variable functional and quality properties to support configurable process model. © The second objective was QoS-range evaluation A service functionality can be provided by similar services but different quality © , Some QoS dimensions values may vary during the service life-cycle and impact the quality of entire process model. so, the quality evaluation becomes very important for service management because that it allows to validate whether or not the final service products guarantees all the ranges of quality requirements within the envisioned scope of the product line. © And last but not least : QoS-aware Process Configuration and business process optimization © Different users have diverse range of preferences and concerns about a particular feature of the service Product and it quality. © Hence, business process require to be optimized by providing the optimal selection of appropriate services and their implementation in the course of configuration with respect to constraints; © which is known as NP-complete problem
- There are four main modeling languages to model and execute business process models There are several works extending © these conventional modeling languages with new language constructs and propose mechanisms to incorporate variability into process models to construct configurable process models, however these approaches increase the complexity of process models, and they can not support automatic variability analysis and configuration. We proposed a general approach to address these challenges.
- Variability Management has been widely studied in the field of Software Product Line Engineering (SPLE) Different variability Modeling Techniques have been proposed and developed © Feature modeling is known as one of effective approach to determine SPL variability ranging from high-level SPL variability (e.g., variation in user’s requirements) to low-level software variability (e.g., variation in software implementation and code). And there is a large body of research in feature model analysis
- Our approach is based on conventional software product line engineering extended for service-oriented software product line. We developed a method following a two-life-cycle approach that separates two core activities related to © service-domain engineering and © service-application engineering.
- The service-domain engineering focuses on service variability analysis and design of configurable process model based on requirements of domain. At design time, © a reference process model is designed as an abstract representation of all valid service composition variants for multiple service application scenarios In our approach we used © variability model as an separate model (orthogonal model) to represent and describe commonality and service variants in a reference process model. And a mapping model which connects two models © The service-application engineering focuses on deriving consumer-tailored services by analysing user’s requirements and considering preferences © , where © feature model guides the configuration of process model. So the specialization of the feature model by selecting features tailors the reference process model Which is followed by binding appropriate services
- We used © feature model as variability model to describes functional variability and express configuration space of all the service variants which are defined in terms of features and their relationships, which can be derived from a reference process model. We defined a feature represents an increment in service functionality For example, this © shows a part of feature model for configurable payment service. Feature model has © visual language and formal semantic We identified a set of possible structural variability patterns may occur in a reference process model: For instance , © Mandatory services which must be included in every member of a service product line. © Optional services may or may not be included for the final configured service product; as well as © complex group relations and © integrity constraints : for example, selection of one service may include or exclude other service for the final service product
- We followed the annotation-based approach to develop mapping model where each feature is mapped to corresponding service activity in process model using presence condition © Which are Boolean variables and specifying the presence or Exclusion of service in a reference business process model based on the selection of features in the feature model ©
- In addition to functional variability we also have quality variability. So in order to support quality variability, we extended feature model metamodel by quality characteristics A configurable process model may provide different quality-range values for individual quality characteristics ( for example execution time of service, cost and etcetera) based on available services © . So each alternative service © can contribute to the quality range values for the © entire process model We also developed a method and algorithm how such those © quality-range values are aggregated and computed. In essence, the quality-range computation depends on: structural variability which captured by a feature model; and b) composition pattern describing the control-flow of the invocation of services during the execution time which are expressed by business process model
- So we identified a set of combination of © variability pattern and © composition patterns and we developed aggregation rules for quality range computation. Which the details is given in the thesis
- We consider four major requirements for the service configuration Functional properties of services; Non-functional properties related to quality of service specification User’s preferences concerning both functional and Quality Optimization supported by the configuration approach which enables to maximize the profits Of user’s objective and based on his requirements
- This figures shows the high-level representation of the configuration framework and its core components The main inputs are abstract specification of the reference process model, feature model and decision-maker’s preference. In the first step, the user requirement and preference are determined © and preference prioritization provides a ranking procedure to compute the relative importance of quality criteria to construct the objective function. The feature model analyzer module © extracts the feature relations and transfers them to optimization model The process model analyzer © generates service dependency and assignment constraints which are specified in the process model. © The optimization model formulation is computed, and solved by optimizer engine. The output is a configured feature model which guides the configuration of the (reference) process model.
- User may have preference about quality, so Modeling and calculating the relative importance of quality requirements are needed in the course of optimization For instance, this consumer may have more concern about price and security of services which are more important to him along with © the degree of importance Or for example, for this person having low cost service is more important rather having high secured service Service consumers also very often have conditional preference, for instance, they are willing to pay more for the cost of service if the customized service has high response time or the service security is high. So to address conditional preferences and to represent and calculate the rank of user's requirements We used Conditional stratified Analytical Hierarchy Process as an extension to AHP as one of widely-used decision-analysis technique
- We model the configuration problem as a Constraint Optimization Problem (COP), which is formulated as Mixed Integer Linear Programming or in short (MILP). The modelling of a complex problem using linear-programming and formulating its description should be performed systematically and requires to represent the concept variables and the constraints in the domain So The MILP model is characterized by four constitutes set of variables representing necessary decision variables in configuration problem using decision variables to model set of logical constraints And objective function which encode user’s preference The output of MILP problem is the maximum value of the objective function and the values of variables at this maximum.
- We formalized the semantic of feature model © including features and their relations as © linear constraints which comprises part of configuration constraint set of optimization model. For this purpose, we developed an algorithm which performs © the transformation of feature model to MILP.
- The optimization model also includes service assignment and dependency constraints Service assignment constraints guarantee only one service is selected from …. And service dependency constraints describing dependencies may exits between operations of services in A process model.
- The overall We include THE
- For the evaluation of complex configuration scenarios, we required to construct models with different specifications ranging from small to large-sized models with respect to diverse characteristics. For this purpose, we developed a simulation framework to generate testbeds of large and complex feature model and process models The simulation framework is composed five main components: © 1) process model generator; © 2) service and QoS generator; © 3) feature model generator; and © 4) preference and quality constraint generator. The framework enables guided generation of random models using optimization criteria. The guided generation means that a random model is generated to meet desirable specifications ,for instance in terms of distribution of variability and composition patterns, which are defined in advance. So for this purpose we had to solved another optimization problem
- To assess performance and scalability of our configuration approach, we conducted a set of experiments. We measured the computational cost in terms of average of execution time to find possible optimal solution for each configuration problem instance. We generated reference process model instances with three different sizes and random topology: © 500, 600, and 1000 service activities as features. © We consider equal distribution of variability and composition pattern fixed To reduce the time in experimental testing, we only considered © five QoS dimensions (cost, response time, throughput, reliability and availability). We consider the distribution of real QoS datasets. To evaluate the scalability, we varied the number of service candidates © ranging from 2 to 128 per each activity of individual generated process model, and the range number of services is increased on the logarithmic bases. © It can be observed that the averages of the computational costs for the large size model © where the of number of available alternative services ranging 16 to 32 services are about one to two minutes. We examined the impact of different model sizes in terms of very large number of service alternatives. © As we can see that the computational cost is reasonable, for instance in our case it is about 7 minutes;
- We also conducted performance evaluation for quality-range aggregation For the formation of fairly large process model © (i.e., 1000 activities with a range of 64 to 128 service candidates per activity), We observed the algorithm performs quality aggregation in reasonable time, for example, the average computational cost being less than thirty seconds
- We also conducted impact analysis of variability and composition patterns on computational cost to determine whether or not the computational cost to find a possible optimal solution is significant for different process model instances varying in these patterns". So we designed a set of experiments and performed statistical tests
- To explore the effects of structural variability of the process model on computational cost for configuration of very large-size model, © we generated 100 process models with random topology whose characteristics included equal ratio of composition patterns, each include 300 activities, and 128 service alternative service per activity). Each experiment set focuses on a primary individual variability pattern, © , optionality, mandatory, group patterns as well as integrity constrains. So For each variability pattern, © we generated four random feature models for each process model with different ratio values © increased incrementally which were partitioned into four groups. And the computational cost in terms of optimization time of process model configuration to find the optimal solution for each group was measured. The tests results showed that the underlying ratios of variability patterns for mandatory, group and integrity constraints impact on computational cost; however, we found that there are no significant differences © in optimization time for the underlying ratios of optionality pattern. We also performed group analysis between variability patterns, the test result shows that there are significant differences between patterns © So, we can predict based on the statistics that the presence of any variability pattern in the process model can have effects on optimization in the course of configuration.
- We also studied the impacts of composition patterns on computational cost! And we found the presence of any composition pattern in the process model can also have effects on the computational cost
- We conducted a mapping study to provide a broad overview of existing research works that have applied or integrate service orientation and SPL principles and approaches. The results can help other researchers in the field to have a quick overview of recent related approaches and research objectives We developed a methodological foundation for the modeling and development of a configurable process model by incorporating the principles of SPLE into the SOA development life-cycle. [ …. We introduced a novel feature-oriented approach as a key design driver to identify, model, and manage functional and quality variability in the context of service-oriented product lines…] We also introduced an extensible multidimensional QoS model to capture quality properties that are inherent to an SOSPL. We developed a quality model framework for holistic architectural quality evaluation. Moreover, we provided the formalization of a computational model for architectural quality evaluation We also developed a preference-based framework for service configuration and optimization. we formulated the problem as a constraints satisfaction optimization problem and we developed a general formal mathematical model for configuration problem.
- There are several research directions and possible extensions to this body of research for future work. Here there main three potential areas: Configuration and customization validation In configuration and customization process, validation mechanisms are required to guarantee and ensures that the final configured process model being deployed in the run-time environment and can be properly executed. So , the correctness of semantic, soundness and completeness of a configured process require to be checked and guaranteed. QOS Evaluation In this work, we assumed that the quality information for service components forming a composite service in a process model is static and pre-existing, however, quality of each service may change dynamically because services are operated in heterogeneous environments, which may impact the overall quality evaluation. Another direction in which our work can be extended is to leverage probabilistic modelling approaches for the quality range evaluation under uncertainty. Design & run-time variability management Variability management should also consider other perspectives of the process models; for instance variability in data objects, resources , and facets. Service-oriented applications not only need to be configurable before deployment by creating predefined service-product variants but are also required to be adaptable at run-time, for example, dynamic service binding and replacement. so, variability transformation at run-time and management are becoming key requirements to configure service based on changing context and environment. Dynamic software product lines (DSPL) built upon SOA is becoming another active research direction which aims at investigating mechanisms to address run-time variability and dynamic reconfiguration