WSO2 Stratos supports multitenanted (MT) application deployment. Web applications, Web services, ESB mediators & mashups can be deployed in a multitenant fashion. One of the most important aspects of an MT deployment is isolation. There should be isolation between the applications hosted by the different tenants, as well as isolation between the tenant code & system code.
WSO2 Stratos is based on the WSO2 Carbon platform. Apache Axis2 sits at the center of Carbon. We use several aspects of Axis2 in Carbon; deployment, messaging, transport & tooling. During the rest of this post we will be looking at how we adopted Axis2 to support multitenanted deployment, messaging & transport.
Deployment
The system, which can also be called the super tenant, has its own AxisConfiguration (AC) & ConfigurationContext (CC). This AC & CC form the base. Each tenant also has its own AC & CC. A tenant can operate only within the boundaries of its AC & CC. The multiple AxisConfigurations are shown in the above figure. For example, two tenants, ibm.com & microsoft.com can deploy the same service archive StockQuoteService.aar within their deployment spaces. There is total isolation. IBM's StockQuoteService WSDL will be available at http://appserver.cloud.wso2.com/services/t/ibm.com/SimpleStockQuoteService?wsdl while Microsoft's StockQuoteService WSDL will be available at http://appserver.cloud.wso2.com/services/t/microsoft.com/SimpleStockQuoteService?wsdl . As you will be able to see from the WSDLs, the service EPRs will have the organization (tenant) domain names in the URLs.
When it comes to managing these deployment, each tenant will again operate within the boundaries of its AC & CC. Hence, when a user from IBM logs in, he will be able to see artifacts deployed under the ibm.com AC only. In order to ensure that tenant code cannot call sensitive server side functionality, we have made use of Java Security, ensuring that code signed only by WSO2 can call the restricted functionality. The AxisConfiguration as well as HTTP sessions provided to each tenant also contains some security restrictions which do not allow tenants to overwrite certain critical parameters & the tenant Axis2 repository.
WSO2 Carbon provides a number of Admin services which have special privileges to manage the server. These admin services are deployed only within the main super AxisConfiguration. However, different tenants can make use of these admin services to manage their deployment. We have ensured that these admin services operate only on the AxisConfiguration of the logged in tenant.
A tenant is free to do almost whatever it wishes within its AC. For example, tenants can deploy modules and engage handlers to handle the messages differently, they could apply security, request throttling, response caching and so on.
A tenant is free to do almost whatever it wishes within its AC. For example, tenants can deploy modules and engage handlers to handle the messages differently, they could apply security, request throttling, response caching and so on.
Messaging & Transport
One of the restrictions we have imposed on tenants is that they cannot create their own transports but will have to share the transports provided by the system. So, all incoming requests will be first received by the system transports. Let us take a Web service request as an example. Say, a client of IBM makes a request to the SimpleStockQuoteService hosted by ibm.com on the Stratos Application Server. The tenant's target EPR or addressing TO header may look like, http://appserver.cloud.wso2.com/services/t/ibm.com/SimpleStockQuoteService.SimpleStockQuoteServiceHttpSoap11Endpoint/. This request will be injected into the main AxisEngine and will go through its in flow. In the DispatchPhase, since the service will not be found, a MultitenantDispatch handler will dispatch this request to a dummy _MultitenantService. The MultitenantMessageReceiver (MTMR) is associated with this service. The MTMR will infer the target tenant from the incoming request, and if an existing tenant is found, it will inject the request into the respective tenant's AxisEngine. Now the message will go through the in flow of the respective tenant's AC, and will eventually get dispatched to the correct service in tenant's AC. If there is a response, it will go through the tenant's out flow, and will finally reach the TenantTransportSender, which will inject the message into the out flow of the super tenant. The response will go through the out flow of the super tenant & will be sent to the client. If a fault occurs, there will be a fault response which goes through the tenant's out fault flow, and then through the super tenant's out fault flow, and reach the client.
In order to generate the proper addressing information for the tenant services, the relevant transports should be associated with those services, and the transport descriptions should be there in the relevant ACs. However, we mentioned that we do not allow tenants to define their own transports. Therefore, we created dummy transports corresponding to the actual tenant transports, and set the EPRs accordingly. This is how the proper EPRs are injected into the service WSDLs.
In order to generate the proper addressing information for the tenant services, the relevant transports should be associated with those services, and the transport descriptions should be there in the relevant ACs. However, we mentioned that we do not allow tenants to define their own transports. Therefore, we created dummy transports corresponding to the actual tenant transports, and set the EPRs accordingly. This is how the proper EPRs are injected into the service WSDLs.
0 comments:
Post a Comment