Single JAR containing all Axis2 client side dependencies

A number of dependent JARs had to be added to the classpath in order to create & compile an Apache Axis2 client project. Now we have created a single JAR which contains the minimum set of dependencies. If you are using Maven, all you need to add is the following dependency.

       <dependency>
           <groupId>org.apache.axis2.wso2</groupId>
           <artifactId>axis2-client</artifactId>
           <version>1.6.0.wso2v1-SNAPSHOT</version>
       </dependency>

This JAR is only 5MB in size.

We have still not uploaded this JAR to the WSO2 Maven repository, hence you will need to build it yourself by checking out the axis2-client project from SVN https://svn.wso2.org/repos/wso2/trunk/carbon/orbit/axis2-client

Carbon 3.0 P2 Repository

$subject is located at http://dist.wso2.org/p2/carbon/releases/3.0.0/

The Book with no doubt in it!

الم ﴿1
ذَلِكَ الْكِتَابُ لاَ رَيْبَ فِيهِ هُدًى لِّلْمُتَّقِينَ ﴿2
this book, there is no doubt in it, is a guide to those who guard (against evil) 

الَّذِينَ يُؤْمِنُونَ بِالْغَيْبِ وَيُقِيمُونَ الصَّلاةَ وَمِمَّا رَزَقْنَاهُمْ يُنفِقُونَ ﴿3
those who believe in the unseen and keep up prayer and spend out of what we have given them 

والَّذِينَ يُؤْمِنُونَ بِمَا أُنزِلَ إِلَيْكَ وَمَا أُنزِلَ مِن قَبْلِكَ وَبِالآخِرَةِ هُمْ يُوقِنُونَ ﴿4
and who believe in that which has been revealed to you and that which was revealed before you and they are sure of the hereafter

أُوْلَئِكَ عَلَى هُدًى مِّن رَّبِّهِمْ وَأُوْلَئِكَ هُمُ الْمُفْلِحُونَ ﴿5
these are on a right course from their lord and these it is that shall be successful


http://quran.com
http://tanzil.info

An Architecture for Multitenant Enabling Apache Axis2

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.

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.

WSO2 Stratos - Deployment Architecture

WSO2 Stratos is a complete SOA and developer platform offered as a self-service, multitenant, elastic runtime for private and public cloud infrastructures. If you want more details on what Stratos is, read Paul's blog entry: WSO2 Stratos - Platform-as-a-Service for private and public cloud

As you can see in the above diagram WSO2 Stratos is a distributed system consisting of a number of services such as Stratos Governance, Stratos Identity, Stratos ESB, Stratos Application Server and so on. Each of these services is an elastic cluster, which means, the number of nodes in the cluster will increase or decrease based on the load on these clusters.

Let us take a look at a few important components of this system.

Stratos Manager
The main service, shown at the top, is known as the Stratos Manager. WSO2 Stratos Manager is the point of entry for all WSO2 Stratos Cloud Services. An organization (called a tenant in the Stratos world), will first be registered in the Manager. A tenant administrator account should be created at this point. For example, when I registered afkham.org, I created an administrator account with username admin, and email address admin@afkham.org. Once you create register your organization, you can login to WSO2 Stratos using the admin account. I provided my username as admin@afkham.org. The next step would be to take a look at the Stratos services enabled for your organization. You could enable of disable services. You may also want to create new roles with certain permissions & then create users for these different roles. There is also a bulk import feature which will allow you to import a large number of uses from a CSV file. You will also be able to create and apply a new theme for your organization. Some basic usage statistics are also available. The Stratos team is currently working on enhancing this metering, usage reporting & billing functionality.

Next you could visit the home pages of the different Stratos services. As of now, single-sign-on (SSO) is not available, so you will have to sign in to each service separately.

Stratos Governance - Governance as a Service
The Governance service will enable you to govern your middleware applications deployed on the cloud. This service is based on the WSO2 Governance Registry product, and has the same user interface & user experience. Each registered organization (tenant) has its own space in the Governance Registry & will be able to view & operate only within its allocated space.

Stratos Identity - Identity Management as a Service
Identity management in the cloud is provided by Stratos Identity, and is same as the WSO2 Identity Server product.

Stratos Application Server - AppServer as a Service
Stratos Application Server is multitenanted WSO2 WSAS running on the cloud. We have also added Web application deployment & management functionality in this version. Each organization will be able to deploy & manage their Web applications, Web services & Apache Axis2 modules using this service. These services can be governed by using the Stratos Governance service. For example, an organization may opt to centrally manage its service policies using the Stratos Governance service, and these policies can be applied across all services deployed on the Stratos Application Server.

Stratos Mashup Server - Mashups as a Service
This is multitenanted WSO2 Mashup Server running on the cloud. Organizations will be able to create, deploy & manage their mashups using this service.

Stratos Gadgets - Portal as a Service
This is multitenanted WSO2 Gadget Server on the cloud. Organizations will be able to create their own gadgets & portals & host them using this service.

Stratos Business Activity Monitor - BAM as a Service
This service allows you to monitor your entire cloud deployment. A graphical view of how your deployment is behaving can be seen using this service.

Stratos ESB - ESB as a Service
This is multitenanted WSO2 ESB on the cloud. This could be used for service mediation for services deployed in the cloud or services deployed within your organizational network. The Cloud Services Gateway component is deployed on the Stratos ESB. This components allows you to easily publish a service deployed within your organization to the cloud. In effect, a proxy service is created on the ESB, and requests received by this proxy are tunneled through the organizational firewall to the actual service. Activities such as governing these services, applying security and so on can be carried out in the cloud. We are currently working on making this service available, and updates should be available soon.

Stratos Data Services & Stratos Business Process Server should also be available in the near future.

Stratos has been designed in a cloud independent manner, so it could run on a private cloud as well. The public Stratos services at http://cloud.wso2.com have been hosted on Amazon EC2.