Achieving Multi-tenanted Business Processes in SaaS Applications
Download as PPTX, PDF•2 likes•1,456 views
The document discusses the challenges of achieving multi-tenanted business processes in Software as a Service (SaaS) applications, outlining key issues like managing overlapping tenant requirements and avoiding invalid modifications. The proposed solution combines Service-Oriented Architecture (SOA) and Business Process Management (BPM) to model a flexible and adaptable organizational approach. It aims to enhance the capability to handle variations in tenant requirements while minimizing code duplication and ensuring process integrity.
Achieving Multi-tenanted Business Processes in SaaS Applications
- 1. WISE 2011 - SydneyAchieving Multi-tenanted Business Processes in SaaS Applications Presenter: Malinda KapurugeCo-Authors: Prof. Jun Han and Dr. Alan Colman1
- 3. SaaS
- 4. SOA and Business Process Modelling
- 6. Challenges
- 7. State of the Art
- 8. Our Contribution and Approach
- 10. Questions2
- 11. Software as a Service (SaaS) – A long story in short. A software delivery model.
- 12. SaaSusers (tenants) rent the software.
- 13. SaaS vendor owns, hosts and maintain the software and infrastructure.3TenantVendorRentOwns, host and maintainSubscription feeSoftware (as a Service)
- 14. SaaS- Benefits for Tenants4
- 15. SaaS - Benefits for Vendors5
- 16. SaaS and SOAVsSOA - A construction model.SaaS - A delivery model.SaaS and SOA complements each other (Laplante, 2008).
- 17. SOA is widely used to construct SaaSapplications.
- 18. SaaS application a Service Composite
- 19. In order to achieve the SaaS benefits, service compositions need to be multi-tenanted.6
- 20. Scenario - Roadside Assistance as a Service SaaS Tenants Travel AgentInsurance Co.Car SellerSmall and medium businesses SOARoSaaS.comBPMSaaS VendorService ProvidersTow trucksCase OfficersGaragesParamedicsTaxis7
- 21. Business Process Management– Why?BPM advantages
- 23. Easy Re-design
- 25. Multi-tenancy? 8
- 26. Multi-tenancy$$Separate application instances.Separate infrastructure.Separate application instances.Shared infrastructure.Shared application instance.Shared infrastructure.Multi-instance multi-tenancySingle-instance multi-tenancy9
- 27. Scenario - revisited10Single shared code base CloudService Composition
- 28. Scenario - revisitedTenants have many overlapping requirements.
- 29. Ex:- All need roadside assistance which require managing activities such as Towing, Repairing etc.
- 30. Requirement are ‘similar’ but not the ‘same’.
- 31. Ex:- The way towing need to be carried out for CarSeller might ‘slightly’ different from the InsuranceCo.
- 32. Tenant requirements can change in the future.
- 33. Ex:- CarSeller might need Tow activity to be paused until a Taxi picks up the motorist.
- 34. Changes are made on a shared code base. Invalid boundary crossings?
- 35. Ex:- A change proposed by CarSeller can harm goals of InsuranceCo.11
- 36. Challenges for SaaS vendorChallenge 1 : Capturing commonalities
- 37. Tenants have many overlapping requirements.
- 38. Duplications need to be minimized.
- 39. Challenge 2 : Allowing variations
- 40. Requirements are similar but not the same.
- 41. Variations with minimal duplications.
- 42. Challenge 3: Avoiding invalid boundary crossings
- 44. Many tenants and many collaborations. Unpredictability12
- 45. State of the Art WS-BPEL – the front runner.
- 46. No explicit support for multi-tenancy.
- 48. Improvements - Two major categories.
- 51. Still not good enough to address the challenges due to single-instance multi-tenancy.
- 52. Code duplications and maintainability issues.
- 53. Lack of support for unpredictability at runtime.13
- 54. Our ContributionWe propose an ‘Organizational’ approach.
- 55. Uses SOA+BPM to model SaaS applications.
- 57. Equipped with specific features to employ BPM in multi-tenanted SaaS applications.
- 58. Addresses above mentioned challenges.
- 59. Contributions
- 60. An architecture to model multi-tenanted process-aware service-composites.
- 61. A flexible process modeling and execution language.14
- 62. Approach - overview15How to model and maintain a single application instance?Adaptable OrganizationService Composition
- 63. Approach - overview16Three layers
- 65. Behavior layer
- 68. Roles and Contracts among them.
- 69. Contracts: Represent role-role relationships. Mutual obligations and interactions.(Colman, 2007)18
- 70. Behavior19
- 71. Behavior ModelingA Behavior Term capture allowed behavior (collaboration) of the organization. E.g., Towing
- 72. An organization can have many such behavior terms.
- 73. E.g., Repairing, Complaining, Hotel booking
- 75. Modifications to behavior terms are subjected to these constraints.
- 76. Re-usable, Declarative. Sample behaviour term, Towing20
- 77. Processes21
- 78. Process ModelingA process definition is a collection of behavior terms.
- 79. Can dynamically include or exclude behavior terms
- 80. Capture process level constraints (to protect tenant goals)
- 81. A process view is dynamically constructed depending on grouped behavior terms.
- 82. Event-driven Process Chain (EPC) view22
- 83. Dynamic Process Views (EPC)23
- 84. Challenge 1: Capturing Commonalities24Separate process views for each tenantOverlapping requirements.
- 85. Solution: Behavior terms can be re-used / shared.
- 86. Code duplication is minimized.
- 87. Processes get automatically updated upon changes to behavior terms.A pool of behaviour terms defined in the organization
- 88. Challenge 2: Allowing Variations Requirements are similar but not the same.
- 89. Example 1: Both tenants CarSeller and InsuranceCo share Towing. Only the tenant CarSellerrequire an additional pre-condition to be added to start task Tow.
- 91. Specialize behavior Towing to create another (Towing2).
- 92. Only the additional properties are specified.
- 93. Towing2 inherits all the properties of Towing except thoseoverridden.25
- 94. Challenge 2: Allowing Variations Example 2: TravlCorequire an additional Task to be added to alert the motorist (MM) once the towing is complete.
- 95. Solution: Specialize behavior Towing to create Towing3.
- 96. Multiple variations of same behavior can co-exist in the organization.26
- 97. Challenge 2: Allowing Variations 27OriginallyExample 1Example 2
- 98. Challenge 3: Avoiding Invalid Boundary CrossingsChanges are carried out in a common code base. Possible invalid boundary crossings.
- 99. Example: CarSeller request a modification to a behavior term shared with InsuranceCo.
- 100. How to identify the boundary for safe modification?
- 101. Solution: Two-tier scoped constraints. 28
- 102. Challenge 3: Avoiding Invalid Boundary Crossings29Change ?Process constraintsBehaviour constraintsLinks among behaviour terms and process definitions, provide the exact constraints need to be validated.Better than global set of constraints. No unnecessary restrictions. (Kapuruge, SCC 2011)Nothing less …! Nothing more …!
- 104. Related Work and Evaluation 31Code duplications and maintainability issues.
- 105. Lack of support for adaptability at runtime.Are we there?32Not yet !
- 106. We addressed ONLY THREE identified challenges.
- 107. Many challenges need to be addressed to achieve true multi-tenanted business processes.
- 108. Example: Better tooling support, scalability issues of the enactment engine, challenges in managing data-flow.
- 109. Future Work !!!References(Laplante, 2008) : Laplante, P.A., Jia, Z., Voas, J.: What's in a Name? Distinguishing between SaaS and SOA. IT Professional. Vol. 10,pp.46-50 (2008)
- 110. (Colman, 2007): Colman, A.: Role-Oriented Adaptive Design (PhD Thesis). Swinburne University of Technology, Melbourne (2007)
- 111. (Kapuruge, SCC-2011): Kapuruge, M., Colman, A., Han, J.: Controlled flexibility in business processes defined for service compositions. In: Services Computing (SCC) pp. 346-353. IEEE Press, (2011)
- 112. (Kapuruge, EDOC-2011): Kapuruge, M., Colman, A., King, J.: ROAD4WS – Extending Apache Axis2 for Adaptive Service Compositions. In: Enterprise Computing Conference (EDOC) IEEE Pres, (2011)33
- 113. Questions ?34