Monday, November 17, 2014

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.


Saturday, July 19, 2014

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.


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..

Friday, February 21, 2014

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 :)

Friday, July 19, 2013

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.

Thursday, July 18, 2013

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... :)

Saturday, September 29, 2012

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.
  

Saturday, September 15, 2012

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.... :)