2011, A POLICY BASED GOVERNANCE FRAMEWORK FOR CLOUD SERVICE PROCESS ARCHITECTURES
•Download as PPTX, PDF•
0 likes•128 views
This document proposes a software architecture for sharing business processes across multiple tenants in a cloud environment. The key elements are: - An architectural style called Service-oriented Process Architecture (SPA) that extends SOA principles to allow runtime governance of shared business processes. - A policy framework that models business rules and policies as metadata for customizing processes on-the-fly based on coordination protocols. - An aspect-oriented policy (AOP) enhancement that extends the policy framework to support additional customization through aspects modeled as policies. - An evaluation case study that demonstrates expressing business policies and shows the coordination framework enables on-the-fly process customization for tenants.
Recommended
Recommended
More Related Content
What's hot
What's hot (10)
Similar to 2011, A POLICY BASED GOVERNANCE FRAMEWORK FOR CLOUD SERVICE PROCESS ARCHITECTURES
Similar to 2011, A POLICY BASED GOVERNANCE FRAMEWORK FOR CLOUD SERVICE PROCESS ARCHITECTURES (20)
Recently uploaded
Recently uploaded (20)
2011, A POLICY BASED GOVERNANCE FRAMEWORK FOR CLOUD SERVICE PROCESS ARCHITECTURES
- 1. MingXue Wang Supervisor: Dr. Claus Pahl 1
- 2. • Motivation • High level contributions • Proposed solutions – Architectural style – Architecture framework • Policy model • Coordination • AOP enhanced policy framework • Case study with evaluation • Conclusions and future work 2
- 3. • Motivation • High level contributions • Proposed solutions – Architectural style – Architecture framework • Policy model • Coordination • AOP enhanced policy framework • Case study with evaluation • Conclusions and future work 3
- 4. Service providers 4 Service providersService consumers
- 5. Business processes are the centre of the business and day-to-day operations of organisations. • Rapid reaction to ever changing market conditions • Quickly adopting new business processes for new business or products • Reusing common process designs for different domains • Increasing Cloud Computing and Business Process Outsourcing 5
- 6. 6 Process providers Service providers Service providersService consumers Process providersProcess consumers
- 7. Service providersService consumers WS-Policy and frameworks Process providers Service providers 7 Process providersProcess consumers our focus: Process sharing in multi-tenancy environment (was) no solution available current business rule approaches, BPM solutions
- 8. • Business process in cloud 8 Such as Cafe project, Salesforce.com (There are still some issues with the solutions) Such as WSO2 multi-tenancy BPEL engine, Mc-Cube Our approach Key difference compare our with others: We offer business processes as software components, just as Web services. The overall software architecture for software development needs to be addressed.
- 9. • Motivation • High level contributions • Proposed solutions – Architectural style – Architecture framework • Policy model • Coordination • AOP enhanced policy framework • Case study with evaluation • Conclusions and future work 9
- 10. • Architectural style • Architecture framework 10
- 11. • Motivation • High level contributions • Proposed solutions – Architectural style – Architecture framework • Policy model • Coordination • AOP enhanced policy framework • Case study with evaluation • Conclusions and future work 11
- 12. • Aims at process sharing for multiple tenants • The architecture concept and elements – Business processes, governance components, coordination protocols • The principle: Process governability – The ability for external monitoring and control as governance of multiple consumers – Processes are governable – Goal • To attract the potential tenants with requirements, i.e., business policies. • To increase the process customizability and adaptability for individual tenants and multiple tenants. 12
- 13. • The SPA principle with impact on SOA principles 13
- 14. • Motivation • High level contributions • Proposed solutions – Architectural style – Architecture framework • Policy model • Coordination • AOP enhanced policy framework • Case study with evaluation • Conclusions and future work 14
- 15. • Policy are viewed as customization metadata of business processes. • Relying on coordination protocols for on-the- fly customization • Rule elements are basic elements of policy model, and follow the ECA paradigm. 15
- 16. • Rule categorisation is based on the safe boundary of business process execution – Flexibility rule • Within the business safe boundary • Business dynamics – Constraint rule • On the business safe boundary • Business compliance – Fault rule • Outside the business safe boundary • Fault (both runtime & business aspect fault) – Utility rule* • Does not control or affect the process execution 16
- 17. • Overview of policy model in UML 17 PolicySet Policy Rule
- 18. • Motivation • High level contributions • Proposed solutions – Architectural style – Architecture framework • Policy model • Coordination • AOP enhanced policy framework • Case study with evaluation • Conclusions and future work 18
- 19. • Coordination protocols are real contracts between providers and consumers • Coordination model 19
- 20. • The protocol is activity centric • Process activity protocol – a protocol message schema – a Finite State Machine (FSM) of COORc and COORp – a cache function specification of COORp 20
- 21. • BPEL processes are specially designed for a platform independent approach • BPEL processes complexity and protocol dependent are disadvantages • Template based implementation – The wrapper service template – The BPEL process template 21
- 22. • Motivation • High level contributions • Proposed solutions – Architectural style – Architecture framework • Policy model • Coordination • AOP enhanced policy framework • Case study with evaluation • Conclusions and future work 22
- 23. • For the extensibility of our policy framework • XML policy as the master policy of extended policies 23
- 24. • Policy aspect model 24
- 26. • Motivation • High level contributions • Proposed solutions – Architectural style – Architecture framework • Policy model • Coordination • AOP enhance policy framework • Case study with evaluation • Conclusions and future work 26
- 27. • Illustrate the SPA style architecture • The issues of current approaches are overcome. 27
- 28. • Demonstrate how business policies are expressed in our policy language • Various aspects of business policies can be covered – Four cases covers different aspects 28
- 29. • The coordination framework is effectiveness • The performance overhead of the coordination framework is considered as acceptable 29
- 30. • Additional policy models could be seamlessly added on top of our predefined XML policies – extend with high level policy for time windows – extend with Jess rule for rule reasoning 30
- 31. • Motivation • High level contributions • Proposed solutions – Architectural style – Architecture framework • Policy model • Coordination • An AOP enhance policy framework • Case study with evaluation • Conclusions and future work 31
- 32. • Software of SaaS is possible in context of process logics, i.e., Process as a service in our context. • The SOA style and RAs do not consider of process sharing. We defined a separate architectural SPA style contains a principle to extend the SOA style and has impact on the SOA principles. • Policy can act as a customization metadata of business processes. We defined a policy model. • Process on-the-fly customization and adaptation can be achieved from process consumers by means of process runtime governance based on process element – business activity. We provided a coordination framework. • Aspects can be modelled as policies on top of our policy model, offering extensibility to process consumers. We provided an AOP enhanced policy framework. 32
- 33. • Measuring of runtime governability • Highly level policy modelling and related algorithms • Enhancements of coordination protocol and framework • Scalability of coordination framework • Enhancements of aspect specification 33
- 34. Thank you very much! Any questions? 34
- 35. 35
- 36. 36
- 37. 37
- 38. 38
- 39. 39 Problems: • Pre-registered account • Policy centralization and reuse • Confidentiality of policies • … Used by Café project, salesforce.com, etc.
- 40. Principle for SPA architectural style: Process runtime governability Different from SOA: service autonomy 40Distributed and Multi-tenant runtime governance Different from current approaches
- 41. 41
- 42. • SOA principles – Standardized Service Contracts – Service Loose Coupling – Service Abstraction – Service Reusability – Service Autonomy – Service Statelessness – Service Discoverability – …. 42
- 43. • Multi-tenancy (in its true sense) refers to the fact that an application used by different customers must ensure that the data produced by one customer is complete isolated from the data produced by another customer. • First-degree multi-tenancy – salesforce.com and ours • Second-degree multi-tenancy – IBM DB2 • Lesser-degree multi-tenancy – Oracle solution 43
- 44. 44 • ISO 38500 IT Governance Standard describes a framework with six guiding principles. • The Open group is drafting a technical standard for SOA governance • The definitions of SOA governance agree in its purpose of exercising control. typical governance issues: – Compliance to standards or laws – Ensuring quality of services – Using policies to restrict behaviour – Monitoring performance of services – …
- 45. • An orchestration is based on a model where the composition logic is executed and controlled in a centralized manner. • A choreography typically assumes that there is no single owner of collaboration logic. • However, one area of overlap between the current orchestration and choreography extensions is the fact that orchestrations can be designed to include multi- organization participants. • An orchestration can therefore effectively establish cross enterprise activities in a similar manner as a choreography. 45
- 46. 46
- 47. • The concept of join points, matched by pointcuts, is the key to AOP which distinguishes it from older technologies offering only interception. • Need general support for domain-specific aspect languages. Need specification-level joint-point ontologies (AspectJ is implementation level.) • Domain-Specific AOP • Event based AOP [Rèmi Douence, 2001] • State based AOP [Noorazean Mohd Ali, Awais Rashid, 2005] • Action based AOP • Policy based for business process • Pc ::= Invoke(ba) | process(bo) | handle(bf) |request(bp) | Pc||Pc | Pc&&Pc | !Pc • Ad ::= [syncex] Pos : AdMes{‘{body}’} Pos::= before | after | hander • Body ::= Jm::= …. 47
- 48. 48 – Resource sharing, on demand use, pay per use model, multi-tenancy – Infrastructure as a service, Platform as a service, Software as a service.
- 49. 49
- 50. 50
Editor's Notes
- Thank you for be here for my viva.
- This is my presentation agenda. First I will give motivation of our work. Then I give high level contributions. After that, we detail our proposed solutions and evaluation. Finally, I talk about conclusions and future work.
- SOA is a business centric architectural style is widely adopted in IT infrastructures. The building blocks of SOA are business tasks, or services, which are platform-independent computational components. We can give more clear understanding in this diagram. There are some business services available from service providers, for example, credit card checking service, online transfer service from bank of Ireland, email message service fro Google, etc. There are some organisations as service consumers could use these services to implement their business processes. For example, an organisation can picks up some services to build a checkout business process for its supply chain or online shopping system. In this case, they could use money transfer services from banks, shipping services from logistic companies, etc. Other organisations also use these services to implement their business processes. And this is how the business collaborated in SOA and current IT industry.
- Business processes are the centre of the business and day-to-day operations of organisations. But organisations as service consumers themselves need concern with process development themselves in SOA style architectures, and this is also defined in SOA references architectures. But business demand more than what SOA offered today. Today’s business environment is very dynamic. For example, the organisation would like adding or selling insurance with their products for customers. Organisations constantly look for new business processes for new business or products. They want rapid reaction to ever changing market conditions. While developing own business processes from sketch is very costly and time consuming, and have risk on return on investment. They expect business processes ready to use with pay-per-use model, just as cloud paradigm.
- So we would extend the service boundary from SOA. It covers business processes. organisations could outsource these business processes. For the process consumer, they can directly use these processes for their consumer applications. The process development, maintainers cost, and the risk on return of investment of process development could be reduced. The business processes are not only restricted within an organisation. These process as platform-independent workflow component can be directly used by process consumers for their consumer applications or sub-business processes.
- However, different organisations always has different business requirements, regulations, etc., i.e., different business policies as nature of the business. For example company A only accept customers within US. But company B would like take order for all over the Europe. Company A only want use payment service from band of Ireland as it considers Citi bank as its trust partner. The company B would use a payment service from any company. For policies between service provider and consumers, WS-Policy is an effort from W3C that provides a mechanism to specify policy information of Web services. However, WS-Policy and frameworks only focus on policy expression and intersection algorithms for service level collaboration with SOA. Runtime policies of processes and enforcement are completely out of scope and are not concerned. For business policies associated to processes, policies can be further expressed into business rule statements, which can be formalized in a rule language and executed in a rule engine for production systems. While the purpose of current business rule approaches (include Business Process Management - BPM suites on the market) is to bring business agility by the ability of rapid changes on processes within an organisation for SOA. There was no solution between the boundary of process provider and client regards with business policy.
- Some on-going researches within in EU project are attempting to address the problem in both Software and Platform cloud layers. Such as Café project proposes a composited application based BPEL delivery, where process consumers can customize the application with process variability descriptors which from the concept of software product line. Other projects, such as WSO2 carbon framework tries to solve the problem in the platform layer by providing extend BPEL engines. It introduces a compliance interface that allows enterprises to gather process evidences from a BPEL engine as well as enforce rules on the process. While, the key difference compare our with others is that, They do not offer business processes as software components, just as Web services. When business processes are software components available for on demand requests in the Cloud, the overall software architecture for utilizing these components for software development needs to be addressed. Our project addresses this problem, that was not been discussed before.
- This is my presentation agenda. First I will give motivation of our work. Then I give high level contributions. After that, we detail our proposed solutions and evaluation. Finally, I talk about conclusions and future work.
- This diagram shows our key research issues and main contributions. We identify the problem as architecture problem, large services or business process offered by providers is difficult to meet various requirement of different consumers in same time. An software architectural style is a set of design guidelines, principles, and constraints that dictate how components can be composed, behave, and communicate. In overall, the main problem of the SOA style is that the current principles are defined with little consideration for the process sharing for multi-tenancy cloud applications. We define the architectural style consists of a principle focusing on the adaptation and customization of business processes. By focusing on SOA architecture, we provide a separated architectural style to extend the SOA style. And a supported architecture framework for the style for the developers. ----- In overall, the main problem of the SOA style is that the current principles are defined with little consideration for the process sharing for multi-tenancy cloud applications. We define the architectural style consists of a principle focusing on the adaptation and customization of business processes. Business policies of process consumers must be addressed. Policies defined by consumers would act as customization metadata of business processes. We provide a policy specification to formalizing business policies as customization metadata of business processes of providers. Defined policies of processes consumers must be enforced on process execution when consumers consume the processes. We provide a coordination model and protocol serve as the base of the distributed and multi-tenant and process runtime governance For the multi-tenancy requirement, the process should not require redevelopment and redeployment for enforcing policies for each consumer, since the process is shared by multiple consumers. We provide a template approach for BPEL implementation for coordination protocols. An extendible policy model will provide an advantage on extendibility and advanced requirements needed in process governance or customization. An AOP enhanced policy framework to address additional features that might be required for process runtime governance by consumers. A policy based AOP specification is defined on top of the policy model for extensibility.
- The SPA aims at sharing business processes for multiple tenants who have various business policies regarding the processes. The concept is derived from code mobility of distributed computing. The primary architecture elements includes two computational components: business processes from process providers, and governance components contained business policies of process consumers. And coordination protocols defined the contracts between above two components. Similar to the SOA style, we defined a principle allow service developers to balance between different principles depend on requirements. Process governability is ability for external monitoring and control as governance of multiple consumers, so the consumers can enforce their own business policies on process execution. The Goal is to attract the potential tenants with requirements, i.e., business policies. Also to increase the process customizability and adaptability for individual tenants and multiple tenants
- Since the principle defines a very different goal which compares with the goals defined by the SOA principles. There is impact on other SOA principles, as a consequence, the service developer need aware with it and make a balance on service process design. For example, since governability is need be defined in contract, it influence the content and design standards on standardized service contract.
- This is my presentation agenda. First I will give motivation of our work. Then I give high level contributions. After that, we detail our proposed solutions and evaluation. Finally, I talk about conclusions and future work.
- As described, various business policy are main restrictions on process sharing. A policy language used for formalizing business policies can be viewed as customization metadata of business processes. The policy weaver relies on coordination protocols for on-the-fly customization. The policy is modelled in a hieratical structure which is similar to most policy model in service management and network management. It is also to support administrative levels. The policy is build by a set rules, and are grouped in a policyset which for policies have similar sematics. The rule element model follows the ECA paradiam. It contains a governance action on managed objects under conditions, which are the states of the managed objects.
- In the policy model, We categorize rules based on the safe boundary of business process execution. As a consequence, we are able to define policy object and governance actions. The first three types of rules make affect on process execution by have provider side actions. The last type is utility rules, do not directly control or affect the process execution.
- This diagram provide a overview of policy model in UML. The text is difficult to see here, but can be further explain in later on request. Multiple Rules in a policy, or multiple Policies in a policySet are combined by a set of defined combining algorithms for conflicts. The combining algorithms allows policy developers to customize policy weaving behaviours.
- This is my presentation agenda. First I will give motivation of our work. Then I give high level contributions. After that, we detail our proposed solutions and evaluation. Finally, I talk about conclusions and future work.
- Coordination protocols are real contracts between providers and consumers, i.e., the business processes and governance components . The coordination model contains two types of coordinator associated the governance components and business processes. The process consumer will initialize a coordination context which is contained in a process request. The protocol specified in the context will ensure the policies be enforced during process executions or business transactions.
- The protocol is activity centric, so can be apply on any business processes regardless different flow logic. The protocol contains a message schema define the data structure on message exchange, As other coordination protocols, such as WS-coordination, Finite state machines define the behaviours of coordinators on coordination conversations. And finally, a cache function specification is to reduce the coordination overhead.
- In our case, the coordination protocol is implemented with BPEL for a platform independent approach. While the disadvantage is that BPEL processes are complex and protocol dependent. We provided two templates: the wrapper service template, the process template for the BPEL implementation. An amount of coordination logic is developed inside of the wrapper service template, are hide from BPEL processes. So we could reduce the an amount of BPEL complexity.
- We have provided a XML policy model and a coordination framework based on protocols for a policy based governance framework. We cannot expect our policy framework to offer process consumers all of the features expected in process governance. Such as complex logic reasoning offered Jess rules language. The AOP enhanced policy is for the extensibility of our policy framework. It is offer a power full programming approach, so process consumers could adopt such as Jess rules as a policy language. But still, our XML based policy model in underlay and as a master policy of extended policies. Or as master policy of aspects.
- In our AOP framework. An aspect model is defined with a mapping to XML policies model. So the AOP approach is integrated seamlessly into the policy framework. And XML based policies, and aspects are weaved together by the policy weaver. Aspect is realized as policy. The join point is mapped to policy managed objects. Etc. Based on this model, we have provide an aspect specification different from current AOP frameworks to address our unique problems, such as distributed aspects and Multi-tenancy.
- In our framework, each aspect is either a Java class or bean. The advices of an aspect as Java methods are defined in the aspect Java class. The pointcut and advice type metadata of an advice are defined as Java annotation and retrieved by Java reflection. Since the AOP is designed on top of policy weaving and coordination protocol. The aspect weaving still satisfy the multi-tenancy requirement of our framework.
- This is my presentation agenda. First I will give motivation of our work. Then I give high level contributions. After that, we detail our proposed solutions and evaluation. Finally, I talk about conclusions and future work.
- In our approach. case study and evaluation are did for each proposed solution components to demonstrate how the sub-problem is addressed. -------- With the SPA style, We draw an SPA application architecture diagram with the case study. we assume All business processes are service processes with the process governability principle applied in this case. Then we analyse the diagram and demonstrate the problem we identified in current approach such policy centralization is addressed.
- In case of policy model, we demonstrate how business policies are expressed in our policy language. For example, Customer account information is not allowed to be passed to business partners that have low security. We used four different cases to cover configuration, protection, optimization, and healing all four autonomic aspects requirements that arise from business policies. So we can say our policy language can be for expressing various business policies.
- We need provide a effective framework as the basic requirement. It means that the business process can be governed in a distributed and multi-tenant environment using our approach, i.e., policies are enforced in business process executions for multiple consumers at the same time for their business goals to be achieved. The results has shows our coordination framework is effectiveness. A performance overhead is also expected on coordination conversations. Our study show the coordination overhead of the activity was around 245 ms with the cache disabled and around 127 ms with the cache enabled in a violation free situation for an activity in business processes. The overhead is also increase liner when number of policies increase. We consider the overhead is acceptable compare as it is in million seconds level, where business process generally take hours or day to completed.
- We developed aspects with in two examples: to extend with high level policy for time windows, also extend with Jess rule for rule reasoning. The result shows the AOP enhanced policy framework offers a great extensibility on the XML based policy model and show that additional policy models could be seamlessly added on top of our predefined XML policies.
- The future work are in the following ideas: We would like provide a compensative metrics and approaches for measuring process runtime governability. And this requires more research. High level goal policies are intuitive, and can be easily used to express business policies or goals for business developers. Highly level policy modelling and related algorithms in one of our future work The protocol can be extended and the coordination frameworks might be redesigned to support generic BPEL processes without requiring specific process design using BPEL templates. The scalability is one of major concern of shared applications in cloud computing. We would intestate this problem and have scalable framework, such as based on apache hadoop. Finally, we also would like enhance the aop framework to make it easier for developers who have experience with workflow modelling, etc.
- The development process
- Questions on SOA principles
- Choreography is addressed?
- For question: Why business process as software component
- For question What is AOP ? Why your aop different with others? Our AOP is focus on governance of business processes.
- Cloud computing Contribution compare with current specifications
- Consumer still able service and process implementation
- The difference of coordinationC and coordinationP in coordination chain