MultiTenant SOA Middleware for Cloud Computing Afkham Azeez

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

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：Saa. S • Saa. S has not realized outsourcing Service Oriented Architecture artifacts • Solution：Paa. S • The next level of Paa. S：virtualization, elasticity and multi-tenancy • Future：virtualize the middleware servers that are running the SOA artifacts

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 multitenancy 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 Saa. S applications

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.

MULTI-TENANCY IN SOA high level multi-tenancy architecture

MULTI-TENANCY IN SOA • Services are grouped under 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

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

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

WSO 2 Carbon Platform • WSO 2 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 servers depend 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 WSO 2 Carbon is OSGi

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

WSO 2 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

WSO 2 Carbon Platform • WSO 2 Carbon components are OSGi bundles • Components can be grouped into the concept of “features” • WSO 2 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

WSO 2 Carbon Platform • Management Console: a componentized Web application built using the WSO 2 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 WSO 2 Carbon management console is pointed to a running WSO 2 Carbon server, it detects the features installed in the server and loading and running only the corresponding UI features in the management console

WSO 2 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 WSO 2 Carbon runtime and keep installing components to form a custom runtime as well.

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

Message Dispatching • When messages arrive into a multi-tenant WSO 2 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, WSO 2 Carbon will dispatch that message to the relevant tenant’s Axis. Configuration object.

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 • WSO 2 Carbon stores users and the resources along with the permissions separately per tenant • WSO 2 Carbon platform allows a tenant to have its own set of users, each user has the own store

Security • Authentication and Authorization: When messages arrive at the tenant-specific Axis. Configuration, 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.

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/My. Service • http: //example. com/t/bar. com/services/My. Service • URLs are unique

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

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

Data Access • The WSO 2 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) • resource = registry. get(path) //store a resource //retrieve a resource

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

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. • WSO 2 Carbon uses the third approach because the best utilization of resources and the little short of availability

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 nonmulti-tenanted versions of WSO 2 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 • 8 GB memory running Ubuntu Linux

PERFORMANCE EVALUATION

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