Are you stuck in the old age with your legacy SOAP service?

Owner of some legacy services?

If your company started its IT department about a decade or so ago, adopted SOA etc. then you should be the owner of some legacy SOAP backend services which you are not proud of anymore. You may not have the guts or the blessings from your leadership to redo them matching the current trends in IT world. It can be due to the risk of redoing them completely and the cost too.

While you are stuck with it, you might be getting frequent requests asking for a more web friendly set of services. If you want to reach to more customers, let application developers innovate etc. its difficult to do so with your legacy services.

What options do you have to get beyond this hurdle?

I would list down following as your requirements.

1. Expose your legacy service as a RESTful API
2. Make it a managed API such that you can control who consumes it and how they consume it.

Answer is an API management solution. Which one should you turn to? There are many API management products and services available in the world today. I am recommending WSO2 API Cloud and WSO2 API Manager (on-premise version) for this.

How can WSO2 API Cloud solve your problems?

1. API Cloud is capable of exposing your SOAP service as a RESTful API. It can accept a JSON payload, convert it to a SOAP payload, send it to your SOAP backend, get the SOAP response, convert it to a JSON response and send back to the client. This is what your clients are asking for, isn't it?
2. It allows you to control the access to the SOAP backend via the managed API
1. It authorizes the access via Oauth tokens
2. It can also throttle the traffic to your backend to protect it from unbearable load. If its a legacy backend it will surely have limitations on the load it can handle.
3. Its powerful mediation engine can be used to selectively expose certain operations only to your clients
4. Even if you decide to expose all the operations, you can selectively give access to different clients via the scopes.
3. You can also get un understanding on the usage of your service via the stats available
4. You can do all these within hours, which gives a greater agility to your digital enterprise.
5. You can monetize your backend service to earn money too.

I strongly recommend the below article to get started on exposing your legacy service as a managed API. It gives you details step-by-step instructions to expose your SOAP service and create you first API.
https://medium.com/@shenavi21/exposing-a-soap-service-as-a-managed-rest-api-288676e06418

If you have any questions you can contact the WSO2 Cloud team via cloud@wso2.com

Following documentation links will also help.
https://docs.wso2.com/display/APICloud/Publish+and+Invoke+a+SOAP+API
https://docs.wso2.com/display/APICloud/Convert+a+JSON+Message+to+SOAP+and+SOAP+to+JSON

Make a fortune of WSO2 API Cloud

For those who do not know about WSO2 API Cloud:

WSO2 API Cloud is the API management solution in cloud, hosted by WSO2. In other words, this solution is WSO2's API Manager product as a service. You can try it for free after reading this post.

What you can do with it:

Of course, what you can do is, manage your APIs. i.e. If you have a REST or a SOAP service, which you want to expose as a properly authenticated/authorized service, you can create an API in WSO2 API Cloud and proxy the requests to your back end service with proper authentication/authorization. There are many other features which you can read from here.

HOW and WHO can make a fortune of it:

There are many entities who can make a fortune out of API Cloud. But, in this post, I am purely concentrating on the system integrators. They undertake projects to combine multiple components to achieve some objective. These components might involve databases, services, apis, web UIs etc.

Now, lets pay attention to publishing a managed api to expose an existing service to be used in the above mentioned solution. We all know, no one will write api management solution from scratch to achieve this when there are api management solutions available. If a SI, decides to go ahead with WSO2 API Cloud, they

1. Can create, publish and test the apis within hours. If their scenario is complex, it might take a day or two if they know what they are doing and with some help from WSO2 Cloud team.

2. Don't need to worry about hosting the api, availability and its scalability.

3. Can subscribe for a paid plan starting from 100 USD per month. See the pricing details.

Now, lets say the SI decided to go ahead with API Cloud and subscribed to a paid plan which costs 100 USD per month. If the SI charges 10,000 USD for this solution, you can see the profit margin. You pay very less and you get a great api management solution in return. If the SI do couple of such projects, they can make a fortune of it :)
  

Tomcat returns 400 for requests with long headers

We noticed this while troubleshooting an issue which popped up in WSO2 Cloud. We have configured SSO for the API Publisher and Store at WSO2 Identity Server. SSO was working fine except for one scenario. We checked the SSO configuration and couldn't find anything wrong.

Then we checked the load balancer logs. It revealed that LB was passing the request to the server i.e. Identity server, but gets a 400 from it. Then we looked the Identity Server logs to find nothing printed there. But, there were logs in the access log of the identity server which told us it was getting the request, but it was not letting it go through. Instead it was dropping it saying it was a bad request and was returning a 400 response.

We did some search in the internet and found out this kind of rejection can occur if the header values are too long. In the SAML SSO scenario, there is a referrer header which sends a lengthy value which was about 4000 characters long. When doing further search, we found out the property maxHttpHeaderSize in tomcat configs where we can configure the max http header size allowed in bytes. You can read about this config from here.

Once we increased that value, everything started working fine. So, I thought of blogging this down for the benefit of people using tomcat and also WSO2 products since WSO2 products have tomcat embedded in it. 

Why you should try WSO2 App Cloud - Part 1

I have written a blog post on how to get started with WSO2 App Cloud couple of months ago and it can be found at Lets get started with WSO2 App Cloud. My intention of writing this post is to explain why you should try it. I'll be listing the attractive features of WSO2 App Cloud which makes it special from other app cloud offerings available.

1. Onboarding process
2. Creating your first application
3. Launching your first application
4. Editing and re-launching the application

Onboarding process

WSO2 App Cloud allows you to sign-up by providing your email address. Then you get an email with a link to click and confirm your account. Once you click it, as the next step, you are asked to provide an organisation name which you want to create.

WSO2 App Cloud Sign-Up page

WSO2 App Cloud has an organization concept which allows a set of developers, QA engineers, DevOps persons to work collaboratively. When you create an account in WSO2 App Cloud, it creates an organisation for you. In other words, this is a tenant. Then you can invite other members to this organisation. You can assign members to different applications developed under this organisation entity. I'll explain this structure in a future post (to keep you reading through this :))

Some of the other app clouds available today do not have the organisation concept. They only have the application entity. You sign-up and create an application. Then you are the owner of that app. You can invite others to collaborate with your app. But, if you create another app, you need to invite them again for collaboration.

Creating your first application

After you sign-up and sign-in successfully, lets have a look at the first app creation experience. WSO2 App Cloud support multiple application types to be created. They are,

• Java web applications
• Jaggery web applications (Jaggery is a Javascript framework introduced by WSO2 itself)
• JAX-WS services
• JAX-RS services
• WSO2 Data Services
• It also allows you to upload existing Java web apps, JAX-WS, JAX-RS and Jaggery apps

WSO2 App Cloud is planning to support other app types such as PHP, node.js in the future.

In WSO2 App Cloud, creating an application is a two click process. After you login in, you click on "Add New Application" button, fill in the information and click "Create Application" button. This will create the skeleton of the app, a git repository for it, build space for the app. Then it will build the app and deploy it for you. All you have to do is, wait a couple of minutes, go to the app's overview page and click the "Open" button to launch your app. This has the following advantages.

1. You don't need to know anything about the folder structure of the app type you are creating. WSO2 App Cloud does it for you.
2. Within a couple of minutes, you have an up and running application. This is same for new users and users who are familiar with the WSO2 App Cloud.

See this video on WSO2 App Cloud's app creation experience.

Other offerings have different approaches when creating applications. Some of them needs users to download SDKs. Users also need to have knowledge about the structure of an app which they want to create. After a user creates and uploads/pushes an app, they have to start up instances to run it. Some offerings provide a default instance, but if you want high availability for your app, user has to start additional instances. WSO2 App Cloud takes care of them by default, so the user does not need to worry about it.

Launching your first application

Lets see how a user can launch the application they have created.

When you create the app in WSO2 App Cloud, after it goes through the build process, it is automatically deployed. Within seconds of creation, it presents you the URL to launch your app. A user with very little knowledge can get an app created and running easily.

Editing and re-launching the application

Its obvious that a user wants to edit the application he/she creates by adding their code.WSO2 App Cloud dominates the app cloud offerings when it comes to development support. It provides you a cloud IDE. You can just click the "Edit Code" button and your app code will be open in the browser. Not only you can edit the code in the browser, you can build and run it before pushing the code to the App Cloud. Very cool, isn't it?

Second option is to edit the code using WSO2 Developer Studio. To do this, you need to have a working installation of WSO2 Developer Studio.

Third option is to clone the source code and edit it using your favourite IDE. 

WSO2 App Cloud IDE

See this video on WSO2 App Cloud's cloud IDE.

Special thing to note is, there is no other app cloud offering which provides a cloud IDE for the developers.

I'll be writing the second part of this post by discussing some more attractive features of WSO2 App Cloud and I am expecting to discuss

• Using resources within the app (databases etc.)
• Collaborative development
• Lifecycle management of the app
• Monitoring logs

Your feedback is welcome. Stay tuned :) 

Lets get started with WSO2 API Cloud

Few weeks ago, I wrote a blog post on "Getting started with WSO2 App Cloud". Intention of writing it was to line up some of the screencasts we have done and published which helps you to use the WSO2 App Cloud.

Couple of weeks after we started publishing App Cloud videos, we started publishing API Cloud videos too. Intention of this blog post is to introduce those screencasts we have added.

WSO2 API Cloud provides you the API Management service in the cloud. You can create and publish APIs very easily using it and it is powered by the well established product of WSO2 product stack, WSO2 API Manager. If you already have an account in WSO2 Cloud or wso2.com, you can login to WSO2 Cloud and navigate to the API Cloud.

First thing you would do, when you go to the API Cloud is, creating and publishing an API. Following screencast will help you on how to do it.

After publishing your API, it appears in your API store. If you advertise your API store to others they can subscribe to the APIs and invoke them. Next screencast shows how to that.

You may have a very promising API created and published, now available in your API store. But, for it to be successful, you need to spread the word. To do that, WSO2 API Cloud have some useful social and feedback channels. You can allow the users to rate your API, comment on them, share using social media and also start interactive discussions via the forums. Following tutorial showcases those capabilities.

For a developer to use your API easily, its documentation is important. Therefore, WSO2 API Cloud allows you to add documentation for your API. There are several options such as inline documentations, uploading already available docs and pointing to online available docs. This video showcases the documentation features.

We will keep adding more screencasts/tutorials to our API Cloud playlist. Stay tuned and enjoy experiencing the power of WSO2 API Cloud.

Lets get started with WSO2 App Cloud

We at WSO2 Cloud team are working on improving the experience we are providing to the WSO2 Cloud users. During this effort, we try to provide clear instructions on using the various features available. Since we have two cloud services offered to the users, I'll be talking about the WSO2 App Cloud in this blog post.

As the first step, we published a set of tutorials with step-by-step instructions on how to do things in the WSO2 App Cloud. This included

• Creating an application from scratch
• Uploading an existing application
• Editing your app with the Cloud IDE
• Creating and using databases
• Invoking APIs from your app code etc.

You can find those tutorials at https://docs.wso2.com/display/AppCloud/Tutorials.

As the next step, we started working on a series of screencasts which shows you how to use different features in the WSO2 App Cloud. These screencasts go parallel with the above mentioned tutorials. We have published them in YouTube and also linked from the tutorials too.  So, you can use both of them to make your life easier. At the moment we have released four screencasts and we are in the process of releasing more. I'll list them here for your reference.

• Create and deploy your first Java application to WSO2 App Cloud

• Edit your app using the Cloud IDE

• Edit your app using your favourite IDE

• Upload your WAR file to WSO2 App Cloud

When you start using WSO2 App Cloud, go through the tutorials and these screencasts. If you face any problems, feel free to contact the WSO2 Cloud team via cloud@wso2.com. We would like to hear your feedback and improve the experience we provide.

WSO2 Cloud - New kid in town

WSO2 has been performing in the cloud for quite sometime now. StratosLive was its first public cloud offering which was operational from 2010 Q4 to 2014 Q2. We had to shutdown StratosLive after we donated Stratos code to Apache (due to trademarks etc.). Now Apache Stratos is a top level project (graduated) after spending nearly one year in incubating.

We at WSO2 were feeling the requirement of a cloud which is more user friendly and more use case oriented. To be honest, although StratosLive had all WSO2 middleware products hosted in the cloud, a user needed to put some effort to get a use case completed using it. It was decided to build a new application cloud (app cloud) and an API cloud using the WSO2 middleware stack. App Cloud was going to be powered by WSO2 AppFactory and API Cloud by WSO2 API Manager. The complete solution was decided to be named as "WSO2 Cloud".

We hosted a preview version of WSO2 Cloud as WSO2 CloudPreview in October 2013. Since then we were working on identifying bugs, usability and stability issues, etc. and fixing them. This June, we announced WSO2 Cloud beta. It was announced in WSO2 Con - Europe 2014 in Barcelona.

WSO2 Cloud - https://cloud.wso2.com

You can go to WSO2 Cloud via the above link. If you have an account in wso2.com (aka WSO2 Oxygen Tank) you do not need to register, you can sign in with that account. If you don't, you can register by simply providing your email address.

Once you are signed in, you will be presented with the two clouds, App Cloud and API Cloud.

   

WSO2 App Cloud

• Create applications from scratch - JSP, Jaggery, JAX-WS, JAX-RS
• Upload existing web applications - JSP, Jaggery
• Database provisioning for your apps
• Life cycle management for your app - Dev, Test and Prod environments
• Team work - A team can collaboratively work on the app
• Issue tracking tool
• A Git repository per each application and a build tool.
• Cloud IDE - For your app development work
•  And more...

WSO2 API Cloud

• Create APIs and publish to API store (a store per tenant)
• Subscribe to APIs in the API store
• Tier management
• Throttling
• Statistics
• Documentations for APIs

Above mentioned are some of the major features of WSO2 App Cloud and API Cloud. I'll be writing more posts targeting specific features and hope to bring some screen casts for you.

Experience WSO2 Cloud and let us know your feedback..

WSO2 ESB answers the critics on its performance test results

Few months ago, big fuss was made via a performance blog saying that some of the performance stats published on WSO2 ESB are incorrect and flawed. WSO2 ESB team has carried out some investigations on these and published the latest performance test results based on their latest release WSO2 ESB 4.8.1.

You can find the official article at http://wso2.com/library/articles/2014/02/esb-performance-round-7.5/

There is an interesting blog post which explains why were the accusations made in the aforementioned performance blog post are incorrect and unfair. You can find it at https://shafreenanfar.blogspot.com/2014/02/esb-performance-round-75-other-side-of.html

If you are too curious, following is the latest performance graph. Believe me, its worth reading the above two posts.

Oh.. I forgot to say, WSO2 ESB is the fastest open source ESB on earth :)

How to send Basic Auth information when invoking a web service with SoapUI

I recently wanted to invoke a web service via SoapUI, which was expecting basic auth credentials. There are two options.

1. When you open a request generated by SoapUI, at the bottom you will find two tabs named Auth and Headers. When you click on the Headers tab, it will open a small window which allows you to add any headers to the message. There you can add a header name "Authorization" and its values should be "Basic <Base64 encoded username:password>".

If your username and password are admin:admin, then when you encode it, your header values will look like "Basic YWRtaW46YWRtaW4="

After setting this, if you send a request in SoapUI, you will be able to see the Authorization header in the request.

2. Other option is to use the Auth tab and define the username and password there. But, these information will not get sent as a header. To send them as a header, you need to do the following.

Open the "Preferences" window by clicking the icon or from the SoapUI menu. Then select "HTTP settings". From that settings list check (tick) the "Authenticate Preemptively" option as shown in the image below.

Then, set the username and password in the Auth tab as I described previously and send a request. You will see the Authorization header sent with the request as shown below.

I learned this from Charitha Kankanmge of WSO2 and thought of writing it down for others benefit.

PublishWSDL option in WSO2 ESB explained...

If you are wondering what is the PublishWSDL option of WSO2 ESB, you can have a look at how to create proxy services in WSO2 ESB.

Lets say you are going to expose a web service by creating a proxy service. If you do not publish the WSDL of the web service you are exposing, then if you take the WSDL of the created proxy, it will only show the "mediate" operation. If a client wants to invoke the backend service via the proxy service, it needs to know the expected message format by the web service (parameters, their names etc.).

But, if you decide to publish the WSDL of the web service, then the WSDL of the proxy service will show all the operations which are available in the web service. This makes life easier to the client.
But publishing WSDL also exposes all the operations of the web service. What if you want to expose only a few operation to the clients? In that case, you can publish a WSDL with only the operations which you want to expose.

There is another advantage. Lets say the backend service operation expects three parameters to be sent (lets assume these are name,department and a permission level). We want the client to send only the name and department and we are planning to add the permission level to the request within the proxy service. In such a scenario, we can publish a modified WSDL which is expecting only the name and the department and inject the permission level within the proxy service.

Above are the use cases of PublishWSDL option available in WSO2 ESB. Although this is a simple thing, I couldn't find a place which explains this. So, hope this helps somebody.

Thanks Kasun Indrasiri of WSO2 for explaining this to me... :)

Unix timestamp vs Java timestamp

A recent incident which occurred to me and a colleague of mine made me write this little post. We were setting a property in a hive script and was trying to retrieve some data comparing with the value we set. In other words, this is what we did.

1. We set a property named max_ts to hive context within a Java class. We used the Timestamp.getTime() method to get the time.
2. In the hive script, we were doing something like:
1. Select my_columns from my_table where unix_timestamp(a_string) > ${hiveconf:max_ts}

 But this was not seem to be working. Even when we had records which has a timestamp greater than the max_ts, query was not returning them. Then we added some debug logs and realized what was going wrong.

Unix timestamp gives the number of seconds which has passed since the epoch.
Java timestamp gives the number of milliseconds since the epoch.

Although both of these uses the same epoch (midnight of January 1st 1970), they provide two different values. Thats why the query was not behaving as intended. Although I had read/learned about this difference, it took some time to kick it into the mind.
  

Now you can send the SoapFaults to the Fault Sequence in WSO2 ESB

WSO2 ESB 4.5.0 was released recently. There are many new features, enhancements and performance gains in this new release. I wanted to highlight one new cool feature which I couldn't wait anymore. That is the title of this post.

In the previous releases of WSO2 ESB fault sequence was hit only when there was a fault during the mediation process taking place inside the WSO2 ESB. If a soap fault was received from a backend service it was sent to the out sequence because the WSO2 ESB considered it as a response from the backend. It was fair from ESB's point of view and unfair from developer's point of view. But with the 4.5.0 release, now you can send the soap faults to the fault sequence and do the fault handling.

To do that, you need to set the FORCE_ERROR_ON_SOAP_FAULT property before you send the message to the backend. This is a newly introduced property and following sample proxy service will show you how to do it.

Hope this property will help many integration developers during their use of WSO2 ESB.

NOTE

Above proxy configuration was taken from a resource which was emailed to me by Kasun Indrasiri who is an ESB expert in WSO2.

Happy Integration.... :)

Getting ActiveMQ Redelivery to work with WSO2 ESB

Recently I wanted to use the redelivery mechanism available in Apache ActiveMQ while using it with WSO2 ESB. My scenario was like this.

1. Retrieve a message from a JMS queue
2. Write the message to a file URI (in your case you may want to send it to a given endpoint)
3. If writing to the file is not successful due to some failure, I wanted the message to be in the queue and ActiveMQ to try repeatedly writing to the file.

Following are the properties/parameters I had to put in the axis2.xml of WSO2 ESB (under JMS transport receiver). Remember that you need to put the other parameters such as initial context factory, provider url, connection factory and connection factory type etc.

<parameter name="transport.Transactionality" locked="true">jta</parameter>
<parameter name="transport.jms.SessionTransacted" locked="true">true</parameter>
<parameter name="redeliveryPolicy.maximumRedeliveries" locked="true">-1</parameter>
<parameter name="redeliveryPolicy.redeliveryDelay" locked="true">2000</parameter>
<parameter name="transport.jms.CacheLevel" locked="true">consumer</parameter>

I will explain some of the above parameters.

1. transport.Transactionality - This is the desired mode of transactionality. I was using distributed transactions. Therefore the value was jta. If you are using local transactions you can put it as local.
2. transport.jms.SessionTransacted - Whether the JMS session should be transacted or not.
3. redeliveryPolicy.maximumRedeliveries - Maximum number of retries you wish. If set to -1, ActiveMQ will infinitely retry.
4. redeliveryPolicy.redeliveryDelay - Delay between retries. I have set it to 2 seconds (i.e. 2000 milliseconds).
5. transport.jms.CacheLevel - This is the most important property to get the redelivery mechanism to work properly. This has to be set to "consumer". Reason for this is ActiveMQ  RedeliveryPolicy is dictated by CONSUMER, not PRODUCER.

With above configurations, you are able to get the redelivery mechanism in ActiveMQ to work when used with WSO2 ESB.

You will also need to set the SET_ROLLBACK_ONLY property in the fault sequence of your proxy service. Otherwise the transaction will not get rollbacked.

<property name="SET_ROLLBACK_ONLY" value="true" scope="axis2"/> 

Following links will provide further help.
1. WSO2 ESB documentation's JMS transport section
2. ActiveMQ redeliverPolicy configuration parameters

Fronting your Stratos service with the WSO2 LoadBalancer

Today I wanted to front the StratosLive Manager with the WSO2 LoadBalancer. I didn't have an idea on how to do it. Then with Afkham Azeez's instructions, I was able to do it. I thought of recording the steps for my and others future use. Following instructions will guide you to front any stratos service with a loadbalancer.

First you need to have the WSO2 LoadBalancer and the service (in this case WSO2 Stratos Manager).

Changes to be done in LoadBalancer
Find the loadbalancer.xml in the repository/conf folder.
Add the following lines under services tag.

    

       cloud-test.wso2.com

    

    wso2.manager.domain

This host name is important because it is going to be added to the axis2.xml of Manager.

Add the above host name to /etc/hosts file.

Changes to axis2.xml of Manager
First enable clustering .

Then set membership scheme to well known addressing - wka

wka

Then set the domain as wso2.manager.domain. This is the host name added in the loadbalancer.xml.

wso2.manager.domain

Change the local member port to some random value, say 5000.

5000

After setting the above parameters, start the LoadBalancer. Then start the Manager. When the manager joins the cluster, you will see a log similar to the following in the LoadBalancer log.

[2011-09-01 23:55:55,919]  INFO - RpcMembershipRequestHandler Received JOIN message from 192.168.1.2:5000(wso2.manager.domain)

[2011-09-01 23:55:55,921]  INFO - MembershipManager Application member 192.168.1.2:5000(wso2.manager.domain) joined group wso2.manager.domain

[2011-09-01 23:56:06,935]  INFO - DefaultGroupManagementAgent Application member Host:192.168.1.2, Port: 5000, HTTP:9763, HTTPS:9443, ACTIVE:true joined application cluster

Now you can try to access Manager's management console via the following url https://cloud-test.wso2.com:8243/

Note that Manager is running on 9443. But we specify the port as 8243 because it is the port LoadBalancer is running. Then, the above request first goes to the LoadBalancer and then to the Manager. When you enter the above url in the browser, you can see this by monitoring the two logs of LoadBalancer and Manager.

NOTE: This is the most simplest scenario fronting a service with the load balancer.

Billing in cloud computing - StratosLive billing explained

StratosLive comes with its own billing system to bill the tenants for using the cloud. Lets have a look at the bill generation process of StratosLive. Shown below is a simple diagram to explain the base entities involved in bill generation.

There can be multiple billing engines in your environment. In StratosLive there are two of them. One is for scheduled bill generation (monthly invoice) and the other is for on-demand bill generation (interim invoice). Both these engines use a single billing database. Each of these engines have a set of handlers to be executed. These handlers can be configured via the billing-config.xml. These handlers are executed by the engine at the time of bill generation. Shown below is segment from the billing-config.xml

   

   

   

   

   

       multitenancy-billing-rules.drl

   

   

   

   

   

   

       email-billing-notifications.xml

   

What are the data used in bill generation?

• Subscription details – subscriptions of the user for the duration considered in the bill generation. There is a subscription entry for each usage plan which the user was subscribed to during the billing period
• Usage details – Usage details of the user for the month of bill generation. This includes bandwidth usage (webapp bandwidth, service bandwidth and registry bandwidth) and registry storage of the user.
• Pricing strategy – This defines how users are going to be charged for subscription and overusage. Shown below is a sample xml file which defines the pricing strategy.

10 



 10

 0 





 25 

 0.1





 2000 

 0.1 

When does bill generation happen?

As I mentioned previously, monthly invoice is generated by a scheduled task. This is achieved via Synapse scheduled tasks. When the billing manager is started (i.e. when the server starts), bill generation task is scheduled for the billing engine. This task scheduling can be configured via the billing-config.xml.

Lets go through the bill generation step-by-step. Billing engine for scheduled bill generation executes the following set of handlers.

1.SubscriptionFeedingHandler – Retrieves the subscription entries relevant to the bill generation period. For each subscription, relevant user's usage data also retrieved. Subscription entries are added to the BillingEngineContext to be used by other handlers.

2.SubscriptionTreeBuildingHandler – Goes through all the subscription in the context and arrange the subscriptions of same customer together. Creates invoices and assigns the subscriptions to them. Fills some data of the invoice such as invoice dates, payments falling under the billing period.

3.RuleHandler – Rules are used to calculate the subscription fees. Rule handler executes the rules over the billing engine context. This will assign a subscription fee for all the subscriptions in the contex.

4.InvoiceCalculationHandler – Over usage charges are calculated by this handler according to the pricing strategy define in a xml file. Total cost, total payments an carried forward values are also calculated. At this moment, there is a complete invoice for all the customers in the memory.

5.Finalizing Handler – This handler takes care of storing the invoices in the billing database.

6.EmailSendingHandler - After generating and storing the invoices, customers have to be notified. It is done by the email sending handler. When this is done you receive an email notifying you about the invoice.

Diagram below gives an idea on what happens in the first four handlers.

Scheduled vs. On-demand bill generation

These two operations are carried out by two billing engines

Scheduled generation executes two additional handlers than the on-demand generation. They are the finalizing handler and the email sending handler. When the invoice is generated on-demand, it is not stored in the database (because it is only for presenting to the user). No email notification is necessary because the invoice shown in the UI. That is the reason for FinalizingHandler and EmailSendingHandler not needed for on-demand bill generation.

Flexibility

The whole bill generation process is execution of set of handlers. If you want to add something new to the flow, you can simply write a handler. Then you need to mention that handler in the billing-config.xml for it to be executed by the engine.

Billing component will be further improved to calculate all the costs via rules. Then it will be super easy to make changes in cost items and pricing because only what we need is to edit the rule file. This avoids any code level change when it comes to changes in calculating the cost which is a huge advantage.

Billing the cloud - StratosLive invoice - What does it contain?

StratosLive is a complete Open PaaS from WSO2. It comes up with its own billing component to bill the tenants for using the cloud. If you have tried out StratosLive, you must have received a monthly invoice for using it. Although you receive an invoice it does not means StratosLive charges for everything. If you want you can sign up for a Demo account which is free or else you can sign up for a paid account with more privileges to consume resources.

StratosLive's billing is based on two parameters.

1.Subscription of the tenant – When you sign up to use StratosLive you can select a usage plan. You can change this usage plan whenever needed. There is a monthly subscription fee associated with the plans.

2.Resource usage – When you select a usage plan, there is a set of resources which can be used under that plan. If you happen to consume resources more than the amount allowed, the excess usage will be charged.

Invoice is generated on the last day of the month and you are notified via email once it is available. Shown below is a sample invoice and I'll describe what is included in it. You can view the invoice in StratosLive Manager's Home → Billing & Metering → Past Invoices.

Following information is available in the invoice.

A) Invoice number

B) Invoice period (i.e. for which time period does this invoice applicable) and Invoice date – date which the invoice was generated

C) Subscription fees for the subscriptions you have used during the period. For example if you have sticked to the same subscription there will be one entry for this. But in this sample invoice, the user has used a SMB usage plan for 5 days and then has changed it to a Demo usage plan. Therefore there are two entries for subscription fee section. It is important to notice that the subscription fee is calculated only for the number of days which you were subscribed in to it.

D) Over usage charges – At the time of bill generation, users usage data is retrieved by the billing engine and compares it with the allowed usage limits for the active subscription at that time. If the user has exceeded the allowed limit, excess usage is charged. Charging the excess usage depends on the desire of the cloud owner. For example, in the above invoice, the tenant has consumed 32MB of excess storage. But it is not being charged. Over use charges are calculated for Bandwidth and Storage. Invoice clearly mentions how much is charged for each of them.

E) Payment details within the period – If you did a payment for your previous invoice, it should clearly be mentioned in this invoice. You can see it in the sample invoice too.

F) Finally, there is a summary which includes the Brought Forward value, Total cost for this period, Total payments during this period and the Carried forward value.

G) After all those details, you get the Paypal button to pay the invoice securely.

Interim Invoice

You will not find this facility in many billing systems. But StratosLive provides you to view your cost for using it up to this moment. Interim invoice shows your costs from the last invoice date to this moment. Many cloud services only provides you the monthly invoice at the end of the month. But we provide you the invoice on demand.

If you have been charged for over using resources, you can check whether the excess usage amounts mentioned in the invoice are accurate by going through you usage report for the month. Usage report can be found at Home →Billing & Metering →Usage Report

Throttling in a cloud environment

What is throttling?

The word "throttling" simply means "controlling" when it comes to the computing world. Throttling can be seen in action in different situations. For example,

• On a LAN, the network admin may throttle the bandwidth to control network congestion and server crashes.
• An ISP may throttle the bandwidth for some users to control their usage above a certain limit.
• CPU throttling is used to conserve power or reduce the heat generation.

Why throttling is important in cloud computing?

When hosting a cloud, you have to be aware of the multi-tenant aspect which can cause problems in consuming cloud resources. A large number of users may using the cloud environment in different ways. If your cloud is a PaaS, they'll be hosting services or web applications. If it is SaaS, they'll be using your software. If it is an IaaS, they'll be running VM instances in your platform.

In any of the above scenarios, if a user is consuming too much of your resources, it can cause problems to your entire cloud environment. Either you have to control the user's behaviour or you have to scale up your resources to cater the situation and then charge the user for consuming resources. Even though you decide to scale up and charge, it is always to good to have a control mechanism.

Another advantage of throttling is, you can use it to support your billing system. For example, if you charge based on subscriptions and you want to restrict the users consuming resources not allowed by their subscription, then, throttling is the answer for you.

What can be throttled?

In a cloud environment, there are several parameters which can be throttled.

• Network bandwidth
• Storage
• CPU usage
• I/O operations

Lets see how throttling is used by a real cloud environment. I am considering StratosLive, a complete Open PaaS from WSO2 to describe how it is using throttling.

Throttling in StratosLive

StratosLive presents you the complete middleware platform Carbon from WSO2 in the cloud. Users can create tenants and use the StratosLive cloud environment. It uses throttling to makes sure the users only consume the resources which are allowed to them according to the usage plan they subscribe to. It throttles following parameters.

• Webapp bandwidth - Tenants can host webapps in WSO2 Application Server. When requests are received and responses are sent, it is checked whether the tenant has permission to consume the bandwidth. If not, i.e. tenant has already consumed the allocated bandwidth, the request will be rejected.
• Service bandwidth - Same as webapp bandwidth. This applies to the services hosted in StratosLive.
• Registry bandwidth - This is considered when registry items are accessed by tenants. When a get/put operations is carried out in the registry, a certain bandwidth is consumed. It also undergoes throttling.
• Registry storage - Tenants are allowed to store artifacts in the registry. But to control the storage consumed, it is throttled.
• Number of users per tenant - When a tenant is created, tenant admin can add users to the tenant. This can be throttled if needed.

Above mentioned throttling is done based on monthly usage data of tenants. Not only that, there are throttling rules. These rules can be changed on the fly, making StratosLive's throttling capabilities very powerful.

You can read more about throttling in StratosLive from Sanjeewa Malalgoda's blog.

Metering, Throttling and Billing in cloud

Usage metering is a very important area when it comes to cloud computing. No matter whether it is a public or a private cloud, PaaS provider will be interested in metering the resources consumed by tenants. Accurate metering leads to successful throttling and billing.

WSO2 StratosLive is a public cloud deployment. There needs to be a way of measuring how tenants consume cloud resources. It is necessary to measure them to control or facilitate the tenants consuming resources. StratosLive encourages tenants to make full use of it's resources. But there needs to be a control mechanism too. Billing, Metering and Throttling components are responsible for measuring resource usage, charging the tenants and controlling access to resources in StratosLive.

What is Metering, Throttling and Billing?

Metering is the base for Billing and Throttling. It measures bandwidth and storage consumed by tenants. Throttling runs its throttling rules against the metered data and takes decisions on access controlling to resources. This resources are, webapps, services, registry storage and registry items. Billing, if enabled (which is enabled in StratosLive), charges customers based on the metered data in a monthly basis. Billing considers not only the metered data, but also the usage plan which the tenant is subscribed and the pricing strategy.

Metering

What are being metered?

In StratosLive following are being metered tenant-wise.

• Webapp bandwidth – When a request is coming to a webapp hosted by a tenant and a response is sent, the amount of bandwidth consumed is metered.

• Service bandwidth – When a service hosted by a tenant is invoked and a response is received, the amount of bandwidth consumed is metered.

• Registry bandwidth – When registry resources are accessed (get/put), the amount of bandwidth consumed is metered.

• Registry storage – When artifacts are added to the registry, the amount of consumed registry storage is metered.

How they are being metered?

Webapp and service bandwidths are measured via Tomcat valves(add a link here). When the request is going through the valve, bandwidth is measured. Registry bandwidth and registry storage is measured when artifacts put/get into/from the registry.

StratosLive services (i.e. Enterprise Service Bus, Application Server) measures the above data and sends them to the Business Activity Monitor to be stored. These metered data are then summarized periodically making them available for billing and throttling components.

What data is available for tenants?

Tenants can view their monthly usage report in StratosLive Manager under the following menu.

Home → Billing & Metering → Usage Report

Shown below is a screen shot of a usage report

Throttling

Throttling component is scheduled to run throttling rules periodically and update permission of tenants on accessing/consuming various resources and stores them in the registry. There are throttling agents in each and every service. When a tenant is trying to access a webapp/service/registry item, throttling agent looks for the permission for the relevant action and decides whether to allow or discard the request. One great advantage of the throttling in StratosLive is throttling rules can be updated on the fly. StratosLive Manager provides this facility only to the super-tenant (i.e. the administrator of StratosLive). This means, if you have a private cloud setup, you have total control over throttling. Once the rules are updated via the StratosLive Manager UI, next run of the rules will be using the updated rules.


Billing

Billing (bill generation) is done on a monthly basis. Bill generation is scheduled on the last day of each month. This date can be configured as you wish. When the bill generation is completed, customers (tenants) are informed via email. They can view their invoice in StratosLive Manager Home → Billing & Metering → Past Invoices. Customers can also view their interim invoice too. Interim invoice is the invoice for the time period from last invoice to this moment. This is generated on demand and can be viewed in StratosLive Manager Home → Billing & Metering → Interim Invoice. Shown below is a sample invoice of a tenant.


Where does Billing, Metering & Throttling takes place in StratosLive?

StratosLive user base is growing day-by-day. Therefore, metering, throttling and billing operations can be very heavy. StratosLive deployment architecture makes sure that this does not affect the smooth functioning of any other services. It is done by keeping a dedicated instance for these three heavy tasks. This instance is called the Summarizer.

StratosLive - The most complete open PaaS from WSO2

StratosLive is the new, complete, open PaaS (Platform-as-a-Service) from WSO2. It is powered by WSO2 Stratos which is a cloud middleware platform. WSO2 Stratos shares a common code base with WSO2 Carbon which is a middleware platform.

StratosLive was released on 18th of July 2011(Before that WSO2 had the Stratos beta which reached its EOL with the release of StratosLive). It is a public cloud deployment where you can create your account(tenant) and try it yourself. An important fact about StratosLive is you can try it for free. All you have to do is create an account with a "Demo" usage plan (Demo is for free). If you are interested and if you wanna make use of StratosLive more, you can upgrade your account to be eligible to use more resources such as bandwidth and storage capacity. You can select from SMB, Professional and Enterprise plans. More info about StratosLive usage plans can be found from Pricing Info

If you are familiar with WSO2 Carbon platform or if you want to try out WSO2 Carbon platform, StratosLive gives you that opportunity. Other than the features you find in WSO2 Carbon products, following are some of the new features you can find in StratosLive.

• Tenant-specific logging - You can view logs related to your tenants activities
• Monthly invoice and payment via Paypal - You will receive an invoice at the end of the month for using StratosLive. Dont worry, if you are using the Demo plan, you will not be charged a cent. If you are subscribed to other plans such as SMB, Professional or Enterprise, you will get an invoice. StratosLive allows you to pay the invoice via Paypal securely.
• Usage meter - You can view your usage amounts of StratosLive.
• You can login to StratosLive using your Google Apps account

Most importantly, StratosLive is a multi-tenant environament (yes, it is tenant aware).
So, go to Stratoslive, try it for free, if you are inspired (I'm sure you will), use it in your production :)

I will blog more about StratosLive soon.

Interesting, but unsolved error when building Apache Axiom

These days I was busy with getting the WSO2 Carbon trunk building successfully. While working on it, I encountered an interesting build failure when building Apache Axiom with tests.

Lets think, the Carbon trunk's structure is as follows.

Carbon
  |--Dir1
    |--Axiom
    |--dirX
    |--dirY
  |--Dir2
  |--Dir3

If I go to the Axiom folder and build it with tests, it builds successfully. But, if I stay in Dir1 (i.e. the parent directory which Axiom is in) and give the maven command to build all modules in Dir1 (with tests), I get this error. This seems to happen when building the Axiom OSGI Test Suite.

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
The current artifact axiom-osgi-run-1.2.12-SNAPSHOT.jar is not a valid bundle
Running org.apache.axiom.test.ServiceTest
Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0 sec
[FATAL ERROR] org.apache.felix.ipojo.junit4osgi.plugin.Junit4osgiPlugin#execute() caused a linkage error (java.lang.LinkageError) and may be out-of-date. Check the realms:
[FATAL ERROR] Plugin realm = app0.child-container[org.apache.felix:maven-junit4osgi-plugin:1.0.0]
urls[0] = file:/home/amila/.m2/repository/org/apache/felix/maven-junit4osgi-plugin/1.0.0/maven-junit4osgi-plugin-1.0.0.jar
urls[1] = file:/home/amila/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
urls[2] = file:/home/amila/.m2/repository/org/apache/felix/org.apache.felix.framework/1.6.1/org.apache.felix.framework-1.6.1.jar
urls[3] = file:/home/amila/.m2/repository/org/apache/felix/org.osgi.core/1.2.0/org.osgi.core-1.2.0.jar
urls[4] = file:/home/amila/.m2/repository/org/apache/felix/org.osgi.compendium/1.2.0/org.osgi.compendium-1.2.0.jar
urls[5] = file:/home/amila/.m2/repository/org/apache/felix/org.osgi.foundation/1.2.0/org.osgi.foundation-1.2.0.jar
urls[6] = file:/home/amila/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
urls[7] = file:/home/amila/.m2/repository/org/apache/felix/org.apache.felix.ipojo/1.2.0/org.apache.felix.ipojo-1.2.0.jar
urls[8] = file:/home/amila/.m2/repository/org/apache/felix/org.apache.felix.ipojo.metadata/1.2.0/org.apache.felix.ipojo.metadata-1.2.0.jar
urls[9] = file:/home/amila/.m2/repository/org/apache/felix/org.apache.felix.ipojo.handler.extender/1.2.0/org.apache.felix.ipojo.handler.extender-1.2.0.jar
urls[10] = file:/home/amila/.m2/repository/org/apache/felix/org.apache.felix.ipojo.junit4osgi/1.0.0/org.apache.felix.ipojo.junit4osgi-1.0.0.jar
urls[11] = file:/home/amila/.m2/repository/net/sourceforge/cobertura/cobertura/1.9/cobertura-1.9.jar
urls[12] = file:/home/amila/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar
urls[13] = file:/home/amila/.m2/repository/asm/asm/2.2.1/asm-2.2.1.jar
urls[14] = file:/home/amila/.m2/repository/asm/asm-tree/2.2.1/asm-tree-2.2.1.jar
urls[15] = file:/home/amila/.m2/repository/log4j/log4j/1.2.9/log4j-1.2.9.jar
urls[16] = file:/home/amila/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
urls[17] = file:/home/amila/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
urls[18] = http://felix.extensions:9/
[FATAL ERROR] Container realm = plexus.core
urls[0] = file:/media/dev/software/apache-maven-2.1.0/lib/maven-2.1.0-uber.jar
urls[1] = file:/home/amila/.m2/repository/org/apache/maven/archetype/archetype-packaging/2.0-alpha-4/archetype-packaging-2.0-alpha-4.jar
urls[2] = file:/home/amila/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] loader constraint violation: loader (instance of org/codehaus/classworlds/RealmClassLoader) previously initiated loading for a different type with name "org/codehaus/plexus/util/xml/XMLWriter"
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/classworlds/RealmClassLoader) previously initiated loading for a different type with name "org/codehaus/plexus/util/xml/XMLWriter"
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
 at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
 at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
 at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
 at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
 at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
 at org.apache.felix.ipojo.junit4osgi.plugin.XMLReport.generateReport(XMLReport.java:194)
 at org.apache.felix.ipojo.junit4osgi.plugin.Junit4osgiPlugin.executeTest(Junit4osgiPlugin.java:573)
 at org.apache.felix.ipojo.junit4osgi.plugin.Junit4osgiPlugin.invokeRun(Junit4osgiPlugin.java:447)
 at org.apache.felix.ipojo.junit4osgi.plugin.Junit4osgiPlugin.execute(Junit4osgiPlugin.java:253)
 at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
 at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2 minutes 7 seconds
[INFO] Finished at: Sat Feb 12 23:44:07 IST 2011
[INFO] Final Memory: 233M/964M

Several other people have encountered this problem, but I didn't see a solution for this. If you know the reason for this, please add a comment. It will be very helpful :).