Wednesday, May 15, 2019

Integrate WSO2 APIM with ETCD

Overview  


Wide adoption of SOA/MSA influenced modern systems to be disaggregated. These disparate systems need to be integrated together to form a business unit or an application. These systems as a whole are being implemented based on well defined standards/interfaces i.e http, jms which makes it possible to seamlessly integrate. Each interface introduces a way to locate these systems/resources i.e url in the form of an endpoint. These endpoints could change rapidly, i.e ip change etc, which creates a requirement to centrally manage them and to allow services/systems who are connecting with each other to discover them.

The following describes how WSO2 APIM could be integrated with ETCD to dynamically discover the endpoints. The tutorial depicts the following,

  1. A sample service would represent a unit of work which will be done through a warehouse management system.
  2. The services are exposed as rest endpoints, and they could be accessed through the ip and port (localhost, 8090)
  3. Hypothetically let’s consider that the port which the service is running would change from time to time.
  4. Each time the port changes it would not be practical to reflect the change in endpoint to each other service/application which consumes it

Hence, following would demonstrate how the service url could be added as an entry to etcd registry, this entry would be an identifier which will represent the url of the service. Connecting applications will query for the url of this endpoint through the registry instead of directly having to embed the url in the application. The change in the url endpoint should only be reflected in the registry entry. The change will be reflected to the connecting applications without having to apply any changes to the application.

Sample Service


Make sure that Ballerina is downloaded and configured. For detailed instructions please refer here.

A sample mock service could be found here.

Once the service is available, execute the following,



ballerina run abc_warehouse.bal

The above will start the service in localhost:8090, the following message would be prompted in the console as a result,


Initiating service(s) in 'abc_warehouse.bal'
[ballerina/http] started HTTP/WS endpoint 0.0.0.0:8090




ETCD Setup


Make sure that ETCD is running, execute the following



The following response could be observed,

{"etcdserver":"3.3.13","etcdcluster":"3.3.0"}

Insert key into the etcd registry/this could also be used to change the entry

curl http://127.0.0.1:2379/v2/keys/warehouseOrderEP -X PUT  -d value="http://localhost:8090/warehouse/order"

To retrieve the key execute the following,





WSO2 APIM Integration


WSO2 APIM provides the capability to define dynamic endpoints. Using this capability in conjunction with mediation extensions. APIM gateway could be integrated with ETCD registry to dynamically discover the service endpoints. 

The following would be the mediation extension which should be added.



<sequence name="warehouseSvcDiscoverySeq" trace="disable" xmlns="http://ws.apache.org/ns/synapse">
  <log>
    <property name="State" value="Discovery Sequence"/>
  </log>
  <call blocking="true">
   <endpoint>
      <http method="get" uri-template="http://127.0.0.1:2379/v2/keys/warehouseOrderEP"/>
    </endpoint>
  </call>
  <log level="full" />
  <property description="WarehouseOrderEP Value" expression="json-eval($.node.value)" name="WarehouseOrderEP" scope="default" type="STRING"/>
  <log>
    <property name="Discovery Endpoint Value" expression="$ctx:WarehouseOrderEP"/>
  </log>
  <header name="To" expression="$ctx:WarehouseOrderEP"/>
</sequence>

The relevant extension could be downloaded from here.

Testing


After applying the above extension. Invoke the WSO2 APIM gateway endpoint.

curl -k -H "Content-Type: application/json" -X POST -d ‘{"cust_id":"hmart", "delivery":"addr1", "contact":"784-7948754", "item":"A100", "quantity":120}’
http://10.100.0.4:8281/warehouse -v
In the warehouse ballerina service following could be observed,

ABC - Order received

2019-05-15 11:40:20,773 INFO [] - Order placed for Item: A100, quantity: 120. Deliverary to: addr1. Contact: 784-7948754

Change the port in which the ballerina service is running (from 8090 to 9090)

In the ETCD registry entry reflect the port change by issuing the following command,

curl http://127.0.0.1:2379/v2/keys/warehouseOrderEP -X PUT -d value="http://localhost:9090/warehouse/order"

After reflecting the change, invoke the APIM gateway URL. The response should be received.

Recommendations


Follow this post to integrate with Consul.

What’s coming up ?


The tutorial explains how ETCD integration could be done via dynamic endpoints and mediation extensions. WSO2 APIM 3.0.0 release would provide out of the box support for this integration with its Micro Gateway offering, for more information refer here.

Friday, August 10, 2018

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. 

Thursday, August 3, 2017

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.


Monday, February 27, 2017

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.

Sunday, June 12, 2016

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.