Multi-Tenant SOA Middleware for Cloud Computing

1. Multi-Tenant SOA Middleware for Cloud Computing Afkham Azeez, Srinath Perera, Dimuthu Gamage, Ruwan Linton, Prabath Siriwardana, Dimuthu Leelaratne, Sanjiva Weerawarana, Paul Fremantle WSO2 Inc. Mountain View, CA, USA 报告人：陈大鹏

2. INTRODUCTION • Cloud computing：inadequate to provide major cost savings across the IT infrastructure life-cycle • User’s wish is to outsource their complete IT infrastructure as a service, whereas cloud computing only provides much lower levels of virtualization. • Solution：SaaS • SaaS has not realized outsourcing Service Oriented Architecture artifacts • Solution：PaaS • The next level of PaaS：virtualization, elasticity and multi-tenancy • Future：virtualize the middleware servers that are running the SOA artifacts

3. INTRODUCTION • There have been many efforts to build multi-tenant frameworks, and most efforts have been focused on providing data multi-tenancy • This paper presents an architecture that enables multi-tenancy at the SOA platform level, which enable users to run SOA artifacts in a multi-tenant SOA framework. This framework becomes a platform for building multi-tenant SaaS applications

4. RELATED WORK • Data multi-tenancy： • three main approaches for data management：separate databases, shared database with separate schemas and shared database with shared schemas • a maturity model of multi-tenant applications(4 levels) level 1 an instance per tenant level 2 a configurable instance per tenant level 3 single instance serves customers level 4 enables level 3 to scale up by running multiple instances and load balancing to scale it up • Our proposed solution falls under multi-user single instance.

5. MULTI-TENANCY IN SOA high level multi-tenancy architecture

6. MULTI-TENANCY IN SOA • Services are groupedunder Execution, Security, and Data. • Execution involves developing, deploying and running services, and composing those services together to create higher level artifacts • Security services define the ownership and authorization of both data as well as executions in the framework. • providing an isolated space per tenant/users in the SOA framework is a challenging problem. • Tenants’ two level of access control

7. PROPOSED ARCHITECTURE • The proposed solution is implemented on top of the WSO2 Carbon platform • We discuss different aspects of the system architecture • WSO2 Carbon platform • Service deployment • Message dispatching • Security • Service execution • Data access

8. WSO2 Carbon Platform • The WSO2 Carbon platform consists of a full suite of products: • WSO2 Application Server for service hosting (Web Apps, JAX-WS, Axis2, Spring) • WSO2 Enterprise Service Bus for mediation services (and SAP, FIX, HL7, Salesforce.com adapters) • WSO2 Message Broker for messaging services (AMQP, JMS, Amazon SQS, WS-Eventing) WSO2 Data Services Server for managing data sources and data access (NoSQL, RDBMS, Flat file, CVS, MS-Excel, Google Docs) • WSO2 Identity Server for authentication, single sign-on and access control (SAML 2.0, OpenID, OAuth, XACML, WS-Security) • WSO2 Governance Registry and repository for managing WSDL, schemas, policies, life cycles and versioning • WSO2 Business Process Server(BPEL), WSO2 Business Rules Server (JSR-94), WSO2 Complex Event Processing Server, WSO2 Business Activity Monitor (JMX) and WSO2 Mashup Server for composing, orchestrating and monitoring business processes and activities. • WSO2 Gadget Server for portal services • WSO2 Web Services Frameworks for C, C++ and PHP – provide simple APIs for implementing web services and web service clients

9. WSO2 Carbon Platform • WSO2 Carbon is a Java based platform, a open source componentized middleware framework for building servers • The servers consist of components which fit into the framework • The serversdepend on the services provided by the framework • The servers offer a Web services API for management • The servers offer components which fit into the Carbon administration console to interact with the services and manage themselves • The component model used by WSO2 Carbon is OSGi

10. WSO2 Carbon Platform • The platform consists of three components: the WSO2 Carbon core, the management console, components that execute within the framework. • The WSO2 Carbon core is the main engine of WSO2 Carbon and manages the loading, linking, execution and management of WSO2 Carbon Components. • The WSO2 Carbon core offers a set of services for components executing in it

11. WSO2 Carbon Platform • authentication and authorization management for administrative services of the components • authentication and authorization for services offered by the component, including full user management and role based authorization • shared repository to store state on a per-server basis • shared repository to store cluster-wide configuration state • shared registry to store system governance information and to look up data and metadata for runtime governance • services to share runtime data across nodes in a cluster • UI framework for writing UI components to give a human interface to the administrative services of components

12. WSO2 Carbon Platform • WSO2 Carbon components are OSGi bundles • Components can be grouped into the concept of “features” • WSO2 Carbon based server is basically a collection of features that have been preconfigured to start at the same time • Features can be brought into the server and removed from the server dynamically • This enables a server to customize its personality dynamically to exactly match the environment needed to run a specific function

13. WSO2 Carbon Platform • Management Console: a componentized Web application built using the WSO2 Carbon core and uses OSGi to manage its components. • Console UI framework provides a template UI, the UI defines how a specific UI component for some feature may integrate with the overall UI • When a WSO2 Carbon management console is pointed to a running WSO2 Carbon server, it detects the features installed in the server and loading and running only the corresponding UI features in the management console

14. WSO2 Carbon Platform • Products: A product is implemented by composing different features as needed to achieve the desired functionality of the product. • One could start with a bare WSO2 Carbon runtime and keep installing components to form a custom runtime as well.

15. Service Deployment • all service hosting components of WSO2 Carbon have Apache Axis2 as its underlying execution engine • Axis2 is a totally stateless system • AxisConfiguration, a configuration tree with all configuration state stored in it, and all configuration elements such as services created within it • ConfigurationContext, another tree with all runtime state stored in • An Axis2 multi-tenant deployment is to have multiple AxisConfiguration instances, one per tenant. • There is a master AxisConfiguration which will be responsible for dispatching requests to tenant AxisConfigurations and provides the management infrastructure for managing tenants

16. Message Dispatching • When messages arrive into a multi-tenant WSO2 Carbon server, they always first arrive at the handlers and dispatchers defined by the master configuration which implement any cross-tenant policies and SLA (service level agreement) management. • When a client sends a message addressed to a particular tenant’s service, that request must indicate the tenant in some manner • Two approaches: Tenant name added to the URL http://example.com/t/tenant-name/services/service-name or configure a CNAME record in DNS • Once the tenant is identified, WSO2 Carbon will dispatch that message to the relevant tenant’s AxisConfiguration object.

17. Security • User Management: User manager uses permissions to compute the authority of a user to perform an action on a particular resource. • Permissions are tuples (role, resource, action) • Permissions are also mapped to a registry resource • Each component defines a permission set that restricts users from accessing their features • WSO2 Carbon stores users and the resources along with the permissions separately per tenant • WSO2 Carbon platform allows a tenant to have its own set of users, each user has the own store

18. Security • Authentication and Authorization: When messages arrive at the tenant-specific AxisConfiguration, the security handlers deployed there will invoke the user manager of that tenant to provide user verification and authorization. • The tenant specific authorization manager will calculate the authority of users and resources of the tenants. • Super-tenant Authorization: The user manager authorizes the actions that should only be accessible to super adminstrators.

19. Service Execution • Per-tenant service execution within a single JVM • a primary requirement: Total isolation of the deployments • each tenant is provided with their own customized management infrastructure & management console • The tenants will not be able to see any services or code deployed by other tenants although services with the name • http://example.com/t/foo.com/services/MyService • http://example.com/t/bar.com/services/MyService • URLs are unique

20. Service Execution • Isolation is achieved via several levels of protection. • At the lowest level, OSGi uses a multi-level class loader structure, code running in one service will have no way to access any code from another tenant • At the next level, it is necessary to protect OSGi services within the JVM • The OSGi runtime has a service directory which can be accessed by arbitrary Java code to discover other services and interact with them • any service which is not deployed as a native OSGi bundle is prevented from accessing any OSGi services by the Java Security Manager

21. Service Execution • For non-OSGi bundles, A custom Java Security Manager is used to give a sandboxed execution environment, so that any access to certain sections of the registry is controlled

22. Data Access • The WSO2 Carbon framework provides a registry/repository that abstracts out the relational database layer while supporting a simpler resource oriented API to store and retrieve persistent data • The registry implements tenant-wise data separation logic inside itself to provide a multi-tenant aware registry interface to higher layers • e.g. The registry API is designed to access resources using a path string as a key. • registry.put(path, resource) //store a resource • resource = registry.get(path) //retrieve a resource

23. Data Access • The tenant information is retrieved from the runtime context and used to qualify all data accesses from the database • The resources persisted in the registry can be accessible via URIs, • In the multi-tenant registry, the URI associated with a resource will contain the tenant name to avoid the resource name conflicts among tenants. • e.g. a resource of tenant-A with the path “/example/path” • https://host/t/tenant-A/registry/resource/example/path

24. Data Access • There are 3 methods to develop a multi-tenant registry on top of a relational database. They are using a separate database, separate tables, and shared tables. • WSO2 Carbon uses the third approach because the best utilization of resources and the little short of availability

25. PERFORMANCE EVALUATION • some experiments conducted to measure the impact of multi-tenancy on overall system performance • Experiment: a simple Stock Quote service, which returns a randomly generated stock quote • This service is deployed onto multi-tenanted and non-multi-tenanted versions of WSO2 Web Services Application Server • servers are then loaded using parallel clients and message latency and throughput were measured • Intel(R) Core Duo 2.4 GHz • 8GB memory running Ubuntu Linux

26. PERFORMANCE EVALUATION

27. DISCUSSION • Challenges： • Elastic adjustment in the presence of session-oriented interactions is difficult • Provide direct database access in a tenant-safe manner • How to scale up to global scales