[WSO2 ESB] Comparing two XMLs and find matching elements using WSO2 ESB 4.8.0

Imagine we are getting a list of xml data from an external service and it is required to match this response against another xml payload and find the matching xml elements inside ESB 4.8.0. For e.g. a user send the below request into ESB.
<Accounts>
    <acctNum>123452</acctNum>
    <acctNum>678912</acctNum>
</Accounts>

Inside ESB we are calling an Account DB service which retrieves all the Account elements inside the database and return us. Assume the BE response with Account details is as follows.

<a123: Accounts xmlns:a123="http://test123.com>

    <a123:Account>
        <a123:AcctNum>123451</a123:AcctNum>
        <a123:Date>2014-03-26</a123:Date>
    </a123:Account>
    <a123:Account>
        <a123:AcctNum>123452</a123:AcctNum>
        <a123:Date>2014-04-20</a123:Date>
    </a123:Account>
</a123:Accounts>   
   
Once this response comes into ESB it is required to compare the two xmls and retrieve Account elements that matches with account numbers which are in incoming request. We can do this through an iterate mediator inside ESB too, however the way that is explained here is rather simple to be used, specially for a scenario when it is not possible to use Iterate mediator.

1. When the incoming request comes, we can use xpath to get a comma separated String with all account numbers in the request. Then assign it to a Property mediator.

<property name="accountsList" expression="string-join(//Accounts/acctNum, ',')" scope="default" type="STRING"/>
This XPath expression uses string-join() function from Xpath 2.0. Therefore it is required to enable the below property in ESB/repository/conf/synapse.properties file in order to support Xpath 2.0

# Uncomment following to support fallback XPATH 2.0 support with DOM and Saxon
synapse.xpath.dom.failover.enabled=true   
   
2. Once this property is set we can call the BE and get the Account details response. Then the response payload will be passed to the given XSLT stylesheet using XSLT mediator in ESB.
Also as there is comparison needs to be done here, i am passing the previous 'accountsList' property as a parameter into XSLT stylesheet as well.

<xslt key="MatchingAccounts">
    <property name="AccountsList" expression="$ctx:accountsList"/>
</xslt>
   
3. The stylesheet is added as a local-entry in the ESB with the name 'MatchingAccounts'. If needed you can add this as a Registry resource too.

<localEntry xmlns="http://ws.apache.org/ns/synapse" key="MatchingAccounts">
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:a123="http://test123.com xmlns:fn="http://www.w3.org/2005/xpath-functions" version="2.0">
        <xsl:param name="AccountsList"/>
        <xsl:output method="xml" indent="yes"/>
        <xsl:template match="/">
            <Result xmlns="">
                <xsl:for-each select="//a123:Account">
                    <xsl:if test="matches($AccountsList,a123:AcctNum)">
                        <xsl:copy-of select="."/>
                    </xsl:if>
                </xsl:for-each>
            </Result>
        </xsl:template>
</xsl:stylesheet>   
</localEntry>
   
4. Inside the style sheet if process through each a123:Account/a123:AcctNum element and checks whether the 'accountsList' String contains that account number. If there is a match that <Account> node is taken as results.

5. For the above two XMLs the final payload that comes outside XSLT mediator will be like this, with one matching Account node.
<Result xmlns="">
    <a123:Account>
        <a123:AcctNum>123452</a123:AcctNum>
        <a123:Date>2014-04-20</a123:Date>
    </a123:Account>
</Result>

[WSO2 ESB] Sending Form Data through WSO2 ESB with x-www-form-urlencoded content type

This post is about how to post form data into a REST service from WSO2 ESB 4.8.1.
Imagine that we have the following key values pairs to be passed into a REST service  which accepts x-www-form-urlencoded type data.

name=ishara&company=wso2&country=srilanka

Now when we going to send these data into ESB, it is needed to set them as key values pairs through adding a PayloadFactory mediator in the following format.  

<property name="name" value="ishara" scope="default" type="STRING"/>
<property name="company" value="wso2" scope="default" type="STRING"/>/>
<property name="country" value="srilanka" scope="default" type="STRING"/>/>
            
<payloadFactory media-type="xml">
                <format>
                    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
                        <soapenv:Body>
                            <root>
                                <name>$1</name>
                                <company>$2</company>
                                <country>$3</country>                               
                            </root>
                        </soapenv:Body>
                    </soapenv:Envelope>
                </format>
                <args>
                    <arg evaluator="xml" expression="$ctx:name"/>
                    <arg evaluator="xml" expression="$ctx:company"/>
                    <arg evaluator="xml" expression="$ctx:country"/>
               </args> 
</payloadFactory>           

Then set the messageType property as 'application/x-www-form-urlencoded'. This is how ESB can identify these key-value pairs as form data and it will do the transformations. Then it is also required to disable chunking too.
            
<property name="messageType" value="application/x-www-form-urlencoded" scope="axis2" type="STRING"/>
<property name="DISABLE_CHUNKING" value="true" scope="axis2" type="STRING"/>
                       
Now we are all set to call the REST endpoint with this message data as below. You can use either send or a call mediator.

<call>
   <endpoint key="conf:endpoints/EmployeeDataServiceEndpoint.xml"/>
</call>
                       

WSO2 Message Broker 2.2.0 - An Overview of Newest WSO2 MB Release

After months of hard work we, WSO2 Message Broker team finally completed and released the version 2.2.0 of WSO2 MB, with several community demanded new features and improvements.

The release was initially planned to be go out with two main features namely Dead Letter Channel and Publisher Flow Control. However as the time goes we were able to introduce several more features listed as Cassandra and Zookeeper Profiles support with MB, Message Selectors and Dynamic Queue Support as well as improved SSL and Failover support and a lot more. Below is a quick overview of the newly released WSO2 MB 2.2.0 version. 

The complete information can be found in MB 2.2.0 official documentation which describes each of below feature in detail.

WS02 MB 2.2.0 New Admin Console

What comes new ???

First let's download WSO2 MB 2.2.0 version to experience the new features. Now we are ready go through the list  :)

๏ Dead Letter Channel implementation

The Dead Letter Channel (DLC) is specifically designed to persist messages that are faulty or rejected by the message receivers, providing you with a choice on whether to delete, retrieve or reroute the messages from the DLC. If the subscriber rejected the message, did not ack the sever within a configured time or could not receive message due to connection fail first MB erver will try to resend the message.After doing this for a maximum number of configured times  the message will be routed to DLC.

A user can perform following actions on DLC messages

• Delete (discard mal-formatted message)
• Restore message to the original queue 
• Re-route the message to any other existing queue in MB cluster

๏ Publisher Flow control implementation

Flow control ensures that the rate at which messages are transmitted from the publisher to the receiver is controlled. Back-pressure is exerted when the defined global memory threshold or message count threshold per connection is exceeded. At this point, message acceptance is blocked until the sender is notified of memory recovery.  If the memory is not recovered within a specified time interval 'qpid.flow_control_wait_failure' which is by default 120s (2 mins), all currently publishing clients will be disconnected. But the subscriber clients will be able to continue.

The users are able to increase/decrease this wait time as needed by setting system property 'qpid.flow_control_wait_failure' at client-side. This value is 'long' type.

WSO2 MB 2.2.0 comes with following flow control mechanisms.
1. Throttling based on global memory threshold
2. Throttling based on message count per connection

๏ MB profile support for Cassandra and Zookeeper

With the previous MB releases it was required to download Cassandra and Zookeeper from external sites and point MB to be run with those. From 2.2.0 onwards this is no longer needed and you can start WSO2 MB purely as a Apache Cassandra server. All configurations files of Cassandra are there plus the port is configurable with an offset. The logs related to Cassandra are written to wso2carbon.log file as well as we have introduced a new log file specially for Cassandra system logs, as <MB_HOME>/repository/logs/cassandra_system.log file. Cassandra tools such as nodetool,cassandra-cli scripts are also packed inside MB. Also now you can start WSO2 MB purely as a Apache Zookeeper server. Hence in order to create a complete message broker cluster the users only need a WSO2 MB distribution.

๏ JMS message selectors support

Message selectors allow you to filter specific messages using a selector string. The message consumer will then receive only messages whose headers and properties match the selector. There are different patterns that can be used in selector strings, and the broker (JMS provider) filters messages according to that query. It is not possible for a message selector to filter messages on the basis of the content of the message body.

๏ Queue/Topic Permission model 

The role permission list is modified now the admin can explicitly set the each permissions like create queue/browse queue etc. inside a role. Therefore now when you create a queue/topic it can be selected whether this user can publish/subscribe to the created queue or topic.

WSO2 MB 2.2.0 Permission Model

๏ Dynamic queue support

In previous Message Broker releases users needed to create a subscriber or create the queue from admin console before start publishing messages to that queue and if not messages will be lost. Now this is  improved with dynamic queue support that when the publisher client initiates the queue is created in the broker, even if there are no consumers. The create queue segmant of message publisher would be as follows.

        QueueConnectionFactory connFactory = (QueueConnectionFactory) ctx.lookup(CF_NAME);
        QueueConnection queueConnection = connFactory.createQueueConnection();
        queueConnection.start();
        QueueSession queueSession =
                queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
        // create queue
        Queue queue =  queueSession.createQueue("Queue-MB");
        // create the message producer for queue
        javax.jms.QueueSender queueSender = queueSession.createSender(queue);

๏ Improved SSL support

The wire level connection between client-server of broker can be encrypted using SSL to provide maximum protection where this is supported in both standalone and clustered mode with failover as well. The SSL properies are easily configurable at the client side using AMQP connection url.

๏ Improved logging 

Trace level logs are now separated for easy debugging. In addition there are two more log files have been introduced for Cassandra and Zookeeper profiles named, cassandra_system.log and zookeeper.log file.

๏ Queue/Topics Subscription UI

A new segmant is introdued to WSO2 MB 2.2.0 admin console as shown in above image to view active/inactive queue and topic subscriptions for whole MB cluster. The following details are displayed in the new UI.

• View active topic subscriptions in whole MB cluster 
• View inactive durable topic subscriptions specifically.
• Ability to unsubscribe inactive durable topic subscriptions with UI.

Queue/Topic Subscriptions UI

Apart from these major changes there are a lot of bug fixes and improvements in the new release. It was a great and hard team work for the last few months for all of us ( there are a lot in the team including our QA crew) to finally get the 2.2.0 release out. It is really proud to be a part of my team and we are now gearing up for WSO2 MB 3.0.0 which will be coming out as a complete revamped architecture. Looking forward for 3.0.0 :) :)

WSO2 ESB Performance Round 7.5 is now released ......

As the Enterprise Service Bus 4.8.1 version was out in early February this year WSO2 ESB team has carried out a latest ESB Performance round, which results in that the newly released WSO2 ESB clearly outperforms other ESBs in the current market. The ESB Performance round 7.5 testing was conducted on an Amazon c1.xlarge EC2 instance of a 64-bit instance with 8 cores, 20 ECUs, and 7GB of memory.

The following table and graph show the summary results which is drawn against 'Average TPS Values' per 'Proxy Service' of the performance test. In summary it can be stated that,

• As shown in the graphs below, WSO2 ESB 4.8.1 is the fastest in performance compared to all the other ESBs here, except for the security scenario.

1.


2.



The 'ESB Performance Round 7.5' article in the WSO2 Library provides a comprehensive report of the complete test round. 

Creating an OSGi Bundle out of a Third Party Library for Using as WSO2 Product Dependency

WSO2 platform supports a modular based architecture where third party libraries which are used in WSO2 products are exposed into the environment as OSGi bundles. This blog post is about how to OSGify a third party library, to be used as a dependency inside WSO2 MB.

We have recently used 'Disruptor', a high performance inter-thread messaging library  as a dependency in WSO2 Message Broker for improving the performance by using disruptor based message writing operations into Cassandra storage. When doing this it is first needed to create an OSGi bundle out of 'Disruptor' library, so it can be referred in the runtime when Message Broker is running.

As common to all OSGi bundle generations, first you need to have a manifest.mf file which describes the bundle information, version info, which packages needed to be imported/exported etc. However as it is not easy to write this file correctly by hand we use maven-bundle-plugin in order to get this done. This process is common to any third party dependency and you can follow the same process in building an osgi bundle for any of them.

1. First let's create a directory named 'disruptor' inside <WSO2_Carbon_Source>/platform/dependencies/orbit/ directory. As we have used Disruptor 2.10.4 version i created a new package called 2.10.4-wso2v1 inside disruptor directory. (This is the common notation across the platform <LibraryVersion>-wso2v<VersionNumber>when naming the versions of the dependencies.)

2. Add a new maven build file (pom.xml) inside package 2.10.4-wso2v1.

3. Now let's add the required details which needs to generate the OSGi bundle into this file. This pom file can be used as a sample template by replacing the required entries when adding another dependency.

<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 ">http://maven.apache.org/maven-v4_0_0.xsd">

<parent>
   <groupId>org.wso2.carbon</groupId>
   <artifactId>carbon-dependents</artifactId>
   <version>4.1.0</version>
   <relativePath>../../../pom.xml</relativePath>
</parent>

<modelVersion>4.0.0</modelVersion>
<groupId>com.googlecode.disruptor.wso2</groupId>
<artifactId>disruptor</artifactId>
<packaging>bundle</packaging>
<name>WSO2 Carbon - Orbit - disruptor</name>
<version>2.10.4-wso2v1</version>
<description>This bundle exports packages from disruptor jar files</description>
<url>http://wso2.org</url>

<dependencies>
   <dependency>
      <groupId>com.googlecode.disruptor</groupId>
      <artifactId>disruptor</artifactId>
      <version>2.10.4</version>
      <optional>true</optional>
   </dependency>
</dependencies>

<build>
     <plugins>
            <plugin>
                 <groupId>org.apache.felix</groupId>
                 <artifactId>maven-bundle-plugin</artifactId>
                 <version>1.4.0</version>
                 <extensions>true</extensions>
                 <configuration>
                      <instructions>
                        <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
                        <Bundle-Name>${project.artifactId}</Bundle-Name>
                        <Export-Package>
                                com.lmax.disruptor.*;version=2.10.4,
                         </Export-Package>
                        <Import-Package>
                                !sun.misc,
                                *
                        </Import-Package>
                      </instructions>
                </configuration>
            </plugin>
     </plugins>
</build>

<!--<repositories>
    <repository>
       <snapshots>
          <enabled>true</enabled>
          <updatePolicy>daily</updatePolicy>
          <checksumPolicy>ignore</checksumPolicy>
    </snapshots>
    <id>wso2-maven2-snapshot-repository</id>
    <name>WSO2 Maven2 Snapshot Repository</name>
    <url>http://dist.wso2.org/snapshots/maven2/</url>
    <layout>default</layout>
  </repository>
</repositories>-->

<properties>
     <disruptor.build.version>2.10.4</disruptor.build.version>
     <disruptor.version>${disruptor.build.version}-wso2v1</disruptor.version>
 <disruptor.orbit.version>${disruptor.build.version}.wso2v1</disruptor.orbit.version>
</properties>
</project>

Let's go trough the important entries in the file.

<dependencies>
<dependency>
<groupId>com.googlecode.disruptor</groupId>
<artifactId>disruptor</artifactId>
<version>2.10.4</version>
<optional>true</optional>
</dependency>
</dependencies>

As we are using external library in the OSGi bundle we need to add this as a maven dependency entry for the bundle. You can find maven dependency entries of lot of libraries in here.

<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>1.4.0</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
<Bundle-Name>${project.artifactId}</Bundle-Name>
<Export-Package>
             com.lmax.disruptor.*;version=2.10.4,
</Export-Package>
<Import-Package>
             !sun.misc,
             *
</Import-Package>
</instructions>
</configuration>
</plugin>
</plugins>
</build>

This is how we use maven-bundle-plugin to generate the disruptor osgi bundle. The Export-Package, Import-Package and DynamicImport-Package tags are used to control the exposure of certain packages to other bundles. With <Export-Package> tag it will find the defined project classes or dependencies, and they will be copied to the osgi bundle. With using <Import-Package> here, we can import the extra classes that have been referred from our osgi bundle. By keeping * as the value here by default it imports all the reference classes that needs for OSGi bundle generation. However when using default value here for 'disruptor bundle' i encountered the following error.

org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Import-Package: sun.misc; version="0.0.0"

So I added the entry '!sun.misc' to resolve this issue and it seems as the sun.misc package is already there to be referred by the osgi framework, we need to tell that it is not needed to explicitly import it in this case. This is a 'Disruptor' bundle specific entry and you don't have to add the same configuration in each bundle you create. However if the bundle's classes use sun.misc package, this setting might be useful in resolving similar errors.


4. That's it! Save the pom file and build it with maven ( WSO2 projects use Maven3). You will see that in the <WSO2_Carbon_Source>/platform/dependencies/orbit/disruptor/2.10.4-wso2v1/target folder the newly created osgi bundle 'disruptor-2.10.4-wso2v1.jar' is present.

If you see the manifest.mf file of the new bundle it will be as follows.

Manifest-Version: 1.0
Export-Package: com.lmax.disruptor.collections;version="2.10.4",com.lm
ax.disruptor;uses:="com.lmax.disruptor.util";version="2.10.4",com.lma
x.disruptor.dsl;uses:="com.lmax.disruptor,com.lmax.disruptor.util";ve
rsion="2.10.4",com.lmax.disruptor.util;uses:="com.lmax.disruptor";ver
sion="2.10.4"
Ignore-Package: sun.misc
Built-By: <your_host_name>
Tool: Bnd-0.0.238
Bundle-Name: disruptor
Created-By: Apache Maven Bundle Plugin
Bundle-Version: 2.10.4.wso2v1
Build-Jdk: 1.6.0_30
Bnd-LastModified: 1373904351577
Bundle-ManifestVersion: 2
Bundle-Description: This bundle exports packages from disruptor jar fi
les
Bundle-SymbolicName: disruptor
Import-Package: com.lmax.disruptor;version="2.10.4",com.lmax.disruptor
.collections;version="2.10.4",com.lmax.disruptor.dsl;version="2.10.4"
,com.lmax.disruptor.util;version="2.10.4"


To know more about creating OSGi bundles with maven-bundle-plugin, you can read the following article in WSO2 Library.


[1]. http://wso2.com/library/tutorials/develop-osgi-bundles-using-maven-bundle-plugin

Configuring SSO session timeout in WSO2 Identity Server 4.5.0

One of the key features in WSO2 Identity Server  is SAML2 based single sign on (SSO) feature. The default time period for a SSO session is 10 hours in the Identity Server versions so far and this default SSO Session Expire time value can not be changed according to the user needs. But from WSO2 IS 4.5.0 onwards the SSO session timeout can be configured at the server start time.

This configuration lies on <IS_HOME>/repository/conf/identity.xml file under the SSOService element. Add the following entry under that in order to explicitly add the SSO timeout.

<SSOService>
<SessionTimeout>120</SessionTimeout>  // Add the expecting timeout value in seconds here.
</SSOService>

Save the configuration and restart the server. Now the SSO session will be timed out as the newly configured value and a user may need to re-authenticate once he logs back after this timeout. It is not a must to have this entry in 'identity.xml' and if a timeout is not configured, the SSO session will use the '10 hours (36000s)' default time out value.

After configuring the SSO Session Expire time you can use this article in order to setup Single Sign On with WSO2 Identity Server.

Adding a new function into WSO2 MB FE using JavaToWsdl approach - My notes

In most of the WSO2 products JavaToWsdl approach is used in adding new functionality. In here we first add the necessary new methods into the relevant service class in /platform/components and then generates the service wsdl for that. After that the service wsdl is added into the corresponding wsdl file in the /platform/service-stubs this stub is used in the front end UI components, in order to call the new method.

As an example let's add a new method to obtain the currently logged in user's name from the UI components.

WSO2 Message Broker's source code is mainly written in the /platform/components/andes component. The admin functionalities are coded in 'org.wso2.carbon.andes.admin' sub component under the AndesAdminService.java class.

First add the new method into the java class.

public String getCurrentUser(){
          
        // ADD METHOD BODY HERE       
        return userName.trim();
}

Due to authentication requirements in the WSO2 MB, you need to add the following entry into the relevant 'services.xml' file in the 'Resouces' package in the component.

<operation name="getCurrentUser">
     <parameter name="AuthorizationAction" locked="true">/permission/admin/configure</parameter>
 </operation>

Now save the two files. Once we build the 'org.wso2.carbon.andes.admin' component back these changes will be available in the back end. But to use them in front end we need to edit the corresponding service wsdl file in the /platform/service-stubs.

For this goto <MB_HOME/Repository/conf/carbon.xml>  file. Find the <HideAdminServiceWSDLs> entry. This is set 'true' by default, as we don't want to expose admin service details, but now we need to see the service wsdl file to see the new functions we added there. Hence make this into 'false'.

<!-- If this parameter is set, the ?wsdl on an admin service will not give the admin service wsdl.--><HideAdminServiceWSDLs>false</HideAdminServiceWSDLs>

Build 'org.wso2.carbon.andes.admin' component using maven and replace org.wso2.carbon.andes.admin_4.1.2.jar file in the <MB_HOME/Repository/Components/Plugins> directory, with this newly built jar file found in /target folder.
(Note: Remember to rename the jar file according to notation)

Start the MB server back and goto ,
https://localhost:9443/services/AndesAdminService?wsdl

You will see the AndesAdminService wsdl file with the newly added changes. Now let's add these to the service-stub to be used in Front End.

The corresponding service-stub for 'org.wso2.carbon.andes.admin' component is, /platform/service-stubs/org.wso2.carbon.andes.stub/4.1.0

In here you will find the /resources/AndesAdminService.wsdl file. Copy the new changes from the wsdl file that is viewed in the browser, into this wsdl file. Some of the changes would be like,

<wsdl:message name="getCurrentUserRequest"><wsdl:part name="parameters" element="ns:getCurrentUser"/></wsdl:message>
<wsdl:message name="getCurrentUserResponse"><wsdl:part name="parameters" element="ns:getCurrentUserResponse"/></wsdl:message>   and more ....

After adding all the changes build the service-stub back using maven. Replace org.wso2.carbon.andes.stub_4.1.0.jar file in the <MB_HOME/Repository/Components/Plugins> directory, with this newly built jar file found in /target folder.

Now you can call this stub class from andes ui components and use the newly added 'getCurrentUser()' method as given below. The same procedure is to be followed whenever we add new functions into the code base.

AndesAdminServiceStub stub = UIUtils.getAndesAdminServiceStub(config, session, request);
String username = stub.getCurrentUser();

Providing Queue browing, message sending and purging features in WSO2 MB 2.1.0

WSO2 MB is a Message Broker which enables applications to exchange communications asynchronously or publish messages for timely access by many subscribers. For the past versions of WSO2 MB there was no support for sending sample messages from the admin console or viewing the messages in a queue. hence in WSO2 MB 2.1.0 onwards, we have added this functionality into the broker.

Therefore it is now possible to,

1.  Send sample text messages to a queue in WSO2 MB
2.  Browse the content in a queue using MB admin console
3.  Purge a queue via admin console and make it empty in WSO2 MB as of the expectation of many users.

The following are some of the snapshots from the new view of the MB admin console.  The 2.1.0 version is not yet released for public but will be releasing by end of this month.

1. New view of the 'Queue Menu'

2. New Queue Browser in WSO2 MB

3. New Message Sending UI in MB

4. New Queue purging option in MB

More details on the new features can be found in MB 2.1.0 documentation once it is released.

Deploying and Running WSO2 API Manager 1.3.1 in an Amazon EC2 instanace

This post is a quick guide on how to deploy WSO2 API Manager 1.3.1 in an AWS EC2 instance and running operations on it. You can also run API Manager behind an Elastic Load Balancer (ELB) in EC2 instance. The configuration procedure is same as described below, except the public DNS address to be used is the DNS of the ELB in that case.

Requirements: Amazon Web Services account
                        WSO2 API Manager 1.3.1


1. If you still don't have an AWS account create one as given here. In the account creation process you will need to specify a password and you will be given a Access Key ID and a Secret  Access Key which will be needed later for you to connect to your AWS EC2 instance.

2. Using your credentials log in to AWS Management Console and open Amazon EC2 console.

https://console.aws.amazon.com/ec2/

3. Create a new Linux instance by selecting "Launch Instance". Create your new instance by following the steps given in this guide.
In doing this choose ' Ubuntu Server 12.04' as the Amazon Machine Image (AMI) type and 'M1 Medium' as the instance type. Specify relevant key-pair or create a new one. If you create a new key-pair, download this into your computer and make sure you remember where it is located in your machine. (You need this later in this post!)

4. Once you finish creating an instance you can see it in the running instances list in the console. if you click on it you will see more information about the new instance.

4. Now let's connect to this instance  and deploy our Am 1.3.1 pack here. 

• Goto the location where you key-pair is located. Now we are going to connect to our Ubuntu server instance in EC2 using SSH. 


• Find the Public DNS address of your instance. In my case this is 'ec2-00-000-000-00.compute-1.amazonaws.com' (Note that i have changed the digits in my EC2 instance DNS here).


• Enter the following command in the terminal.

ssh -i ishara.pem ubuntu@ec2-00-000-000-000.compute-1.amazonaws.com


• In here  'isarap.pem' is the keypair file that was downloaded when creating the EC2 instance.
  ec2-00-000-000-000.compute-1.amazonaws.com is the public DNS address of your instance.


• Most probably there will be 'permission denied' error when you try this the first time. This is because there is more permission given for your keypair file when it is created. We need to make to more access restricted. For that use,

chmod 400 ishara.pem


• After that when you try to SSH you will be able to successfully connect to your instance in AWS EC2.You will now see the following message which means you are now connected.

Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-36-virtual x86_64)

* Documentation: https://help.ubuntu.com/

System information as of Mon Apr 29 17:48:41 UTC 2013 
System load: 0.08                 Processes: 59 
Usage of /: 32.9% of 7.87GB Users logged in: 0 
Memory usage: 32%             IP address for eth0: 10.202.151.238 
Swap usage: 0% 

Graph this data and manage this system at https://landscape.canonical.com/ Get cloud support with Ubuntu Advantage Cloud Guest http://www.ubuntu.com/business/services/cloud 

Use Juju to deploy your cloud instances and workloads. https://juju.ubuntu.com/#cloud-precise 

Last login: Mon Apr 29 07:03:15 2013 from 203.143.18.194 
ubuntu@ip-10-202-151-238:~$
.........................................................................................................


5. As now you are logged into ubuntu instance, consider this as a normal scenario where you work on your local computer. Make a new directory in EC2 instance as apim/ and copy API Manager 1.3.1.zip pack into this EC2 instance.

ubuntu@ip-10-202-151-238:~$ pwd
/home/ubuntu

ubuntu@ip-10-202-151-238:~$  mkdir apim/


Open another terminal and enter command,
scp -i ishara.pem wso2am-1.3.1.zip ubuntu@ec2-00-000-000-00.compute-1.amazonaws.com:/home/ubuntu/apim

This will be copying Am 1.3.1 distribution files into the apim/ directory in EC2 instance. Similarly copy JDK 1.6 pack as you needs it to run the API Manager in EC2. 

6. Unzip both distributions now. If 'zip' is not installed you will first need to install it. Edit the .bashrc in /home/ubuntu directory and add the path to your JDK ad JAVA_HOME in it.

7. Unzip the API Manager 1.3.1 pack too. In order to start the API Manager server in an outside location we need to configure carbon.xml and api-manager.xml files in AM_HOME/repository/conf directory . The following guide explains how to do this in detail.

API Manager User Guide: http://dist2.wso2.org/products/api-manager/1.3.0/APIManager-GettingStarted-v1.3.0.pdf 

In addition find the following entries in api-manager.xml and specify the values given below.

<KeyValidatorClientType>WSClient</KeyValidatorClientType>
<EnableThriftServer>false</EnableThriftServer>    

..........................................................................................................
Note: You need to install 'curl' in EC2 instance to follow the steps in this guide. If there are issues occurs when trying with,

pubname=$(curl http://169.254.169.254/latest/meta­data/public­hostname 2>/dev/null);
export JAVA_OPTS=­Damazon.pub.hostname=$pubname

In that case remove the above lines from .bashrc file and manually enter the 'EC2 instance public DNS url' into the places described in the configuration. 

For example instead of adding,

<HostName>${amazon.pub.hostname}</HostName> in carbom.xml file you can enter as 
<HostName>ec2-00-000-000-00.compute-1.amazonaws.com</HostName>

...............................................................................................................................
 
8. When all these configurations are over, start API Manager from /home/ubuntu/apim/wso2am-1.3.1/bin. Point your browser to,

https://ec2-00-000-00-00.compute-1.amazonaws.com:9443/carbon/ 

9. The WSO2 Admin Console for API Manager will be started! You are running AM 1.3.1 in AWS EC2 now :)  

WSO2Con 2011: A fantastic week with SOA, Open Source Development Trends and Cloud Computing

WSO2Con 2011, The second annual user conference organized by WSO2 is all set to begin from tomorrow with the participation of a whole set of local and international CEOs, Software Developers, Architects and  IT Managers gathered from all over the world. The event is compromised with three conference days   at Waters Edge Hotel, Battaramulla and two tutorials days. WSO2Conf 2011 is a whole event of guest speeches, customer experiences, tutorials and SOA best practices which will bring a remarkable experience to all its participants who has a great bond with open source developement community.

The conference week begins with a pre-conference tutorial day on 12th Sepetember 2011 at Taj Samudra Hotel,Colombo. This tutorial day covers most of the introductory tutorial sessions related to SOA and web services including Introduction to SOA, Introduction to WSO2 Carbon Platform, Introduction to Cloud Computing etc. 

Main conference is scheduled from 13th to 15th September at Waters Edge, which will bring an overall experience of getting familiar with the innovative WSO2 product stack as well as many SOA and Web Services related technologies from guest speeches from well known software professionals in the world. 

The conference may end with a post-conference tutorial day on 16th September at Centre for Banking Studies, Kotte. Post-conf tutorials cover some advanced aspects of WSO2 products and technologies.

Corresponding to the event, selected 50 local university students have given a valuable opportunity of participating WSOConf 2011 under a highly affordable package, which will surely give a value added opportunity to their carriers and interests. Although i am still a university student, i was very fortunate to participate the whole conference week for free as a team member due to my internship at WSO2 at the moment. I specially hope to participate on  'Introduction to OSGI' and 'Introduction to Web and SOA Security' sessions which i hope as essentials in getting familiar with WSO2 products. Also very much looking forward to attend in 'Advanced Concepts in WS-BPEL' session presented by my team members of WSO2 BPS team.  

Read the whole list of the tutorial sessions and conference days agenda here.

Here are the key speakers who are going to address WSO2Conf 2011.

The location information is available here.

Inviting all the participants to have a wonderful Con Week in Sri Lanka :)