WSO2 con 2014 Asia is coming soon in March.....

WSO2 con - 2014 in Colombo, Asia

WSO2 brings 2014 conference back in Colombo, SriLanka . It will be a great opportunity to learn technology insights in SOA(Service Oriented Architecture) and to build connected business with the world. Within a short time, you will get a chance to exposure on a complete middleware stack including governance, big data, enterprise integration, API-centric enterprise integration, Real time analistics, Security and Cloud. Attending to the con will definitely sharpen your tech background with these varienty of things in SOA.

Are you interested in get to know about how to build a light weight PaaS with essential elements in placed? Here is the talk for that “Essential Elements of an Enterprise PaaS” by Lakmal.  In this session, Lakmal will talk about the essential elements of an Enterprise PaaS and how Apache Stratos (incubating) is delivering on these aspects. You will get to know about a rapidly development Apache project and it would be a entry point for you to contribute to a Apache project. Please visit Apache Stratos official-site to get more information in order to be part of the conversations and contribution. If you wish contributing to Apache Stratos, don't miss the chance of attending to WSO2 2014 Asia conference in March.

Apache Stratos as PaaS framework

It is light weight messaging based PaaS framework helps you to quickly develop, deploy and run your new applications. You put your things on top of Stratos and continue to use it without worrying much about the availability of your application all the time. Stratos will take care of the resources by monitoring and provision enough resources in your peek time and manage them in a cost effective manner. This will include scaling and fail-over handling to your applications. The health monitoring behind Apache Stratos will take the decision in the real time and passing it to the relevant functional point.

The key features are delivering in Apache Stratos:

* Support for several IaaS such as EC2, openstack, vcloud and etc(in future)
* Support for any kind of application
* Support for data persistent
* Horizontal scaling, high availability and span across geographical regions
* Multitenancy support
* Monitoring and Billing for the applications


In order to work with Apache Stratos,
* Follow us in mailing-lists or in the official-site to get the right guide. So that you will get to install your own PaaS in a very short time.

For more information see WSO2Con Asia 2014 official website.

PayloadFactory Vs Enrich Mediator in WSO2 ESB

When you need to customize the payload of request or a response in WSO2 ESB, then here is the way to go. You can use PayloadFactory mediator to replace the payload with the different payload or you can use enrich mediator to modify the existing payload.

• The following steps will explain how can a payload be replaced with a different payload using PayloadFactory mediator:

<property name="id" expression="//id" scope="default" type="STRING"/>
<property name="name" expression="//name" scope="default" type="STRING"/>

<payloadFactory media-type="xml">
        <format>
            <m:response xmlns:m="http://services.samples">
                <m:customer>
                    <m:id>$1</m:id>
                    <m:name>$2</m:name>
                </m:customer>
            </m:response>
        </format>
        <args>
            <arg evaluator="xml" expression="$ctx:id"/>
            <arg evaluator="xml" expression="$ctx:name"/>
        </args>
    </payloadFactory>

Where in the argument, the id and name are set using the message context. From the request or response, these id and name can be parsed through the xpath and set it as a property as above.

• The following steps will explain how can a payload be replaced with a different payload using Enrich mediator:

<property name="id" expression="//id" scope="default" type="STRING"/>
<property name="name" expression="//name" scope="default" type="STRING"/>

<enrich>
            <source type="inline">
                <response >
                <customer>
                    <id>xxx</id>
                    <name>xxxx</name>
                </customer>
            </response>
            </source>
            <target type="body"/>
 </enrich>
<enrich>
            <source type="property" clone="true" property="id"/>
            <target xpath="//s:response/s:customer/s:id" xmlns:s="http://ws.apache.org/ns/synapse"/>
</enrich>
 <enrich>
            <source type="property" clone="true" property="message"/>
            <target xpath="//s:response/s:customer/s:name" xmlns:s="http://ws.apache.org/ns/synapse"/>
</enrich>

In this case, the first enrich will replace the body with the specified payload. Then the second and third enrich will replace the values of the element in the body using the available property.
       

Worker-Manager separation with two ELB's

The latest release of WSO2 products which were based on carbon 4.0.0 supports worker-manger separation. In this post, you can find out how to configure worker-manager with two ELB's with single cluster and how it can be extended to another deployment. This patterns is clearly explained in Afkham Azeez's blog.

Worker-Manager clustering with two ELB's and one worker/manager cluster

I have configured every instance in different machine. The configuration can be found as following:

ELB-mgt

=========

repository/conf/loadbalancer.conf

esb {

hosts mgt.esb.cloud-test.wso2.com;

domains {

wso2.esb.domain {

sub_domain worker;

tenant_range *;

}

}

}

repository/conf/carbon.xml

<MgtHostName>elb.mgt.wso2.com</MgtHostName>

Then you have to have the relevant entry in the /etc/hosts for elb.mgt.wso2.com.

ELB-worker

===========

repository/conf/loadbalancer.conf

esb {

hosts esb.cloud-test.wso2.com;

domains {

wso2.esb.domain {

sub_domain worker;

tenant_range *;

}

}

}

repository/conf/carbon.xml

<MgtHostName>elb.worker.wso2.com</MgtHostName>

Then you have to have the relevant entry in the /etc/hosts for elb.worker.wso2.com.

I have assumed here that port offset of both ELB's are kept as default and they are running in different machine. Default ELB's transport port https:8243, http:8280

Worker-cluster

==============

All worker nodes can be configured as in (http://docs.wso2.org/wiki/display/ELB203/Setup+ELB+with+WSO2+ESB) for clustering and proxy set up. Also, add the relevant entries to /etc/hosts

in addition to the configuration, you will have to add the following to all worker node as like management node (can find the place in documentation).

repository/conf/axis2/axis2.xml

<property name="port.mapping.8280" value="9764"/>

<property name="port.mapping.8243" value="9444"/>

9764, 9444 can be veried according to your port offset of servlet transport. 8280, 8283 are ELB's transport. If two ELB for one cluster, then both should be kept in the same transport port.

Special node which will be manager and worker

==========================================

Have to configure like above worker node cluster and in addition to that need to add

repository/conf/carbon.xml

<MgtHostName>mgt.esb.cloud-test.wso2.com</MgtHostName>

repository/conf/axis2/axis2.xml

Instead of one member, need to add two ELB as well known memebers.

<members>

<member>

<hostName>elb.mgt.wso2.com</hostName>

<port>4000</port>

</member>

<member>

<hostName>elb.worker.wso2.com</hostName>

<port>4000</port>

</member>

</members>

repository/conf/axis2.xml.

<parameter name="WSDLEPRPrefix" locked="false">http://esb.cloudtest.wso2.com:8280</parameter>

/etc/hosts of special node should include

.

<ip of ELB worker> esb.cloud-test.wso2.com
<ip of ELB managee> mgt.esb.cloud-test.wso2.com
<ip of ELB worker> elb.worker.wso2.com
<ip of ELB manager> elb.mgt.wso2.com

Single cluster with one ELB where one node worker/manager and accessible directly

==================================================================

All workers need to configure as stated in the documentation.

Special Node :

As stated in the above setup for special node, you will have to follow up,

adding only one member as a well known member as following:

<members>

<member>

<hostName>elb.worker.wso2.com</hostName>

<port>4000</port>

</member>

</members>

removing the proxy port in repository/conf/tomcat/catalina-server.xml and keep other configurations as it is.

All the other configuration should be kept as previous setup manager node. Now you can eliminate the manager ELB and work on this setup accessing management console directly via https://mgt.esb.cloud-test.wso2:9444 (servlet transport port) and worker requests can be served via https://esb.cloud-test.wso2:8243 via ELB.

Also, add the /etc/hosts as similar as above setup to the special node machine.

References

========

1. http://blog.afkham.org/2012/08/separation-of-worker-management-nodes.html

2. http://charithaka.blogspot.com/2012/09/setting-up-minimum-deployment-of-wso2.html

Encoding and Decoding
=================

You can use encoding in order to render a specific language properly in any browser. When you support encoding from your front end, you need to make sure that you adhere to the following in order to avoid upcoming future issues.

1. OS (windows, ubuntu and etc)
2. Browser
3. Code (whole flow from JSP to the back end)

1. OS

Different OS supports different encoding type as default. For example windows 7 supports cp1252 which is a western char set and ubuntu supports UTF-8 which unicode char set. If we take java, jvm by default pick up the char set from the OS. But you can change the char set to jvm by adding an environmental variable in windows for example to support UTF-8 in windows:

JAVA_TOOL_OPTIONS
Variable value : - -Dfile.encoding=UTF-8

FYI:- Windows XP and previous versions supports unicode. So that you don't need to add this. But after windows 7 only, you may need to add this only if the default char set is different from UTF-8.

The reason why i'm taken UTF-8 is most of the time we support in our code UTF-8 as it is unicode. So making whole flow into unique charset is important when it comes to encoding and decoding.

2. Browser

To view a particular language, you may have to switch to correct encoding from the browser. Browser precedence  when choosing right encoding is from:

          *  The encoding send by the server (in JSP eg: encoding specified in meta tag)
          *  User preference from the broswer

Since we include UTF-8 or some other encoding in JSP's, browser tends to choose them as the encoding every time a page getting loaded. In order to to choose different encoding from JSP's meta tag, we will have to choose it in every page reloads which is a pain for a user. So that we have to support such different encoding from JSP itself. Then only users can go ahead without facing any problem.

3. Code (whole flow from JSP to the back end)

Every where encoding and decoding should be taken as the correct charset. So in order to make sure, we might have to develop the back end supporting correct encoding and decoding. For an example:
Encoding in JSP's
Encoding to query parameters
Encoding to DB input values

Like wise, you will have to check each and every area where encoding decoding is handled in order to avoid loosing details by following wrong encoding type in the middle.

This post is to just to give an idea about encoding and it's issues so that we can think better to support internationalization of a developing web site.

URL-Mapping on Stratos

Configure URL-mapping on Stratos
=========================

ELB setup
========

CARBON_HOME/repository/conf/loadbalancher.conf
    * enable cache_size with preferred size
    * enable url_sufix in each service
        Eg: 

************************************************************************************
appserver {
       hosts                   appserver.cloud-test.wso2.com;
       url_suffix             as.wso2.com;
       domains   {
           wso2.as.domain {
                          tenant_range    *;
           }
           
       }
    }

esb {
       hosts                   esb.cloud-test.wso2.com;
           url_suffix             esb.wso2.com;
       domains   {
           wso2.esb.domain {
               tenant_range    *;
           }
       }
    }

***************************************************************************************
as such all the servers which have axis2 services or any services should be defined with unique url_suffix.

Worker-manager node
================

appserver {
       domains   {
           CharithaASdomain {
               hosts mgt.charitha.appserver.wso2.com;
               sub_domain mgt;
               tenant_range    *;

           }
           CharithaASdomain {
               hosts             charitha.appserver.wso2.com;
                  url_suffix                     as.wso2.com;
               sub_domain worker;
               tenant_range    *;
           }
       
       }
    }

only worker node needs the url_suffix.


AS node setup
==========

by default url-mapping feature is there
So in CARBON_HOME/repository/conf/etc/url-mappings.xml
    * replace url-prefix as “localhost” with “as.wso2.com” which is given in the ELB’s conf as url-suffix for that particular AS node.


Worker_manager node (AS)
====================
Manager node should have the url-suffix defined as in loadbalancher.conf for the worker node.

Worker can be as default.

ESB node setup
===============

install url-mapping feature from p2 repo.
Then as like AS node setup, change the configuration file with relevant url-suffix from ELB conf.


Greg
====

Need to mount Greg’s governance as shared across all the modes.


DNS mapping for a URL-mapping
========================

Have to get a DNS mapping to that particular URL-mapping.

Context Mapping for Applications and Services in WSO2 AS

If you would like to have your own name for a app that you are developing and hosting it with us in Apps server, then here is the way to go. The custom URL will be mapped to the long URL.

You can own a unique domain to your deployed web application in our Apps server. Basically your app can be accessible like http://example.wso2.com rather confusing with a long URL http://appserver.stratoslive.com/t/tenant.com/webapps/example. Here you can configure the suffix ".wso2.com" through a CARBON_HOME/reposiory/etc/conf/url-mappings.xml file. 

The services which hosts in apps server can also be accessible via http://serviceid.wso2.com?wsdl. Also, tryit and rest call could use the same URL.

The short URL is tenant isolated even though it is not having tenant URL pattern. Also, the webapps which could be accessible through short URL will work with:

1.Tenant Lazy loading

2.Ghost Deployment of artifacts

3.Billing and Metering in Stratos

4.Cloud Deployment of AS nodes

The configuration of URL mappings will be slight different in case of stand alone products and in stratos. I'll explain the configuration details in my next post.