This document discusses the need for multi-tenant SOA middleware for cloud computing. It outlines the challenges of implementing multi-tenancy and describes WSO2's Carbon platform and its architecture for achieving tenant isolation at different layers. The architecture isolates tenants through separate security domains, a multi-tenant registry implementation, and tenant-specific Axis2 contexts. It also discusses scaling and monitoring open challenges.

1. Multi-Tenant SOA Middleware for Cloud Computing July 2010 Srinath Perera, Ph.D., Architect, WSO2 Inc.

3. Multi-tenancy

4. Challenges of Multi-tenancy

5. Carbon Platform

6. Multi-tenancy Architecture

7. Stratos

8. Conclusion

10. They want to buy IT aspects as a Utility (like water or electricity), making Niclous Carr's “IT does not matter” prediction a reality

11. Cloud Computing For end-users For developers, integrators, architects For infrastructure specialists

15. Implies you have a proper identity model What does Cloud a Native Platform Needs(1/2)?

20. Second Generation: VM per User

24. To Understand Multi-tenant SOA platform, you have to first understand Our SOA Platform

25. WSO2 Carbon Platform

26. WSO2 Carbon Platform

28. Let users run their single tenet apps (Services, Business processes, Web applications, Mediation logic, Rules etc. ) in this multi-tenant environment without any change.

30. Resource sharing and isolation are a tradeoff.

32. Multi-tenant-efficient: same instance hosts multiple tenants

33. configurable.

35. Admin view vs tenants views and programming model, maximum configuration without compromising isolation.

36. Scalability: multi-tenancy tend to accumulate load so it has to be scalable.

38. Security: ownership and authorization of both data, as well as executions in the framework

39. Data

40. Multi-tenancy Architecture

42. Each domain may have its own User Store and Permissions, thus have a s et of users and permissions enabling users to access resources

43. Each domain is isolated and do not have access to other domains

45. At Multi-tenant environments, system loads with multi-tenant implementation of the registry, which enforces isolation

47. Separate tables

48. Shared tables ** [We use this]

50. Axis2 have stateless executions and keep all state in a Context.

51. So if we create different context for each tenant, they are isolated.

52. Achieving Execution Isolation (Contd.)

53. Extending this to Products

55. BPS keeps all the data either in Context or in registry, and each tenet see a specific view.

56. Some products need some work, but in general they are implemented using registry for data and services for executions So the aforementioned model covers most usecases.

57. Performance

58. WSO2 Stratos

59. http://cloud.wso2.com

60. AppServer

62. Archival Formats that describe applications that uses different parts of the SOA (Services, BPEL, Workflows, Rules, CEP etc).

63. Bringing in discovery: WS-Discovery based deployment

64. Monitoring and Managing Stratos Deployment

65. Making Sessions work with Scalability Solutions

66. Tenant-aware JDBC driver

67. Supporting Hybrid Cloud Architectures, and on demand scaling out to Public Cloud.

68. Incremental deployment and versioning

70. We discussed how architecture handle three aspects, Security, data, and execution and how those three aspects can yield a Multi-tenet SOA platform

72. Developer portal: http://wso2.org

73. Business development team: [email_address]

74. [email_address]