Simple HTTP Proxy Service With UltraESB-X

DZone 's Guide to

Simple HTTP Proxy Service With UltraESB-X

Learn how user-friendly it is to work with UltraStudio's new ESB, UltraESB-X, and check out some of its use cases for integration flows.

· Integration Zone ·
Free Resource

I recently tried out the AdroitLogic UltraStudio which is currently an alpha release. UltraStudio is AdroitLogic’s latest product which was released in January 2017. Their previous ESB, known in the name UltraESB was there for around 6 years offering a high level of performance and higher reliability while being a lightweight ESB. While preserving those renowned qualities UltraESB's successor, UltraESB-X is coming out with a new design and with a very user-friendly, easy to use user interface which is an IntelliJ Idea plugin. I will give you a brief idea on how it was like to work with UltraStudio for the first time and will show you some use cases of UltraESB-X.

UltraESB-X – Design Overview

UltraStudio came out with the concept of Projects. A project can have multiple Integration Flows, which represent possible message flows. That is, an Integration Flow will have the following components:

  • Egress Connector – This is the connector responsible for sending messages out of the Integration Flow. As in the ingress connector, the egress connector will make use of the underlying transport sender implementations like HTTP sender, JMS sender, etc.
  • Ingress Connector – This is the component which will be seen by the users. If a user wants to use an HTTP listener, the user has to drag and drop an HTTPIngressConnector into the integration flow and configure its listening port. In the runtime, the connector will take the necessary steps to build and start an HTTP transport listener if there is not a transport listener listening on the given port.
  • Transport Listener – This is the underlying transport listener which is actually listening to requests coming to a given service path, files coming to a given directory, or messages coming to a given message queue. There are different types of underlying transport listeners depending on the underlying transport we are willing to use. Examples are HTTP, HTTPS, FTP, SFTP, and JMS transport listeners. The users will not directly see these listeners. Instead, ingress connectors are the entity responsible for offering the functionalities of the underlying transport listeners.
  • Processing Element – These are the elements in an integration flow responsible for processing messages. A processing element can be there to add a header to a message, to convert XML payloads to JSON payloads, and much more.
  • Transport Sender – This is the underlying transport sender responsible for sending messages out of the server. Therefore, there can be multiple egress connectors sharing the same transport sender if all those egress connectors want to send messages to the same endpoint.

In order to see how user-friendly UltraStudio is, I decided to try out some common scenarios expected to be fulfilled by an ESB (Enterprise Service Bus). Acting as a proxy server is one such common use case. In the first section of this article, I will explain to you how I have setup an HTTP proxy service using UltraStudio. Then I will explain to you how I configured it to work with HTTPS along with 2-way SSL.

What Is a Proxy Service?

A proxy service can be considered another computer/server which lies in between the client and the actual endpoint. In the most common scenario, proxy servers are configured at the gateways of local area networks. Therefore, they are covering up the actual identities of the clients in an internal network from the outside networks, most probably from the internet.

The other type of proxy servers is used closer to the servers, where the proxy server acts as a gateway to the internet, hiding an internal network of enterprise servers. We do not hear about them in day-to-day life. These type of proxy servers are used for security, scalability, high availability, and load balancing purposes. UltraStudio provides convenient methods to implement this type of proxy services.

Here We Go…

Step 1 - What Else…You Need a Project

To create an UltraStudio project, you need IntelliJ Idea community edition installed and you need to install the AdroitLogic UltraESB Studio plugin. Once done, go to File -> New -> Project. You will then get the following window:


As shown in the above figure, select an Empty Ultra Project. Then, you have to specify some parameters like artifact ID and group ID for configuring the Maven project being created.


Then, you have to select the connectors required for your project. Since I only need the HTTP connector, I have selected the NIO HTTP Connector only. Of course, you can add more connectors later when you start building the integration flows through the UI.


Now for the processing elements known as processors. You can select as many of these inbuilt processing elements which will be used in your project. Also, you can write your own processing elements in a project in order to process the messages.


Now we are one step away from starting to work on our project. Next, you have to give a project name and a location for the project. Then we are good to go.


Step 2 – Our First Integration Flow

Now we are going to build our first integration flow, which is going to be a proxy service.


The above figure shows the new project's structure. This is equivalent to the Maven project structure except that there is a conf directory in src/main. In fact, this is a Maven project. We usually create integration flows in the conf directory. Just right click on that directory and select New -> Integration Flow. Then, give a name to the integration flow (say "http-proxy"). Then a new file is created in the name http-proxy.xcml, which is where we are going to design our integration flow.


The above figure shows what it will contain when you open the http-proxy.xcml file. Wait…where's the so-called user friendliness? It is there, in the Design tab in the bottom left corner. Let's go there. There we are in our working space. All the connectors and processors we selected when we were creating the project are listed in your left-side pane.


Now, it's playtime…Wanna drag some pictures and draw some arrows just as we used to when we were kids? Here we go.

We are now going to draw our integration flow. What does a proxy need? Yes, it has to listen for incoming HTTP requests. Then it has to send those requests to the actual endpoint. In between, we may need to log the request details for audit purposes. That means we need an ingress connector, a processing element which can log and an egress connector which can send requests to the actual endpoint. Therefore NIO HTTP Listener will be your ingress connector and NIO HTTP Sender will be your egress connector.

First, we will drag and drop the NIO HTTP Listener. Once we drop it, a pane will appear from below asking the port and the service path of the connector. Here, the port means the port on which the underlying listener (of the connector) will be listening. As I mentioned earlier, multiple connectors can share the same underlying listener when all those connectors want to listen on the same port. The service path is the suffix of the URL in which this connector is interested in. For example, if your connector's port is 80 and your domain name is "mydomain.com," the service path of the request mydomain.com:80/test/my_resource is /test/my_resource. So, this is how it will look once you are done with the connector. There are also some advanced configurations that can be done in the pane below. I will leave it up to you to explore.


That completes the listening part of our integration flow. Now the processing part. What do we need to do when we receive a request? Let's assume we need to add an authentication header. Drag and drop a new Processors -> Generic -> Add New Transport Header element and fill in the header details, as below.


Now, the NIO HTTP Sender for the egress connector. In this element's configuration, you have to specify the endpoint details including the hostname, port, and service path to which the requests are forwarded. I have used an online JSON hosting API for this example, so I want to direct my requests to https://api.myjson.com/bins/54nmo, which will return a "{"status":"success"}" JSON string as a response.


Now, all we have to do is connect these elements with arrows. The processor (top most white dot) of NIO HTTP Listener has to be connected to the input (grey dot on the left side) of the processing element. The next (white dot on right) has to be connected to the input of the NIO HTTP Sender. Finally, since we need to send the response back to the client, the sender's Response Processor has to be pointed to the input of the NIO HTTP Listener. Now we are done.


That is our first integration flow. Note that I haven't connected the red dots of any element, which are to process any error situation when receiving, processing, or sending requests, in order to keep this introduction simple.

If you are curious, you can go and see what has happened to the text in http-proxy.xcml, which is the other tab. It will be like below. What UltraStudio has done is to make everything simple for the user to design and visualize his/her design.


Step 3 – Does It Work?

Let's see if it works. First, you have to build your Maven project. Go to the terminal and run mvn clean install to build the maven project. To run this project, you have to add a new run configuration. Go to run/debug configurations and add a new Ultra Server. The configuration details will be auto-filled. All you have to do is run the newly created configuration. When you run it, you will see a set of log lines saying several components corresponding to your project have started. It will also say that out NIO HTTP Listener has started on the port we gave.

Now, we have to send a request to the NIO HTTP Listener which we configured. To do that, you can use the Ultra Studio Toolbox plugin. Open it and add a new HTTP/S Client. Then, fill in the URL to which we want to send the request. In this example, we setup the listener to listen on port 8280. Therefore, the proxy's URL is http://localhost:8280/test. Remember the service path we gave, /test.


Now just send a GET request and wait for the response. If you followed this article correctly, you should have gotten the same correct response as me.

What's Next?

I just explained to you how to set up an HTTP proxy service. You can do the same with HTTPS using the corresponding connectors. I will leave it up to you. When you are configuring HTTPS, you need to do some additional configurations like providing truststore paths and identity store paths. Go on, it will be fun. Thanks for following this article.

ultraesb ,integration ,proxy service ,esb

Published at DZone with permission of Imesha Sudasingha . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}