Achieving Multi-tenanted Business Processes in SaaS Applications

1,842 views

Published on

With the emergence of Cloud Computing and maturity of Service Oriented Architecture (SOA), the Software-as-a-Service (SaaS) delivery model has gained popularity, due to advantages such as lower startup cost and reduced time to market. A SaaS vendor owns and takes the responsibility of maintaining a single application for multiple clients/tenants who may have similar but also varying requirements. Business process modeling (BPM) approaches can be used to package service offerings to meet these varying requirements on a shared basis. However the customizations in those business processes can be challenging. In this paper we discuss the challenges arising from single-instance multi-tenancy, and present our approach to defining customizable business processes in SaaS applications to address those challenges.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,842
On SlideShare
0
From Embeds
0
Number of Embeds
599
Actions
Shares
0
Downloads
59
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Economies of scale : When a product is produced in larger scale, there is less input cost per item produced.
  • RoSaaS cannot alone provide all the services.
  • Code duplications and maintainability issues. Lack of support for unpredictability at runtime.
  • Achieving Multi-tenanted Business Processes in SaaS Applications

    1. 1. WISE 2011 - Sydney<br />Achieving Multi-tenanted Business Processes in SaaS Applications <br />Presenter: Malinda Kapuruge<br />Co-Authors: Prof. Jun Han and Dr. Alan Colman<br />1<br />
    2. 2. Outline<br /><ul><li>Introduction
    3. 3. SaaS
    4. 4. SOA and Business Process Modelling
    5. 5. Multi-tenancy
    6. 6. Challenges
    7. 7. State of the Art
    8. 8. Our Contribution and Approach
    9. 9. Addressing Challenges
    10. 10. Questions</li></ul>2<br />
    11. 11. Software as a Service (SaaS) – A long story in short. <br /><ul><li>A software delivery model.
    12. 12. SaaSusers (tenants) rent the software.
    13. 13. SaaS vendor owns, hosts and maintain the software and infrastructure.</li></ul>3<br />Tenant<br />Vendor<br />Rent<br />Owns, host and maintain<br />Subscription fee<br />Software (as a Service)<br />
    14. 14. SaaS- Benefits for Tenants<br />4<br />
    15. 15. SaaS - Benefits for Vendors<br />5<br />
    16. 16. SaaS and SOA<br />Vs<br />SOA - A construction model.<br />SaaS - A delivery model.<br /><ul><li>SaaS and SOA complements each other (Laplante, 2008).
    17. 17. SOA is widely used to construct SaaSapplications.
    18. 18. SaaS application  a Service Composite
    19. 19. In order to achieve the SaaS benefits, service compositions need to be multi-tenanted.</li></ul>6<br />
    20. 20. Scenario - Roadside Assistance as a Service <br />SaaS Tenants <br />Travel Agent<br />Insurance Co.<br />Car Seller<br />Small and medium businesses <br />SOA<br />RoSaaS.com<br />BPM<br />SaaS Vendor<br />Service Providers<br />Tow trucks<br />Case Officers<br />Garages<br />Paramedics<br />Taxis<br />7<br />
    21. 21. Business Process Management– Why?<br /><ul><li>BPM advantages
    22. 22. Automated Enactment
    23. 23. Easy Re-design
    24. 24. Automated Verification
    25. 25. Multi-tenancy? </li></ul>8<br />
    26. 26. Multi-tenancy<br />$<br />$<br />Separate application instances.<br />Separate infrastructure.<br />Separate application instances.<br />Shared infrastructure.<br />Shared application instance.<br />Shared infrastructure.<br />Multi-instance multi-tenancy<br />Single-instance multi-tenancy<br />9<br />
    27. 27. Scenario - revisited<br />10<br />Single shared code base <br />Cloud<br />Service Composition<br />
    28. 28. Scenario - revisited<br /><ul><li>Tenants have many overlapping requirements.
    29. 29. Ex:- All need roadside assistance which require managing activities such as Towing, Repairing etc.
    30. 30. Requirement are ‘similar’ but not the ‘same’.
    31. 31. Ex:- The way towing need to be carried out for CarSeller might ‘slightly’ different from the InsuranceCo.
    32. 32. Tenant requirements can change in the future.
    33. 33. Ex:- CarSeller might need Tow activity to be paused until a Taxi picks up the motorist.
    34. 34. Changes are made on a shared code base. Invalid boundary crossings?
    35. 35. Ex:- A change proposed by CarSeller can harm goals of InsuranceCo.</li></ul>11<br />
    36. 36. Challenges for SaaS vendor<br /><ul><li>Challenge 1 : Capturing commonalities
    37. 37. Tenants have many overlapping requirements.
    38. 38. Duplications need to be minimized.
    39. 39. Challenge 2 : Allowing variations
    40. 40. Requirements are similar but not the same.
    41. 41. Variations with minimal duplications.
    42. 42. Challenge 3: Avoiding invalid boundary crossings
    43. 43. Common application instance.
    44. 44. Many tenants and many collaborations. </li></ul>Unpredictability<br />12<br />
    45. 45. State of the Art <br /><ul><li>WS-BPEL – the front runner.
    46. 46. No explicit support for multi-tenancy.
    47. 47. Flexibility issues.
    48. 48. Improvements - Two major categories.
    49. 49. Template based approaches
    50. 50. Aspect oriented approaches
    51. 51. Still not good enough to address the challenges due to single-instance multi-tenancy.
    52. 52. Code duplications and maintainability issues.
    53. 53. Lack of support for unpredictability at runtime.</li></ul>13<br />
    54. 54. Our Contribution<br /><ul><li>We propose an ‘Organizational’ approach.
    55. 55. Uses SOA+BPM to model SaaS applications.
    56. 56. Multi-tenanted BPM
    57. 57. Equipped with specific features to employ BPM in multi-tenanted SaaS applications.
    58. 58. Addresses above mentioned challenges.
    59. 59. Contributions
    60. 60. An architecture to model multi-tenanted process-aware service-composites.
    61. 61. A flexible process modeling and execution language.</li></ul>14<br />
    62. 62. Approach - overview<br />15<br />How to model and maintain a single application instance?<br />Adaptable Organization<br />Service Composition<br />
    63. 63. Approach - overview<br />16<br /><ul><li>Three layers
    64. 64. Process/Packaging layer
    65. 65. Behavior layer
    66. 66. Structure layer</li></li></ul><li>Structure<br />17<br />
    67. 67. Structure<br /><ul><li>Abstraction for Stability.
    68. 68. Roles and Contracts among them.
    69. 69. Contracts: Represent role-role relationships. Mutual obligations and interactions.(Colman, 2007)</li></ul>18<br />
    70. 70. Behavior<br />19<br />
    71. 71. Behavior Modeling<br /><ul><li>A Behavior Term capture allowed behavior (collaboration) of the organization. E.g., Towing
    72. 72. An organization can have many such behavior terms.
    73. 73. E.g., Repairing, Complaining, Hotel booking
    74. 74. Define collaboration constraints.
    75. 75. Modifications to behavior terms are subjected to these constraints.
    76. 76. Re-usable, Declarative. </li></ul>Sample behaviour term, Towing<br />20<br />
    77. 77. Processes<br />21<br />
    78. 78. Process Modeling<br /><ul><li>A process definition is a collection of behavior terms.
    79. 79. Can dynamically include or exclude behavior terms
    80. 80. Capture process level constraints (to protect tenant goals)
    81. 81. A process view is dynamically constructed depending on grouped behavior terms.
    82. 82. Event-driven Process Chain (EPC) view</li></ul>22<br />
    83. 83. Dynamic Process Views (EPC)<br />23<br />
    84. 84. Challenge 1: Capturing Commonalities<br />24<br />Separate process views for each tenant<br /><ul><li>Overlapping requirements.
    85. 85. Solution: Behavior terms can be re-used / shared.
    86. 86. Code duplication is minimized.
    87. 87. Processes get automatically updated upon changes to behavior terms.</li></ul>A pool of behaviour terms defined in the organization<br />
    88. 88. Challenge 2: Allowing Variations <br /><ul><li>Requirements are similar but not the same.
    89. 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.
    90. 90. Use behavior specialization.
    91. 91. Specialize behavior Towing to create another (Towing2).
    92. 92. Only the additional properties are specified.
    93. 93. Towing2 inherits all the properties of Towing except thoseoverridden.</li></ul>25<br />
    94. 94. Challenge 2: Allowing Variations <br /><ul><li>Example 2: TravlCorequire an additional Task to be added to alert the motorist (MM) once the towing is complete.
    95. 95. Solution: Specialize behavior Towing to create Towing3.
    96. 96. Multiple variations of same behavior can co-exist in the organization.</li></ul>26<br />
    97. 97. Challenge 2: Allowing Variations <br />27<br />Originally<br />Example 1<br />Example 2<br />
    98. 98. Challenge 3: Avoiding Invalid Boundary Crossings<br /><ul><li>Changes are carried out in a common code base. Possible invalid boundary crossings.
    99. 99. Example: CarSeller request a modification to a behavior term shared with InsuranceCo.
    100. 100. How to identify the boundary for safe modification?
    101. 101. Solution: Two-tier scoped constraints. </li></ul>28<br />
    102. 102. Challenge 3: Avoiding Invalid Boundary Crossings<br />29<br />Change ?<br />Process constraints<br />Behaviour constraints<br />Links among behaviour terms and process definitions, provide the exact constraints need to be validated.<br />Better than global set of constraints. No unnecessary restrictions. (Kapuruge, SCC 2011)<br />Nothing less …! Nothing more …!<br />
    103. 103. Implementation<br />30<br />Web services<br />PetriNet and CTL <br />
    104. 104. Related Work and Evaluation <br />31<br /><ul><li>Code duplications and maintainability issues.
    105. 105. Lack of support for adaptability at runtime.</li></li></ul><li>Are we there?<br />32<br /><ul><li>Not yet !
    106. 106. We addressed ONLY THREE identified challenges.
    107. 107. Many challenges need to be addressed to achieve true multi-tenanted business processes.
    108. 108. Example: Better tooling support, scalability issues of the enactment engine, challenges in managing data-flow.
    109. 109. Future Work !!!</li></li></ul><li>References<br /><ul><li>(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. 110. (Colman, 2007): Colman, A.: Role-Oriented Adaptive Design (PhD Thesis). Swinburne University of Technology, Melbourne (2007)
    111. 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. 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)</li></ul>33<br />
    113. 113. Questions ?<br />34<br />

    ×