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.

1. WISE 2011 - Sydney Achieving Multi-tenanted Business Processes in SaaS Applications Presenter: Malinda Kapuruge Co-Authors: Prof. Jun Han and Dr. Alan Colman 1

3. SaaS

4. SOA and Business Process Modelling

5. Multi-tenancy

6. Challenges

7. State of the Art

8. Our Contribution and Approach

9. Addressing Challenges

10. Questions2

12. SaaSusers (tenants) rent the software.

13. SaaS vendor owns, hosts and maintain the software and infrastructure.3 Tenant Vendor Rent Owns, host and maintain Subscription fee Software (as a Service)

14. SaaS- Benefits for Tenants 4

15. SaaS - Benefits for Vendors 5

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 Agent Insurance Co. Car Seller Small and medium businesses SOA RoSaaS.com BPM SaaS Vendor Service Providers Tow trucks Case Officers Garages Paramedics Taxis 7

22. Automated Enactment

23. Easy Re-design

24. Automated Verification

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-tenancy Single-instance multi-tenancy 9

27. Scenario - revisited 10 Single shared code base Cloud Service Composition

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

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

43. Common application instance.

44. Many tenants and many collaborations. Unpredictability 12

46. No explicit support for multi-tenancy.

47. Flexibility issues.

48. Improvements - Two major categories.

49. Template based approaches

50. Aspect oriented approaches

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

55. Uses SOA+BPM to model SaaS applications.

56. Multi-tenanted BPM

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 - overview 15 How to model and maintain a single application instance? Adaptable Organization Service Composition

64. Process/Packaging layer

65. Behavior layer

68. Roles and Contracts among them.

69. Contracts: Represent role-role relationships. Mutual obligations and interactions.(Colman, 2007)18

70. Behavior 19

72. An organization can have many such behavior terms.

73. E.g., Repairing, Complaining, Hotel booking

74. Define collaboration constraints.

75. Modifications to behavior terms are subjected to these constraints.

76. Re-usable, Declarative. Sample behaviour term, Towing 20

77. Processes 21

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

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

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. Use behavior specialization.

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

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 27 Originally Example 1 Example 2

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 Crossings 29 Change ? Process constraints Behaviour constraints Links 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 …!

103. Implementation 30 Web services PetriNet and CTL

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.

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