How Ballerina does I/O

Recently i came across this article which i found rather fascinating and thought of comparing how Ballerina does I/O in comparison to other programming languages which were compared in the article .

If you have not read the article before. I encourage you to read it before reading the rest of this post. Since the concepts explained in the article will not be re iterated.

Authors Summary of the Article 

Article mainly compared between the existing I/O capabilities provided by different programming languages (PHP, Java, Node.js and Go). The following table illustrates how the author in the article summarized his findings. 

The author mainly compares between several programming languages on their I/O capabilities and elaborates the importance of programming language supporting Multi-threading over creation of a process, Non-blocking I/O and ease of use (providing transparency for the developers to write code over having to manage callbacks, callbacks were artificially created as a result of non-blocking functionality in some of the programming languages which reduces the ease of use).

The author summarizes in his article how "Golang" provides most of the characteristics required by a programming language to perform I/O operations, in comparison to other programming languages he compared.

Since Golang is the successor. I thought of further evaluating pros and cons of  Golang to really identify it's capabilities and it's global understanding.

Further Evaluation 

Further, beyond the boundaries of the article i came across the following post which describes some of pain points in developers are experiencing in Golang ,

- lack of Vectored-I/O which means, this will not support operations such as scatter-gather. 

- Each time a IO read is performed a buffer is allocated first before performing the sys call. This would however will not guarantee that the read will return by filling the content to the allocated buffer.

To further elaborate this, say you're attempting to read content from a socket. When attempting to read it is expected for content to be present (obviously.. Dha).

There are several approaches to read content, the post explains that in Golang, first a buffer is allocated, sequentially a read() sys call will be called. As stated above bytes might not be present when attempting to read, if there're no bytes the read will return empty. However, allocated buffer remains the same which means increased memory footprint.

So is there an alternative for this ? how can you allocate and perform a sys() calls to read only if the content is present. I will explain further in this post on how Ballerina does this. Again if you have not read the article i encourage you to do so. The author explains how the sys calls work which i will not repeat.

Ballerina I/O Architecture 

Canonicalization

Shown above is an illustration of Ballerina I/O architecture.

I/O or Input/Output is about how a program reads data for processing or writes data after processing. I wouldn't be wrong to say every program involves an I/O operation some way or another either you read from a file process it, write some of the content to a socket or perhaps you do some calculation and write the result to the standard output and the end of the day you would mainly see the following attributes involved.

# I/O sources - these could be files, socket, devices etc basically the entities which you would use to gather or place information which is required by your programs for processing.
# Information - these information are mainly delivered to a program in bytes which is the standard way to represent information
# Interpretation - information or a sequence of bytes (1 or more) could be interpreted differently. In other words byte is basically a number. This number could represent a character in alphabet, pixel in an image, minute detail of an audio clip, state in a traffic light etc. Once a byte is being absorbed or being written into an I/O source. The program basically interprets it's value to perform it's processing these interpretations can commonly be characters, records etc.

Interpretation can be independent of it's source. Whether you get the information from socket, file, standard input it doesn't matter as long as it's the same information. Ballerina I/O architecture revolves around this principal.

So what advantage will it provide ?

say as a developer, you write one program to read from a file and perform it's processing. Say suddenly you're being told that the very same content should be read over the network. so in this case the source would change from file to socket, however the information and the interpretation stays the same. So in Ballerina all you need to change is the source and the rest of the program would work. You will see how when you further identify the semantics/syntax it provides.

Syntax

You could try the samples available in the site to get a broader sense of how to use I/O apis. Following is a pseudo code on how I/O apis look like.

function main(string... args) {
         //Initialize channel/I/O source
         io:ByteChannel sourceChannel = io:openFile(filePath, permission);
         var result = sourceChannel .read(numberOfBytes);
         //Initialize channel/I/O source
         sourceChannel .write(..);   
}

So basically as a developer when you write a program and figure out the I/O source needs to change from file to socket all you need to change is how ByteChannel is initialized from file to socket, in ballerina all the I/O sources will be represented as a ByteChannel.

Going back to the beginning of the post, when compared ballerina with other programming languages compared in the article. Following are some highlights   

# Async model -

Ballerina uses a threading model which will have controlled amount of IO threads, reduced context switches, based on NIO (Non blocking I/O) which will be described further in this article.

# Ease of use -

As you would observe. There're no callbacks. For the developer the non-blocking behaviour is transparent. Which makes it as easy to use as other comparative programming languages which tops the list for ease of use. 

As i mentioned in the beginning of the post, let me illustrate the approach ballerina uses to read content to avoid the limitation of causing additional memory footprint. 

Under the Hood (How it works)

Say you're reading content from a socket. The functional flow looks like the following,

Illustrating thought the syntax highlighted earlier in the post. When the program execution hits the following line,

var result = channel.read(numberOfBytes);

The functional flow looks like the following,

1. When read is called, an event would be registered with a selector (multiplexer which will capture event from Kernal and notify accordingly). At this point no buffers will be allocated and no thread will be hanged or blocked internally. The event would await until it's being notified by the Kernal. 

2. When the specific I/O source writes data to the Kernal buffer. The selector will be notified through the kernal to the user space. Notifying the user space of readiness of data to be read from the buffer from the given channel

3. At this point there is certainty there's data available to be read, hence the selector manager will dispatch read event to IOThreadPool (which is a dedicated thread group that will handle I/O operations in Ballerina), only at this point Ballerina would allocate a buffer. 

4. Data will be read into the newly allocated buffer and once the operation is complete, the next LoC will be executed. The entire operation is natively non-blocking but developer does not need to struggle handling callbacks.

Summary 

The post mainly compared some of the factors considered to evaluate I/O apis offered by different programming languages. The comparison points were derived from article. sequentially some of the pain points of the existing I/O models were discussed. Finally Ballerina I/O architecture was compared against the comparison points discussed in the article and further explained how ballerina addresses some of the commonly known limitations which are even faced by the successor mentioned in article.

I encourage you to try ballerina out yourself. 

What's Special About WSO2 ESB ??

I am a bit late to write this post. Better late than never :)

Why should you consider WSO2 ESB ?

The recently published article will unveil the answer to the question  What is WSO2 ESB?

WSO2 ESB is one of the most matured products in the WSO2 stack, it's scalable, it's fast and it has all the features which will support all your integration needs. This i believe is evident and would be self explanatory if you download it.

How i got started with Ballerina

I am certain most of my friend's would click on the link to see me dancing :)

With the announcement of Ballerina, the new integration language. I thought of writing a quick summary on how i got started. 

Installation 

I downloaded Ballerina from here. Also i referred Installation-instructions to get started.

Writing an EIP

CBR as a very common EIP in the integration world was something i tried out with Ballerina. So here's how i did it.  

Creating a Mock Service in Ballerina

Something i was longing to try out in Ballerina is to be able to write a service which could be executed in the same runtime. So here's how i did it, 

Started the composer, and viola it provided a graphical view for me to represent the service and what it should do and all i had to do was drag and drop a few elements to the canvas. This was like drawing a floor chart. 

the service i created would accept an incoming http message and send a mock respond back. The source view showed the language syntax i could use, here's how that looked like.

import ballerina.lang.messages; @http:BasePath("/gadgets") service GadgetInventoryMockService { @http:GET resource inquire(message m) { message response = {}; json payload = `{"inquire":"gadget","availability":"true"}`; messages:setJsonPayload(response, payload); reply response; } }

Similarly i managed to create both the services ("Widget Inventory" and "Gadget Inventory").

Routing with Ballerina

Just like creating a service i was able to drag an drop a set of elements from the graphical view and create the router

import ballerina.net.http; import ballerina.lang.jsons; import ballerina.lang.messages; @http:BasePath("/route") service ContentBasedRouter { @http:POST resource lookup(message m) { http:ClientConnector widgetEP = create http:ClientConnector("http://localhost:9090/widgets"); http:ClientConnector gadgetEP = create http:ClientConnector("http://localhost:9090/gadgets"); json requestMessage = messages:getJsonPayload(m); string inventoryType = jsons:getString(requestMessage, "$.type"); message response = {}; if (inventoryType == "gadget") { response = http:ClientConnector.get(gadgetEP, "/", m); } else { response = http:ClientConnector.get(widgetEP, "/", m); } reply response; } }

While looking back i realize, it was not only convenient to create the message flow, but it was also easier for me to describe the flow through the diagram. The way it was describing the connections, the message flow and the client as seperate entities (the picture was actually speaking 1000 words :) ). 

Running What I Wrote 

I was excited to see how this diagram, would look like when it's running.

This is all what i had to do,

ballerina run service ./gadgetInventoryMockService.bal ./widgetInventoryMockService.bal ./router.bal

where, gadgetInventoryMockService.bal and widgetInventoryMockService.bal were the mock services i wrote and router.bal is the routing logic. In this case i would've preferred to actually be able to bundle the whole project into one package instead of having to give each an individual file as arguments. I checked on this capability with the team and this will be supported in the near future by the composer. So i'll have my fingers crossed for this. As a result in my local machine each of the bal files were running as a service in the following URLs. The files i used could be found here.

Service	URL
Gadget Inventory Mock Service	http://localhost:9090/gadgets
Widget Inventory Mock Service	http://localhost:9090/widgets
Router	http://localhost:9090/route

So to practically experience how Ballerina routed the requests i did the following, using cURL client i sent the following request, 

curl -v http://localhost:9090/route -d '{"type" : "gadget"}'

The following response should be observed,

{"inquire":"gadget","availability":"true"}

Re executed the request with the following,

curl -v http://localhost:9090/route -d '{"type" : "widget"}'

Then the following response should be observed,

{"inquire":"widget","availability":"true"}

In general there're more components i.e fork-join capability which will be required to implement some of the EIPs i wanted to try out i.e scatter-gather, so tick tock for the next release. However, it was a great experience.

ESB as a Transistor for Protocol Switching Between AMQP and MQTT - Part 2

In the previous post i described how WSO2 ESB could be used to switch between AMQP and MQTT protocols. In that the pattern of having AMQP queue producer and and MQTT as a consumer was discussed. In this post i would be elaborating how a message could be published to AMQP topic and received by both AMQP and MQTT consumers.

2.0 AMQP Topic to MQTT Topic 

Please follow the instruction described in the previous post to setup the environments if it has not being done already.

Usage: Publishing message to AMQP topic and receiving is from both AMQP and MQTT consumers

Message Flow

Use case: This sample demonstrates how a message published to AMQP topic via JMS could be consumed by both MQTT and AMQP topic consumers.

1. Start the ESB server and log into its management console UI (https://localhost:9443/carbon). In the management console, navigate to the main menu and click source view in the service bus section. Next, copy the configuration which could be found in ESBConfiguration.xml
2. Replace the jndi.properties file which could be located in the ESB ($ESB_HOME /repository/conf) directory with jndi.properties.
3. Start two JMeter instances, one which would act as a JMS message publisher and the other which will act as a JMS message consumer. The consumer could be found in AMQPTopicConsumer.jmx and the producer could be found in AMQPTopicPublisher.jmx.
4. Start MQTT fx client and subscribe to the topic ‘TrackLocationMqttTopic’.
5. Execute the Jmeter consumer and producer and observe.

Observation

JMS message which was published to ‘TrackLocationAMQPTopic’ would be received by both the AMQP subscriber who subscribed to the topic ‘‘TrackLocationAMQPTopic’’ and MQTT subscriber who subscribed to ‘‘TrackLocationMqttTopic’”.

JMS Topic Publisher (JMeter)

JMS Topic Subscriber (JMeter)

MQTT Topic Subscriber (MQTT Fx)

Note : Message Broker current version ( < 3.1.0) does not support subscribing to the same topic name with two different protocols. I.e AMQP and MQTT, hence the consumers were subscribed to two different topic names and was correlated through the ESB. however, Message Broker future releases intend to allow the capability to subscribe to a common topic name by different protocols. 

The next two patterns "Publishing to MQTT topic and receiving from AMQP queue consumer" and "Publishing to MQTT topic and receiving from AMQP topic consumer" would discuss the inverse of the two patterns discussed in part 1 and 2. Will elaborate these patterns in the upcoming days. 

ESB as a Transistor for Protocol Switching Between AMQP and MQTT - Part 1

In my previous post, i discussed how both protocols AMQP and MQTT could be of use for different enterprise requirements. Both protocols has its own advantages, in my opinion AMQP could be more robust over MQTT due to its maturity, however MQTT would outperform AMQP to its lightweight nature making the protocol more suitable for applications intended to be executed in low powered and constrained network environments. 

Due to the potential of both the protocols the apparent question would be the possibility of using both of them. Could this be achieved ? the simple answer would be yes. The following post would discuss in a series on how this could be achieved using both WSO2 ESB and MB.   

Transistor is typically used to switch electronic signals (typically between hight powered circuits to low powered once) i would like to apply that term to describe how WSO2 Enterprise Service Bus could act as a transistor to allow switching between both the protocols (AMQP protocol and MQTT) supported by WSO2 Message Broker, imagining the use case of an enterprise having AMQP as the high powered source and MQTT as the lightweight source deployed on devices running in constrained environments. 

I would like to describe 4 patterns which could be followed when protocol switching,

1. Publishing to a AMQP queue and receiving from MQTT topic consumer
2. Publishing to AMQP topic and receiving from both MQTT and AMQP topic consumers. 
3. Publishing to MQTT topic and receiving from AMQP queue consumer 
4. Publishing to MQTT topic and receiving from AMQP topic consumer

The above patterns would be described in a generic fashion which could be implied to various use cases,

Setting Up

Prerequisites 

• Download WSO2 MB and  WSO2 ESB from the website. (Also note i used WSO2 ESB 4.9.0 and WSO2 MB 3.1.0 for this post)
• To send/receive AMQP messages via JMS we use apache JMeter.
• To send/receive MQTT messages we use MQTT Fx as the client.

Configuration 

• Enable MQTT Transport sender and receiver in the ESB.
• Enable JMS Transport sender and receiver in the ESB.
• Copy the MB client libraries from $MB_HOME/client-lib to $JMeter_HOME/lib/ext and also copy the client libraries to $ESB_HOME/repository/components/lib/
• Create the jndi.properties file and add the following to it. Make sure to track the url of the jndi file location. This location should be replaced in the ‘Provider URL’ of the jmeter script file. The jndi file could be found in jndi.properties.
• Startup MB server. Make sure the MB server is running on its default offset.
• Startup ESB server. Make sure that you offset the ESB by 1.

1.0 AMQP Queue to MQTT Topic

Usage : Publishing message to AMQP Queue and consuming the message from MQTT client.

Message Flow

Use Case : This sample demonstrates how a message published to AMQP queue via JMS could be consumed by an MQTT consumer.

1. Start the ESB server and log into its management console UI (https://localhost:9443/carbon). In the management console, navigate to the main menu and click source view in the service bus section. Next, copy the configuration which could be found in ESBConfiguration.xml .
2. Replace the jndi.properties file which could be located in the ESB ($ESB_HOME /repository/conf) directory with jndi.properties.
3. Start JMeter and import the script file AMQPQueuePublisher.jmx.
4. Start MQTT fx client and subscribe to the topic ‘LocationTrackerTopic’.
5. Execute the Jmeter script and observe.

Observation

The JMS message which was published to the LocationQueue should be received by the MQTT client consumer who is subscribed to LocationTrackerTopic.

As illustrated below in the screenshots,

JMS Client (JMeter)

MQTT Client (MQTT Fx)

Next post would describe the pattern of having AMQP topic producer distributing messages to both AMQP and MQTT consumers. 

What would you chose AMQP or MQTT ?

WSO2 Message Broker currently supports both AMQP and MQTT protocols. whether to use AMQP or MQTT was a frequent question i came across. The answer would subjective in my opinion, in simple terms both protocols has its own advantages, hence i would like to share a few of my findings on various strengths of both these protocols.

	AMQP	MQTT
Large Messages Transmission	Uses buffer oriented approach and supports fragmentation, hence it’s more suitable in comparison	Stream oriented protocol, does not support fragmentation. Hence more suitable for smaller size messages
Message Exchanges	Supports both topics and queues, suitable for long lived messages	Optimized for active routing, publisher-subscriber based.
Transactional Support	Supports different level of transactions and acknowledgment modes i.e distributed XA transactions, client acknowledgement, auto acknowledgment	Supports three acknowledgment modes. Specifically focusses on exactly once delivery
Connection Security	Supports standard TLS through SASL.	Supports basic auth and SSL. Security is embedded into the protocol itself. This requires security changes to be included in the protocol itself.
Last value queues	Does not support explicitly	Supports this in the form of RETAIN flag.
Reliable Messaging	Supports reliability using different acknowledgment modes and session durability	Supports reliability using different acknowledgment modes and session durability
Failover	Supports native failover	Need to support failover explicitly

Depending on the enterprise needs the above selection of protocols could defer, AMQP is a more matured protocol in comparison to MQTT and its readily available for the use of enterprise requirements, however AMQP is more heavy weight than MQTT which makes it less suitable for devices running in low powered and constrained network environments.

What if you want to use both these protocols? I would be discussing on how protocols could be switched in my next post.