In some cases, it makes sense creating a custom URL for WSO2 ESB proxies and WSO2 APIs. Take for instance the use case where you have an Amazon Web Services (AWS) environment. If you do not have an elastic IP address which will stay the same, the IP address will change every time you reboot the machine.
Internally (so internal the Amazon instance) though there will be another IP address on which the services are exposed like http://ip-172-31-16-199.eu-central-1.compute.internal:8280/services/echo.
This IP address is not known outside the AWS instance. If we want to access the services on the ESB we cannot use the address the ESB offers. We need to look at the external IP address and take that address to access the services.
It would be easier to have the services (proxies and APIs) on a (at least neater) address like yenlo.training so the address would be: http://yenlo.training:8280/services/echo
This address can be anything but we use this setting for our Yenlo WSO2 Training virtuals it makes sense.
With the correct settings (i.e. setting the hosts file on both the Amazon instance as well as our own machine, we are able to access the services in a simple and consistent way as well as still have access to the services using the external IP address.
In this WSO2TORIAL we will not go into detail into the Amazon AWS setup and the ESB installation but rather assume you are familiar with these elements. We will setup the ESB configuration as well as our own local machine to access the ESB through a stable hostname that can survive AWS instance reboots.
Setup
The setup is going to be an Amazon (AWS) hosted Centos7 Environment with Gnome Desktop and a Windows based client system to access the services.
We will take an out of the box version of the WSO2 ESB version 5.0.0 and call the Echo service on the ESB usingTry-It from the ESB (or you can use SoapUI)to prove that this setup works.
AWS and ESB
For this WSO2TORIAL purpose we created a simple instance using the Centos7 Package from Amazon and installed all the necessary software on it to run WSO2. Actually and to be more precise, we have our own Amazon Machine Image (AMI) that we can just use to create a new instance. That is easier since we don’t always have to install Java and other software we need to run WSO2.
We do a quick setup of the WSO2 ESB and start it directly after.
Changing /etc/hosts
We first setup our hostname resolution in /etc/hosts. This configuration file allows for a simple DNS-name to IP-address mapping without installing a DNS-server solution on your host. The names setup in this file are only known to the host itself.
We change the setup of the default hosts file by adding yenlo.training to the lists of hostnames linked to the 127.0.0.1 IP address.
If you are proficient with VI you can do that using this command : sudo vi /etc/hosts
In case VI is not you cup of tea you can also use Gnome’s Gedit editor (if you have Gnome installed of course).
This allows the instance to map yenlo.training to the 127.0.0.1 IP-address, also known as localhost. We could also directly map to the internal IP address, in that case you would add another line with the IP address and yenlo.training (e.g. 172.31.7.13 yenlo.training) rather than mapping to 127.0.0.1.
Changing axis2.xml
In order to make the services actually be offered on the new hostname yenlo.training we need to change the axis2.xml configuration file. This file contains the configuration of the transports, listeners and other components that the ESB and other WSO2 products, that use Axis2 and Synapse, utilize.
We made the changes using Gedit in this case, you can also use another editor of course. Please note that the try-it function of the ESB still utilizes the localhost address regardless what we configure here. Of course we use both the HTTP and HTTPS transports.
Changing hosts on the client
We now have a functioning WSO2 ESB version 5.0 available at yenlo.training as hostname but we need to also change the hosts file on the computer that we use to access the AWS WSO2 ESB instance.
We have a windows 10 machine available and we edit our hosts file using Notepad++ or another tool This file is located at C:WindowsSystem32driversetchosts
We add the external IP address of the AWS instance, in our case we assume 35.156.26.132. In real life that IP address will of course be different for your situation.
Once we save the file its changes become effective immediately and we can start testing our setup.
Testing the setup
The proof of the pudding is in the eating, which means that we want to see that both internally (within the instance) as well as externally (using a browser) we can access services on the yenlo.training hostname.
Let us start with the external usecase. We browse to the ESB using the yenlo.training hostname from our Windows 10 client machine.
We can still use the AWS IP address directly as is shown below.
We can also try the echo service and it works!
When we go to the instance itself, using a remote desktop connection and try to access the ESB from a browser on the machine itself, we see that this situation also still works correctly.
Again, we test echo service and it also works.
So there you have it, a custom URL for your proxies that works both internally and externally.
If you have any questions about this blogpost contact us via the comments section of this blog. View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.
