Dynamic Service Composition Judith E. Y. Rossebø May 21, 2008
advertisement
Dynamic Service Composition Judith E. Y. Rossebø May 21, 2008 Outline • • • • • • Services and service composition Motivation – why dynamic service composition? Background for the approach Overview of the policy-based approach Example – Voice over IP service Conclusions Services and Service Composition What is a service? A service is: an identified functionality aiming to establish some goals/effects among collaborating entities. Captures: • active services • passive services • end user services • component interfaces (Web Services, CORBA, JINI, …) • layered functionality (ISO OSI) C1 C2 Layer n Layer n-1 Cn Service essentials: • Service is functionality; • it is behaviour performed by entities. • Service imply collaboration; • it makes no sense to talk about service unless at least two entities collaborate. • Service behaviour is cross-cutting; • it may depend on the behaviour of other services • it may be depend on sharing of resources with other services • Service behaviour is partial; • it is to be composed with other services Service Composition • Service is considered as a functionality involving a collaboration among entities to achieve desired goals/effects for end users or other entities • Service Composition - allows for incremental service development. • service components statically or dynamically combined at run time • Allows for reuse of components • Modeling service composition using UML 2.x • UML 2.x collaborations • Structured way to define services in terms of collaborating roles • Means to decompose/compose services using collaboration uses • UML 2.x sequence diagrams • To specify service behaviour Role Role Collaboration Collaboration Service Composition - dependencies • Cross-cutting nature of services: • Service components interact for the execution of services • Services depend on each other (vertical composition) • Service depend on shared resources and enablers (horizontal composition) Vertical composition (within an agent) service component/part Service 1 Service 2 Service 3 Terminal Agent x User Agent y Group Agent z Terminal User Agent w Agent k Horizontal composition (within a service) Our approach to dynamic composition • Policy combined with modelling techniques • To make the overall coordination of collaborations participating in a service more flexible and adaptable. • We focus on: Specification of mechanisms at service model layer Finally, Enable dynamic composition in the runtime system Enable transformation to design models Policy-based Dynamic Service Composition PESM Service models Policy Rules UML Collaborations for services, connectors Policy Rule ID Condition Trigger Action Goal PDP1_ru1 P1, A.x, B.y t1 Do CU1 A.g1, B.g1 PDP2_ru1 P2, A.t, C.r t2 Do CU2 A.g2, C.g2 PDP2_ru2 P3, B.f, C.g t3 Do CU3 B.g3, C.g3 Model transformation Local PESMs Design models Systems Local Policy Policy Rule ID Condition Trigger Action Goal PDP1_Ar1 P1, x, B.y t1 Do CU1 g1 PDP2_Ar1 P2, t, C.r t2 Do CU2 g2 PDP2_Br2 P3, f,C.g t3 Do CU3 g3 Components, conectors Model transformation Realization dynamic composition Monitoring term Service platforms NGN Enablers Why Dynamic Service Compositon? Motivation • Securing availability of services is challenging • The telecommunications environment has evolved • from centralized to distributed • Services are being developed in a distributed manner in a connectionless environment requiring cooperation of several components and actors • Example: Ensuring availability of the VoIP services. • a user expects to be able to place a call, complete the call with out being cut off. • The service can be secured by e.g., providing stronger authentication • Can this be deployed dynamically? Internet Internet IP-based IP-based Net Net VoIP server VoIP server Motivation • Our approach: Development of (re-usable, flexible) patterns to ensure availability in composition • It should be possible to dynamically adapt, change or exchange services involved in a service collaboration • Example: Authentication to VoIP • – Our approach should support exchanging weaker SIP authentication with stronger IMS AKA authentication… User User authenticateeA authenticatee UAs1:UTPA HTTP UAs1:MTPA IMS AKA Digest authenticateeB authenticator Service Service Unilateral two pass authentication Extension of SIP authentication (username and password based) providing mutual authentication : HTTP digest protocol and MD5 (USIM symmetric key-based) Using IMS AKA Background Collaborations and roles • An elementary collaboration is a service collaboration with exactly two elementary roles that collaborate on an interface • An elementary role is the smallest modelling element • Composite roles are compositions of elementary roles. • In dynamic composition, these are dynamic compositions of elementary roles Composing AA-Patterns and Services: • We provide a framework and classification of authentication and authorization patterns • For composing with services • To ensure that services are accessible to the authorized users only. UserPull Authentication authenticator authenticatee authenticator ty ar P o te Tw tica : s1 hen A U ut A Access Server s auths h t granter Au ion : s2 vat A U cti A authenticatee auths requestor Service Access Filter User authorisor authorisee USs2:Checking Access Rights Classification of authentication patterns TwoParty Authenticate Unilateral Authenticate UniOnePass Authenticate Mutual Authenticate UniTwoPass Authenticate MTwoPass Authenticate MThreePass Authenticate Classification of some unilateral two pass authentication patterns UniTwoPass Authenticate UniTwoPass Authenticate Symmetric ISO /IEC 9798 -2 5 .1.2 Two pass authentication UniTwoPass Authenticate crypto check function ISO /IEC 9798 -4 Two Pass Authentication 5 .1.2 UniTwoPass Authenticate Asymmetric UniTwoPass Authenticate using a Hash Function ISO /IEC 9798 -2 5 .1.2 Two pass authentication rfc 2617 HTTP digest with MD 5 Specifying AA-patterns : • UML 2.x collaboration diagram for generic two party AA-patterns • Specializations of generic patterns with properties/constraints and goals • UML 2.x sequence diagrams for modelling behavior • Interactions uses - for flexibility and reusability • Subject to service constraints (e.g. timing, processor capacity available, strength of algorithm required UserPull TwoPartyAuthenticate authenticator ty ar P o te Tw tica : s1 en UA uth A authenticatee authenticator Access Server auths hs granter t u :A tion 2 s va UA cti A authenticatee auths requestor Service Access Filter User authorisor authorisee USs2:Checking Access Rights Composition of VoIP and User Pull patterns Authentication authenticatee authenticator SecureVoIP (Userpull) authenticator 1: tion s UA tica en h t Au auths_granter ths u 2:A tion s UA ctiva authenticatee A auths_req_or voip_req_or User AccessControl Server USs1: Request VoIP authorisee voip_req_ee authorisor USs2:CAR voip_user rel_er ServiceProvider voip_provider USs3: VoIP Use USs4:END VoIP VoIP Use rel_ee voip_user voip_provider Policy and service management A policy rule is a rule that defines a choice in the (course of the) behavior of a system [Damianou, Dulay, Lupu, and Sloman] • Applied to dynamic service composition: • Policy rules are specified separately from the roles and collaborations • Enables collaborating roles to be dynamically composed at runtime • Allows for changes to be made at runtime by changing policy rules • Rather than changing the specifications of the roles themselves Why apply policy? • To separate the ordering of the roles from the roles themselves • To facilitate reusibility of roles in service composition • Enable dynamic composition at runtime • Policy is used to govern the composition of roles executed by actors dynamically • Making e.g. access control policies more evident in service models • Make it possible to connect the service specification to higher level strategies and goals • E.g. level of security to be provided, context parameters • To assist in selecting the most appropriate AA-patterns to apply. What is a policy? • A policy is a set of policy rules. • A policy rule is of the following form: if trigger T and condition C then action A and goal G • The trigger part (an event) describes when the policy should be applied • A message or signal associated with the collaboration or • an external signal or message from some other part of the system • The condition part defines constraints on its applicability • The action part defines what is to be done • For composition policies this means execute the collaboration • The goal part defines what is the desired result when the policy is applied. PDP1_rule2: T: ? (Request authentication, External, User) C: Rel (User.secret, AcS.knowledge), User.True, AcS.(Unilateral required AND Challenge required) A: UAs1b (authenticateeT -> User, authenticatorT -> AcS) : UTPA G: User.unilaterally_authenticated, AcS.authentication_successful Overview of the approach Service models Overview of the approach Service CU1(r1->A,r2->B):C1 r1 r2 CU2:C1 A r5 Action CU1 Go A.g, Policy Rules policy policy policy CU2(r1->A,r2->C):C1 r4 Trigger P, A.a, B.b, ?(m,E,A) PDP2 2 C 3: r1 PDP1_ rule1 r3 B C U 1: C 1 r2 U C • Service models PDP1 Policy Rule Condition ID PDP3 C r6 CU4:C3 CU3(r3->B,r4->C):C2 CU4(r5->A,r6->C):C3 Design models Policy Rule Condition Trigger ID PDP2_ ?RoleReq True C_rule1 (r2) PDP1_A • Design models Action Policy Management PDP1_B r1 PDP2_A PDP2_C r2 r1 PDP3_B Policy Rules PDP3_C r3 PDP3_A r2 PlayRole (r2) policy policy policy r2 r6 r5 Runtime system • Runtime system Policy Management - Translation - Refinement - Updating - Conflict Resolution - Dissemination - Enforcement Policy Rules policy policy policy Distribution Goal Cr2.g Overview of the policy-driven approach (1/3) • Service models • Collaboration diagrams composed from elementary collaborations Trigger T: • Choreography is defined by the PESM A receives message • PDPi - policy rules govern behavior associated with the collaboration m from E (external) (dependenies between sub-collaborations) • Policy rules stored in table with a pointer to the PDP the rule applies to Service models PDP1 Service B PDP2 2 C 3: r1 r3 U C C U 1: C 1 r2 CU1(r1->A,r2->B):C1 r1 r2 CU2:C1 A r5 r4 C Policy Rule Condition ID PDP1_ rule1 PDP3_ rule1 PDP3_ rule2 Action Goal CU1 A.g, B. T, B.k, C.i ?(m2,B,C) CU3 Policy Rules T, A.r, C.s ?(m3,A,C) CU4 B.g,C. P, A.a, B.b, ?(m,E,A) CU2(r1->A,r2->C):C1 PDP3 r6 CU4:C3 CU3(r3->B,r4->C):C2 Trigger CU4(r5->A,r6->C):C3 policy policy policy A.g,C. Service models Overview of the approach PDP1 Service r1 r2 CU2:C1 A r5 Action CU1 Go A.g, Policy Rules policy policy policy CU2(r1->A,r2->C):C1 r4 Trigger P, A.a, B.b, ?(m,E,A) PDP2 2 C 3: r1 CU1(r1->A,r2->B):C1 U C • Service models PDP1_ rule1 r3 B C U 1: C 1 r2 Policy Rule Condition ID PDP3 C r6 CU4:C3 CU3(r3->B,r4->C):C2 CU4(r5->A,r6->C):C3 Design models Policy Rule Condition Trigger ID PDP2_ ?RoleReq True C_rule1 (r2) PDP1_A • Design models Action Policy Management PDP1_B r1 PDP2_A PDP2_C r2 r1 PDP3_B Policy Rules PDP3_C r3 PDP3_A r2 PlayRole (r2) policy policy policy r2 r6 r5 Runtime system • Runtime system Policy Management - Translation - Refinement - Updating - Conflict Resolution - Dissemination - Enforcement Policy Rules policy policy policy Distribution Goal Cr2.g Service models PDP1 Service CU1(r1->A,r2->B):C1 2 C 3: r1 r2 CU2:C1 A r5 Action Goal CU1 A.g, B.g Policy Rules policy policy policy CU2(r1->A,r2->C):C1 CU2(r1->A,r2->C):C1 r4 Trigger P, A.a, B.b, ?(m,E,A) PDP2 PDP2 U C r1 PDP1_ rule1 r3 B C U 1: C 1 r2 Policy Rule Condition ID PDP3 PDP3 PDP3 C r6 CU4:C3 CU3(r3->B,r4->C):C2 CU3(r3->B,r4->C):C2 CU4(r5->A,r6->C):C3 CU4(r5->A,r6->C):C3 Design models Policy Rule Condition Trigger ID PDP2_ ?RoleReq True C_rule1 (r2) PDP1_A Action Policy Management PDP1_B r1 PDP2_A PDP2_C PDP2_C r2 r1 PDP3_B r5 Policy Rules PDP3_C r3 PDP3_A r2 r2 PlayRole (r2) policy policy policy r2 r6 Goal Cr2.g Overview of the policy-driven approach (2/3) • Design models • Define design components in the form of statemachines that can perform the roles defined in the service models • Based on global PESM diagram and global composition policy • Local PESM is derived for each composite role • Policy rules are distributed, (e.g. table for each local pesm) Policy Rule Condition Trigger ID PDP2_ ?RoleReq True C_rule1 (r2) PDP1_A Action Policy Management PDP1_B r1 PDP2_A PDP2_C r2 r1 PDP3_B r5 Policy Rules PDP3_C r3 PDP3_A r2 PlayRole (r2) policy policy policy r2 r6 Goal r2.goal Service models Overview of the approach PDP1 Service r1 r2 CU2:C1 A r5 Action CU1 Go A.g, Policy Rules policy policy policy CU2(r1->A,r2->C):C1 r4 Trigger P, A.a, B.b, ?(m,E,A) PDP2 2 C 3: r1 CU1(r1->A,r2->B):C1 U C • Service models PDP1_ rule1 r3 B C U 1: C 1 r2 Policy Rule Condition ID PDP3 C r6 CU4:C3 CU3(r3->B,r4->C):C2 CU4(r5->A,r6->C):C3 Design models Policy Rule Condition Trigger ID PDP2_ ?RoleReq True C_rule1 (r2) PDP1_A • Design models Action Policy Management PDP1_B r1 PDP2_A PDP2_C r2 r1 PDP3_B Policy Rules PDP3_C r3 PDP3_A r2 PlayRole (r2) policy policy policy r2 r6 r5 Runtime system • Runtime system • Dynamic composition Policy Management - Translation - Refinement - Updating - Conflict Resolution - Dissemination - Enforcement Policy Rules policy policy policy Distribution Goal Cr2.g Overview of the policy-driven approach (3/3) • Runtime system • Service parts/components interact for the execution of services • Design models are transformed to implementations that can be deployed in the runtime system • Bound to system parts depending on role-binding policies • Policy is distributed to the parts of the system • Policy enforcement agents in the system parts ensure that policy is enforced • Dynamic composition (policy-based) Policy Management Policy Rules - Translation - Refinement - Updating - Conflict Resolution - Dissemination - Enforcement policy policy policy Distribution Example: VoIP service Basic VoIP service • Composed of three elementary collaborations • The User composite roles plays three elementary roles: • voip_req_or • voip_user • vel_er Composition of VoIP and User Pull patterns Authentication authenticatee authenticator SecureVoIP (Userpull) authenticator 1: tion s UA tica en h t Au auths_granter ths u 2:A tion s UA ctiva authenticatee A auths_req_or voip_req_or User AccessControl Server USs1: Request VoIP authorisee voip_req_ee authorisor USs2:CAR voip_user rel_er ServiceProvider voip_provider USs3: VoIP Use USs4:END VoIP rel_ee VoIP Use voip_user voip_provider Global PESM: • Policy governed PDP1 Unilateral One Pass Authentication UAs1a (authenticateeO->User, authenticatorO->AcS) : UOPA • composition of two party collaborations • CHOICE of Authentication • Unilateral one pass PDP1_rule1: • Unilateral two pass User) T: ? (Request authentication, External, C: Rel (User.secret, AcS.knowledge), • Mutual two pass User.True, AcS. (Unilateral requiredSecureVoIP AND Challenge (Userpull) NOT required A: UAs1a (authenticateeO -> User, authenticatorO -> AcS) : UOPA authenticator AccessControl G: User.unilaterally_authenticated, AcS.authentication_successful Server : s1 tion UA tica n the Au auths_granter PDP1_rule2: s uth T: ? (Request authentication, External, User) A n : s2 atio A UAcS.knowledge), tiv C: Rel (User.secret, User.True, authenticatee Ac USs1: auths_req_or AcS.(Unilateral required ANDRequest Challenge required) voip_req_ee VoIP voip_req_or A: UAs1b (authenticateeT -> User, authenticatorT -> AcS) : UTPA authorisee authorisor User ServiceProvider USs2:CAR G: User.unilaterally_authenticated, AcS.authentication_successful voip_user voip_provider PDP1_rule3: USs3: VoIP Use rel_er rel_ee T: ? (Request authentication, External, User) C: Rel (User.secretA, AcS.secretB), User.True, AcS.Mutual required USs4:END VoIPauthenticateeB -> AcS) : MTPA A: UAs1c (authenticateeA -> User, G: User.authct(AcS), AcS.authct(User) Unilateral Two Pass Authentication UAs1b (authenticateeT->User, authenticatorT->AcS) : UTPA Mutual Two Pass Authentication UAs1c (authenticateeA->Us authenticateeB->AcS) : MTP PDP2 UAs2 (authsrequestor -> User, authsgranter->AcS) : AA PDP3 USs1: (voip_req_or ->User, voip_req_ee ->SP) : RM PDP4 USs2 (authorisee->User, authorisor->SP) :CAR PDP5 USs3 (voip_user->User, voip_provider->SP) : VUse PDP6 USs4 (rel_er->User, rel_ee->SP) : EM Global PESM - transformation to local PESM PDP1 UAs1a (authenticateeO->User, authenticatorO->AcS) : UOPA UAs1b (authenticateeT->User, authenticatorT->AcS) : UTPA PDP2 UAs2 (authsrequestor -> User, authsgranter->AcS) : AA PDP3 UAs1c (authenticateeA->User, authenticateeB->AcS) : MTPA Local PESM - Access Server Composite role: PDP1_AcS_rule1: T: ?(RoleReq(authenticatorO), User, AcS) C: Unilateral required A: PlayRole( authenticatorO) G: authentication_successful authenticatorO PDP1_AcS_rule2: T: ?(RoleReq(authenticatorT) ,User, AcS) C: Unilateral required AND Challenge required A: PlayRole(authenticatorT) G: authentication_successful PDP1_AcS_rule3: T: ?(RoleReq(authenticateeB), User, AcS C: Mutual required A: PlayRole( authenticateeB) G: authct(User) PDP1_AcS authenticatorT PDP2_AcS authsgranter authenticateeB Conclusions Conclusions • We have presented an approach to using policy in dynamic service composition for coordinating separately specified (re-usable) behaviors • Policy enforcement state machine diagram (PESM) • Diagram specifies the coordination of elementary service collaborations • Overall choreography becomes more flexible and adaptable • Policy • Allows for choice between alternatives of pre-defined behavior, and ordering of these • Can involve variables outside of a collaboration, e.g. context or requirements on strength of security to be provided • Composition policies • Provide necessary information for linking the separately specified behaviors together • Provide policy enforcement information for enabling and governing dynamic service composition Thank you for listening Questions?
