Transcript Document

04-28-11 | 1
Identifying Potential Core Assets in Servicebased Systems to Support the Transition to
Service-oriented Product Lines
› Matthias Galster, University of Groningen, NL
› Armin Eberlein, American University of Sharjah, UAE
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?
04-28-11 | 3
Research question
S1
s5
s7
s11
s15
s18
s25
S1
S2
s1
s1
s1
s11
s5
s11
s13
s7
s13
s15
s11
s15
s17
Added services
s13
Original services
s1
S2
s13
s11
s13
s17
s18
s18
s15
s18
s19
s18
s19
Original services +
added services
s1
s25
Identification of potential core
asset services
Core asset services
› What services should be included in what instance of
a service-based system so that
• value can be maximized
• stability is maintained
04-28-11 | 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 | 5
Proposed approach
Step 1: Determine available services, i.e., services
which are not yet assigned to a service composition
Step 2: Prioritize available services
Step 3: Select services to be added to SOA instances
Step 4: Determine potential core asset services
Step 1: determine available services
› What services are still available?
› S’v with S’v = S \ Sv
› S: set of all services
› Sv : set of services already assigned to an instance v
Step 2: prioritize available services
› S’v is sorted in decreasing order
› If services have the same value  order is chosen
randomly
Step 3: select services (I)
› Trade-off between stability and accumulated added
value
› stabilityv(i) = 1 – [i / (M + i)]
(1)
› AAVv(i) = k=1..i value(sk)
(2)
Step 3: select services (II)
Definition: I = number of services in S’v
Input: S’v(sorted), Sv, M = sizeOf(Sv)
Output: S’’v(resulting list of services; initialized empty)
copy Sv 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 stabilityv of S’’v using (1)
calculate AAVv of S’’v using (2)
normalize stabilityv and AAVv
endfor
Determine i so that (i, AAVv(i)) and (i, stabilityv(i)) are closest to each
other to represent the best compromise (trade-off)
Step 4: determine core asset services
› Sca = S’’1  S’’2  S’’3  …  S’’V
(3)
› Sca: services that could form basis for a product line
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
Case study settings – services
Service
Description
Value
s1
Display name and number of caller
20
s2
Alerts incoming calls when on the phone
15
s3
Takes messages when call is not answered
17
s4
Forwards incoming calls to pager, cell phone, voice mail or any other phone number
12
s5
Intercepts calls from pre-selected numbers and routes them to a standard recording
5
s6
Provides a second phone number on existing line, with distinctive ring
12
s7
Prompts anonymous callers to unblock phone number or say their name
5
s8
Lets restrict selected outbound calls
10
s9
Shows names and numbers of incoming callers when on the phone
0
s10
Prevents own name / number from being shown when calling somebody with call display
0
s11
Allows to trace last incoming call in the event of threatening, harassing, or obscene phone calls
0
s12
Lets add a third party to call
4
s13
Lets monitor a busy line to get in touch with caller when line is free
4
Case study settings – initial SOA instances
Service
Customer 1 (S1)
Customer 2 (S2)

s1

s2
s3
Customer 3 (S3)



s4

s5
s6
s7
s8
s9


s10


s11



s12
s13



Case study: step 1 – identify services
› S’1 = S \ S1 = S \ {s3, s9, s10, s11, s13} = {s1, s2, s4, s5, s6,
s7, s8, s12}
“inverse” of columns from previous slide
› S’2 = S \ S2 = S \ {s2, s3, s5, s9, s10, s11, s12} = {s1, s4, s6,
s7, s8, s13}
› S’3 = S \ S3 = S \ {s1, s3, s9, s11} = {s2, s4, s5, s6, s7, s8, s10,
s12, s13}
Case study: step 2 – prioritize services
› Available services are ranked based on value
Rank
S’1
S’2
S’3
1
s1
s1
s2
2
s2
s4
s4
3
s4
s6
s6
4
s6
s8
s8
5
s8
s7
s5
6
s5
s13
s7
7
s7
-
s12
8
s12
-
s13
9
-
-
s10
Case study: step 3 – select services (I)
Normalized AAV [a.u.]
1
1
0,9
0,9
0,8
0,8
0,7
0,7
0,6
0,6
0,5
0,5
0,4
0,4
0,3
0,3
0,2
0,2
0,1
0,1
0
0
1
2
3
4
5
6
7
Normalized stability [a.u.]
› Trade-off analysis for instance 1
8
Number of added services
AAV (normalized)
stability (normalized)
Case study: step 3 – select services (II)
› Illustration of the algorithm for instance from
previous slide
i (number of added services)
Added service
Increase in AAV (normalized)
Decrease in stability
1
s1
norm(20) = 0
norm(0.84) = 1.00
2
s1 , s2
norm(20 + 15) = 0.24
norm(0.71) = 0.74
3
s1 , s2 , s4
norm(20 + 15 + 12) = 0.43
norm(0.63) = 0.54
4
s1 , s2 , s4 , s6
norm(20 + 15 + 12 + 12) = 0.62
norm(0.54) = 0.38
5
s1 , s2 , s4 , s6 , s8
norm(20 + 15 + 12 + 12 + 10) = 0.78
norm(0.50) = 0.26
6
s1 , s2 , s4 , s6 , s8 , s5
norm(20 + 15 + 12 + 12 + 10 + 5) = 0.86
norm(45) = 0.16
7
s1 , s2 , s4 , s6 , s8 , s5 , s7
norm(20 + 15 + 12 + 12 + 10 + 5 + 5) = 0.94
norm(0.42) = 0.07
8
s1, s2, s4, s6, s8, s5, s7, s12
norm(20 + 15 + 12 + 12 + 10 + 5 + 5 + 4) = 1
norm(0.38) = 0.00
Case study: step 3 – select services (III)
0,9
0,9
0,8
0,8
0,7
0,7
0,6
0,6
0,5
0,5
0,4
0,4
0,3
0,3
0,2
0,2
0,1
0,1
0
0
1
2
3
4
5
6
Number of added services
AAV (normalized)
stability (normalized)
1
1
0,9
0,9
0,8
0,8
0,7
0,7
0,6
0,6
0,5
0,5
0,4
0,4
0,3
0,3
0,2
0,2
0,1
0,1
0
0
1
2
3
4
5
6
7
8
Normalized stability [a.u.]
1
Normalized AAV [a.u.]
Normalized AAV [a.u.]
1
Normalized stability [a.u.]
› Trade-off analyses for instances 2 and 3
9
Number of added services
AAV (normalized)
stability (normalized)
Case study: step 4 – determine services
› S’’1 = S1  {s1, s2, s4} = {s3, s9, s10, s11, s13}  {s1, s2, s4} =
{s1, s2, s3, s4, s9, s10, s11, s13}
› S’’2 = S2  {s1, s4, s6} = {s2, s3, s5, s9, s10, s11, s12}  {s1,
s4, s6} = {s1, s2, s3, s4, s5, s6, s9, s10, s11, s12}
› S’’3 = S3  {s2, s4, s6} = {s1, s3, s9, s11}  {s2, s4, s6}= {s1,
s2, s3, s4, s6, s9, s11}
Case study: step 4 – determine services
- Sca = S’’1  S’’2  S’’3
- Sca = {s1, s2, s3, s4, s9, s11}
previous slide
see services in bold on
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
Limitations
› No effort or resource constraints
› No interface problems
› Simplified trade-off algorithm
› Interpretation of stability
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
04-28-11 | 24
Thank you for your attention
Backup
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