1. 04-28-11 | 1 › Matthias Galster, University of Groningen, NL › Armin Eberlein, American University of Sharjah, UAE Identifying Potential Core Assets in Service- based Systems to Support the Transition to Service-oriented Product Lines

2. 04-28-11 | 2 Research problem ›Different instances of a SOA system can be treated as product line To handle different instances To support variability management ›But: how to make the transition from individual products to a product line?

3. 04-28-11 | 3 Research question ›What services should be included in what instance of a service-based system so that value can be maximized stability is maintained

4. Background and related work ›Product lines and service-oriented systems, e.g., Service-oriented PL architectures Feature analysis to identify services for SO systems ›Transition to PL and identifying core assets, e.g., Core assets as foundation for new PL architecture Components reused on PL Feature orientation 04-28-11 | 4

5. Proposed approach 04-28-11 | 5

6. Step 1: determine available services ›What services are still available? ›S’ v with S’ v = S \ S v ›S: set of all services ›S v : set of services already assigned to an instance v

7. Step 2: prioritize available services ›S’ v is sorted in decreasing order ›If services have the same value  order is chosen randomly

8. Step 3: select services (I) ›Trade-off between stability and accumulated added value ›stability v (i) = 1 – [i / (M + i)](1) ›AAV v (i) =  k=1..i value(s k )(2)

9. Step 3: select services (II) Definition: I = number of services in S ’ v Input: S ’ v (sorted), S v, M = sizeOf( S v ) Output: S ’’ v (resulting list of services; initialized empty) copy S v into S ’’ v k = 0 /* counter for added services is 0 */ for i = 1 to I add S ’ v (i) to S ’’ v k = k + 1 /* service is added */ calculate stability v of S ’’ v using (1) calculate AAV v of S ’’ v using (2) normalize stability v and AAV v endfor Determine i so that ( i, AAV v ( i )) and ( i, stability v ( i )) are closest to each other to represent the best compromise (trade-off)

10. Step 4: determine core asset services ›S ca = S’’ 1  S’’ 2  S’’ 3  …  S’’ V (3) ›S ca : services that could form basis for a product line

11. Case study ›“Exploratory” case study No proposition ›Identification of web services that could form the foundation for a service-based product line Web services of telecom company

12. Case study settings – services ServiceDescriptionValue s1s1 Display name and number of caller20 s2s2 Alerts incoming calls when on the phone15 s3s3 Takes messages when call is not answered17 s4s4 Forwards incoming calls to pager, cell phone, voice mail or any other phone number12 s5s5 Intercepts calls from pre-selected numbers and routes them to a standard recording5 s6s6 Provides a second phone number on existing line, with distinctive ring12 s7s7 Prompts anonymous callers to unblock phone number or say their name5 s8s8 Lets restrict selected outbound calls10 s9s9 Shows names and numbers of incoming callers when on the phone0 s 10 Prevents own name / number from being shown when calling somebody with call display0 s 11 Allows to trace last incoming call in the event of threatening, harassing, or obscene phone calls0 s 12 Lets add a third party to call4 s 13 Lets monitor a busy line to get in touch with caller when line is free4

13. Case study settings – initial SOA instances ServiceCustomer 1 (S 1 )Customer 2 (S 2 )Customer 3 (S 3 ) s1s1  s2s2  s3s3  s4s4 s5s5  s6s6 s7s7 s8s8 s9s9  s 10  s 11  s 12  s 13 

14. Case study: step 1 – identify services ›S’ 1 = S \ S 1 = S \ {s 3, s 9, s 10, s 11, s 13 } = {s 1, s 2, s 4, s 5, s 6, s 7, s 8, s 12 } “inverse” of columns from previous slide ›S’ 2 = S \ S 2 = S \ {s 2, s 3, s 5, s 9, s 10, s 11, s 12 } = {s 1, s 4, s 6, s 7, s 8, s 13 } ›S’ 3 = S \ S 3 = S \ {s 1, s 3, s 9, s 11 } = {s 2, s 4, s 5, s 6, s 7, s 8, s 10, s 12, s 13 }

15. Case study: step 2 – prioritize services ›Available services are ranked based on value Rank S’1S’1 S’2S’2 S’3S’3 1s1s1 s1s1 s2s2 2s2s2 s4s4 s4s4 3s4s4 s6s6 s6s6 4s6s6 s8s8 s8s8 5s8s8 s7s7 s5s5 6s5s5 s 13 s7s7 7s7s7 -s 12 8 -s 13 9--s 10

16. Case study: step 3 – select services (I) ›Trade-off analysis for instance 1

17. Case study: step 3 – select services (II) ›Illustration of the algorithm for instance from previous slide i (number of added services)Added serviceIncrease in AAV (normalized)Decrease in stability 1s1s1 norm (20) = 0 norm (0.84) = 1.00 2s 1, s 2 norm (20 + 15) = 0.24 norm (0.71) = 0.74 3s 1, s 2, s 4 norm (20 + 15 + 12) = 0.43 norm (0.63) = 0.54 4s 1, s 2, s 4, s 6 norm (20 + 15 + 12 + 12) = 0.62 norm (0.54) = 0.38 5s 1, s 2, s 4, s 6, s 8 norm (20 + 15 + 12 + 12 + 10) = 0.78 norm (0.50) = 0.26 6s 1, s 2, s 4, s 6, s 8, s 5 norm (20 + 15 + 12 + 12 + 10 + 5) = 0.86 norm (45) = 0.16 7s 1, s 2, s 4, s 6, s 8, s 5, s 7 norm (20 + 15 + 12 + 12 + 10 + 5 + 5) = 0.94 norm (0.42) = 0.07 8s 1, s 2, s 4, s 6, s 8, s 5, s 7, s 12 norm (20 + 15 + 12 + 12 + 10 + 5 + 5 + 4) = 1 norm (0.38) = 0.00

18. Case study: step 3 – select services (III) ›Trade-off analyses for instances 2 and 3

19. Case study: step 4 – determine services ›S’’ 1 = S 1  {s 1, s 2, s 4 } = {s 3, s 9, s 10, s 11, s 13 }  {s 1, s 2, s 4 } = {s 1, s 2, s 3, s 4, s 9, s 10, s 11, s 13 } ›S’’ 2 = S 2  {s 1, s 4, s 6 } = {s 2, s 3, s 5, s 9, s 10, s 11, s 12 }  {s 1, s 4, s 6 } = {s 1, s 2, s 3, s 4, s 5, s 6, s 9, s 10, s 11, s 12 } ›S’’ 3 = S 3  {s 2, s 4, s 6 } = {s 1, s 3, s 9, s 11 }  {s 2, s 4, s 6 }= {s 1, s 2, s 3, s 4, s 6, s 9, s 11 }

20. Case study: step 4 – determine services -S ca = S’’ 1  S’’ 2  S’’ 3 -S ca = {s 1, s 2, s 3, s 4, s 9, s 11 } see services in bold on previous slide

21. Case study: discussion of results ›Investigating how SOA instances diverge from the PL is important ›Method is light-weight ›Trade-0ff between value and stability ›Threats to validity

22. Limitations ›No effort or resource constraints ›No interface problems ›Simplified trade-off algorithm ›Interpretation of stability

23. Conclusions and future work ›SO PL help manage versions of SOA ›Trade-off analysis between value and stability to ensure homogenity between SOA systems / instances ›Future work More comprehensive evaluation Inclusion of types of variability Inclusion of more complex definitions for stability

24. 04-28-11 | 24 Thank you for your attention

25. Case study: threats to validity ›External validity More evaluations are needed ›Internal validity See limitations (simplifications made in method) ›Assumptions Price correlates with value No value for services which are free of charge Backup