Using Kaazing WebSockets with MQTT

In my prior post, Adding Enterprise Features to a Socket.io Application with Kaazing WebSockets, we looked into moving from an existing Socket.io application to an Enterprise-class WebSocket application with very few changes in the code. In that example, we used an AMQP broker with the Kaazing JavaScript AMQP libraries.

While AMQP is a very powerful protocol, it requires some knowledge and understanding—a developer has to learn about exchanges, queues and so on. For mobile applications, there are added considerations of bandwidth and battery life. This is why Facebook chose the simple, yet powerful, MQTT protocol for their messenger (see Building Facebook Messenger).

In this post we will demonstrate how to make an existing AngularJS application using MQTT. To build this demo, we will use an existing Open Source MQTT library, Eclipse Paho, and demonstrate how to make it communicate over WebSocket using Kaazing WebSocket Gateway.

Let’s Start with a Working Socket.IO App

Similar to what we did in my prior post, we are going to start with my AngularJS implementation of the canonical TodoMVC application that uses Socket.IO – we will start with the code from here.

We’ve modified the code of the existing TodoMVC app (a detailed discussion can be found here) adding the following steps (final code can be found here):

  1. Connect to Socket.io.
  2. Once connected, load the initial state of TODO items (send the message to the server asking for the initial state).
  3. Set up a callback to process received messages using the function  $scope.processReceivedCommand.
...
$scope.loadData=function(){
        var msg={
                command:"init",
                client:$scope.client
        }
        $scope.socket.emit("todomvc-rcv", msg);
        $log.info("Sent initialization!");
}
...
// Connect to pub-sub service
$scope.socket=io();

// Load initial data on connect
$scope.socket.on("connect", $scope.loadData);

// Setup receive callback
$scope.socket.on("todomvc-snd", $scope.processReceivedCommand);
...

We also added code to notify everyone about any changes in the state of the items. For example, when a new item is created we will execute the following:

...
var msg={
                command:"insert",
                item:
};
$scope.socket.emit("todomvc-rcv", msg);
...

Server side NodeJS component is exactly the same as in our prior sample. The component contains code to connect to Socket.IO, receive the new state of TODO items, and provide the new clients with initialization info by sending the message back using mostly the same code as in the client:

...
function processMessage(cmd) {
        console.log("Command: " + cmd.command + ", Received: " + cmd);
        if (cmd.command === "insert") {
                ...
        }
        else if (cmd.command === "remove") {
                ...
        }
        else if (cmd.command === "update") {
                ...
        }
        else if (cmd.command === 'init') {
                var retCmd = {
                        command: "initdata",
                        client: cmd.client,
                        items: todos
                }
                socket.emit("todomvc-snd", retCmd);
        }
}

io.on('connection', function(s){
        console.log('a user connected');
        socket=s;
        s.on('disconnect', function(){
                console.log('user disconnected');
        });
        s.on('todomvc-rcv', processMessage);
});
...

Now we can run and test the application. For detailed instructions, see README.MD

Now… Adding MQTT to an existing Socket.IO with Kaazing APIs

Before we start changing the code, we need to set up the Gateway and a message broker. While any MQTT broker will do, for the sake of simplicity we will use Eclipse Mosquitto, a very popular and easy to use tool.

Also, we will use the open source Kaazing WebSocket Gateway 5.0. We simply need to add the necessary configuration to the Gateway for it to talk to an MQTT broker.

As you can see in provided gateway-config.xml file, we need to create a proxy service that will deliver all the messages received via WebSocket to a listening MQTT broker. The proxy service accepts the WebSocket messages on URL ws://${gateway.host}:8080/mqtt and delivers the payload to tcp://localhost:1883 where the MQTT broker is running.

<gateway-config>
        ...
        <service>
                <name>mqtt-proxy</name>
                <accept>ws://${gateway.host}:8080/mqtt</accept>
                <connect>tcp://localhost:1883</connect>
                <type>proxy</type>
                <cross-site-constraint>
                        <allow-origin>*</allow-origin>
                </cross-site-constraint>
        </service>
        ...
</gateway-config>

As I mentioned earlier, we are going to use a very common open source MQTT library named Eclipse Paho to communicate with the Gateway.

Modifying Client Code

To use Eclipse Paho to communicate with the Gateway, we are going to follow the sample as shown at the Paho JavaScript Library page. Here are the steps we need to take in the main controller:

  • Configure the browser to use the Kaazing API:
...
window.WebSocket = Kaazing.Gateway.WebSocket;
...
  • Connect to the Gateway and establish all callbacks (replace $scope.socket=io() and all $scope.socket.on calls)
    • Create an instance of a client. The last parameter is a unique client ID
      ...
      $scope.mqttClient = new Paho.MQTT.Client($scope.host, $scope.port, $scope.client);
      ...
      

      As we mentioned before, the Gateway must be bound to the IP of our station. We cannot simply bind it to localhost as Raspberry PI won’t be able to connect (mentioned later in the article). To deal with the bind, we will pass a port as part of URL and read it with the following code:

      ...
      var hostPort=window.location.search.replace("?", "").split("&")[0];
      $scope.host=hostPort.split(":")[0];
      $scope.port=parseInt(hostPort.split(":")[1]);
      ...
      
    • Establish a callback for the loss of the connection
      ...
      $scope.mqttClient.onConnectionLost = function(responseObject){
              if (responseObject.errorCode !== 0) {
                      alert("Connection is lost!"+responseObject.errorMessage);
              }
      }
      ...
      
    • Establish a callback to process arriving messages.
      ...
      $scope.mqttClient.onMessageArrived = function (message) {
              $log.debug("Message Arrived: from "+message.destinationName+":"+message.payloadString);
              var cmd=JSON.parse(message.payloadString);
              if (cmd.clientID!==$scope.client){
                      $scope.processReceivedCommand(cmd);
              }
      };
      ...
      

      Note: we have to prevent the client from processing the messages it sent. To accomplish this, we are going to add the clientID attribute to every message so we can compare it with the ID of the receiving client. If the ID is the same, the message will be ignored.

    • Establish a connection. Within the callback function that will be called when connection is established, we will subscribe to the topic to receive the data and request initialization data:
      ...
      $scope.onConnect=function () {
              $scope.mqttClient.subscribe(TOPIC_SUB);
              $scope.loadData();
      }
      
      // connect the mqttClient
      $scope.mqttClient.connect({onSuccess:$scope.onConnect});
      ...
      
  • Replace $scope.socket.emit with  the function to send a message
    ...
    $scope.sendMessage=function(cmd){
            cmd.clientID=$scope.client;
            var message = new Paho.MQTT.Message(JSON.stringify(cmd));
            message.destinationName = TOPIC_PUB;
            $scope.mqttClient.send(message);
    }
    ...
    

Note: We no longer need to use different topics for publishing and subscribing. The Gateway will send published messages to all subscribed clients without the need to retransmit them in the server code!

Server Code Changes

To preserve our server-side code we are going to use theKaazing Socket.IO Wrapper for MQTTlocated in the node subdirectory of the TodoMVC implementation.

The wrapper hides the details of the MQTT protocol implementation while exposing the interface that mimics the one used in Socket.IO.

With our Socket.IO wrapper, we only need to make two changes on the server:

  • Change both send and receive topics to todomvc
  • Remove the code that retransmits messages

See https://github.com/kaazing/tutorials/blob/develop/mqtt/javascript/serverwsnoiot.js for the final server code implementation.

Now we can test our application by:

    1. Starting the application:
      $node serverwsnoit.js
    2. Opening multiple browsers and pointing them to http://localhost:3000/?<gateway host:gateway port>, e.g. http://localhost:3000/?192.168.6.153:8080

Connecting to the World of IoT

Now we have a Web application running over MQTT—the protocol that is widely-used in the Internet of Things (IoT) world. With that in mind, we can integrate our application with IoT devices; for example, to help with predictive maintenance.

Let’s outline a use-case:

  • There is a device that periodically reads the data from a mechanical sensor and sends it to a particular MQTT topic. Given that the sensor is mechanical, it has to be serviced after every X reads.
  • When the service is required, we need to:
    • Turn on perform maintenance light on a device.
    • Add an entry to our TODO application to request that the service be performed.
  • Once the service is complete and the TODO item is checked, we need to turn the maintenance light off.

To illustrate this scenario, we are going to use Raspberry PI 2 as a remote device with an LED simulating a maintenance light and a button playing the role of a mechanical device that reads the data. The following diagram illustrates the architecture of our application.

MQTT-architecture

Wiring and Electronics

Raspberry PI is an excellent little computer that runs Linux. More importantly, there is easy access to what’s called GPIO pins: a set of generic pins on an integrated circuit whose behavior—including whether it is an input or output pin—is controllable by the user at run-time.

As shown in the circuit diagram below, we are going to wire an LED to one GPIO pin and the button to another GPIO pin:

MQTT-wiring
The following picture demonstrates the complete wiring implemented using Vilros Raspberry PI Ultimate Starter Kit.

Raspberry-MQTT

Important note on the wiring: If you noticed, our circuit diagram indicates the use of GPIO 0 and GPIO 2. Actually, we wired our button and LED to the pins marked as GPIO 17 and GPIO 27. The reason for this is the GPIO pin numbers shown on the Vilros board use BCM GPIO while the Raspberry PI GPIO access library uses an abstract pin numbering scheme to help insulate software from hardware changes. The following article explains this in detail as well as provides a diagram to find the matching GPIO pins.

Programming Raspberry PI

To make things simple, we are going to write a Java application using an open source Pi4J library to interact with GPIO and the Paho MQTT Java library to communicate with Kaazing WebSocket Gateway.

Interacting with Raspberry PI GPIO

As shown on Simple GPIO Control using Pi4J example, turning the LED on and off is rather simple:

...
// Create an instance of gpio
final GpioController gpio = GpioFactory.getInstance();
// Provision pin 2 for output with initial state as ‘low’ - meaning off
final GpioPinDigitalOutput lightPin02 = gpio.provisionDigitalOutputPin(RaspiPin.GPIO_02, "Pin2", PinState.HIGH);

// Set the state to low (off) when the application quits
lightPin02.setShutdownOptions(true, PinState.LOW);
...
// Turn light on
lightPin02.setState(PinState.HIGH);
...
// Turn light off
lightPin02.setState(PinState.LOW);
...

The following GPIO State Listener Example using Pi4J illustrates how to receive the events from the button:

...
// Create an instance of GPIO
final GpioController gpio = GpioFactory.getInstance();

// Provision GPIO pin 0 for input with its internal pull down resistor enabled
final GpioPinDigitalInput button = gpio.provisionDigitalInputPin(RaspiPin.GPIO_00, PinPullResistance.PULL_DOWN);

// Create an event listener
button.addListener(new GpioPinListenerDigital() {

        @Override
        public void handleGpioPinDigitalStateChangeEvent(GpioPinDigitalStateChangeEvent event) {
                if (event.getState() == PinState.HIGH) {
                        // if event goes back to high (button pushed and released)
                        ... do something
                }
        }
});
...

See the Pi4J – Usage for more information.

Communicating with Kaazing WebSocket Gateway

Similar to the JavaScript case, we need to instruct the Paho MQTT library to use Kaazing Java WebSocket API. Implementing it in Java requires a little more work. We are going to use the same technique as implemented in Inventit MQTT over WebSocket library, except we will use the Kaazing Java WebSocket API instead of Jetty.

Here is what we are going to do:

Using the samples illustrated in http://www.hivemq.com/blog/mqtt-client-library-encyclopedia-eclipse-paho-java we connect and communicate with Kaazing WebSocket Gateway:

...
final KaazingMqttWebSocketClient client=new KaazingMqttWebSocketClient(brokerUrl, clientId);
client.connect();
client.setCallback(new MqttCallback() {
            
        @Override
        public void messageArrived(String topic, MqttMessage message) throws Exception {
                ... process received message
        }
            
        @Override
        public void deliveryComplete(IMqttDeliveryToken token) {
                // TODO Auto-generated method stub                
        }
            
        @Override
        public void connectionLost(Throwable cause) {
                LOG.error("Connection is lost: " + cause.getMessage());
        }
});    
client.subscribe(topicListenName, qos);
...

Sending messages is also very easy:

...
client.publish(topicPublishName, new MqttMessage(commandText.getBytes()));
...

Putting it All Together

Now, when we have all the components, we can put it all together:
We are going to use JSON text messages to communicate with our server:

  • Each click results in a {“button”:”click”,”clientId”:”pi1″} message being published on the topic /Devices/status.
  • Clients subscribe to the topic /Devices/command to receive maintenance notifications; the server sends commands {“clientId”:”pi1″,”maintenancelight”:”on”} or {“clientId”:”pi1″,”maintenancelight”:”off”}, which results in the LED on a specific client being turned on or off.

Our client application takes two parameters: the URL for the Kaazing WebSocket Gateway and the client ID that should be assigned to it. See https://github.com/kaazing/tutorials/blob/develop/mqtt/java/raspberry-mqtt/src/main/java/com/kaazing/mqtt/pi/Application.java for the final implementation.

Adding Predictive Maintenance Logic to NodeJS server Component

To track devices we use a devicesarray. For each device we keep a clientId, current number of clicks, and the ID of a TODO item that will be created or updated when the device needs maintenance.

Our processDeviceMessage function searches for the device in the devices array. If the device is found, we increment the number of clicks; otherwise, we create a new device entry.

Once the device clicks counter reaches a maxClicks number (in our case we set it to 10), we do the following:

  • Try to locate TODO item using the TODO item ID that is associated with the device. If the item is located, we uncheck it and send an update message to the todomvc topic; otherwise, we create a new item and send an insert message to the todomvc topic.
  • Send a maintenance light on message to a device.
...
function processDeviceMessage(cmd){
        var deviceInfo=devices[cmd.clientId];
        if (deviceInfo==null){
                deviceInfo={counter:1, itemId:getRandomInt(1, 100000), clientId:cmd.clientId};
                devices[cmd.clientId]=deviceInfo;
                console.log("Registering new device:"+cmd.clientId);
        }
        else{
                deviceInfo.counter++;
                console.log("Updating device:"+cmd.clientId+", new counter="+deviceInfo.counter);
        }
        devices[cmd.clientId]=deviceInfo;
        if (deviceInfo.counter>=maxClicks){
                var exists=false;
                var item=-1;
                for(var i=0;i<todos.length;i++){
                        if (todos[i].id===deviceInfo.itemId){
                                item=i;
                        }
                }
                if (item<0){
                        var newTodo = {
                                id: deviceInfo.itemId,
                                title: "Perform maintenance on "+deviceInfo.clientId,
                                completed: false,
                                busy: false
                        };
                        todos.push(newTodo);
                        var cmd={command:"insert", item:newTodo, clientID:"server"};
                        socket.emit("todomvc", cmd);
                }
                else{
                        todos[item].completed=false;
                        var cmd={command:"update", item:todos[item]};
                        socket.emit("todomvc", cmd);
                }
                socket.emit("/Devices/command", {clientId:deviceInfo.clientId, maintenancelight:"on"});
        }
}
...

Now we need to add another subscription to our NodeJS component. We need to subscribe to /Devices/status to receive messages from devices about the clicks that will use our processDeviceMessage function:

...
io.on('connection', function(s){
        console.log('a user connected');
        socket=s;
        s.on('todomvc', processMessage);
        s.on('/Devices/status', processDeviceMessage)
});
...

The next step is to add the code to turn the light off when the item about device maintenance is checked. We are going to add the code to the processMessage function for the item update message processing case.

...
function processMessage(cmd) {
        ...
        else if (cmd.command === "update") {
                var index = -1;
                for (var i = 0; i < todos.length; i++) {
                        if (todos[i].id === cmd.item.id) {
                                index = i;
                        }
                }
                if(todos[index].completed!=cmd.item.completed) {
                        for (var key in devices){
                                var deviceInfo=devices[key];
                                if (deviceInfo.itemId=cmd.item.id){
                                        if (cmd.item.completed){
                                                deviceInfo.counter=0;
                                                socket.emit("/Devices/command", {clientId:deviceInfo.clientId, maintenancelight:"off"});
                                                devices[deviceInfo.clientId]=deviceInfo;
                                        }
                                        else{
                                                socket.emit("/Devices/command", {clientId:deviceInfo.clientId, maintenancelight:"on"});
                                        }
                                }
                        }
                }
                todos[index] = cmd.item;
        }  
        else {
                ...
        }
}
...

If the item’s completed status changed, we try to determine whether this item is about the maintenance of a particular device. We iterate through the array of the devices, matching the id of the TODO item with the TODO item ids associated with the devices. If a device is found, we send a maintenance light on or off command based on the checked or unchecked state of the item.

As mentioned earlier, the MQTT protocol does not have no local feature, although no local is being considered for a future version. In other words, if the client publishes and subscribes to the same topic, it will receive its own messages, which in our case is not desireable. Similar to the browser code, the server also needs to check whether the message received is not one of its own. In order to check, it does the following:

  • Every message that server sends to the todomvc topic has clientID set to server; for example:
    ...
    var cmd={command:"insert", item:newTodo, clientID:"server"};
    socket.emit("todomvc", cmd);
    ...
    
  • We then add the check to processMessage function
    ...
    function processMessage(cmd) {
            if (cmd.clientID==="server")
                    return;
            ...
    }
    ...
    

Application in Action

Let’s build and start all of the components of our application using instructions specified at https://github.com/kaazing/tutorials/tree/develop/mqtt.
This video shows an application in action.

Conclusion

Its very easy to use the MQTT protocol and Kaazing WebSocket Gateway to upgrade an Socket.IO application and add WebSocket capabilities to IoT devices that use MQTT. Few changes to your existing code are needed and you can use open source MQTT libraries to work directly with Kaazing WebSocket Gateway.  Not only do you now get high-performance, advanced security, and scalability features, but Kaazing technology will extend your MQTT applications to work with mobile and Web clients and many B2B and behind-the-firewall solutions.

Posted in Featured, IoT, Kaazing, WebSocket | Tagged , , , , , , , , | Leave a comment

Stop Using the WebSocket API

KWICies #008
How to Reinvent the Wheel to Run Yourself Over

“Those who cannot remember the past are condemned to repeat it.” – George Santayana
“If I’m not back in five minutes, just wait longer.” – Ace Ventura

hamster.jpg

Ever since its standardization back in 2011, the popularity of WebSocket for live, real-time websites, reactive frameworks and streaming APIs has grown rapidly.  Stackoverflow is buzzing with the geekosphere seeking answers and suggestions on real-time architecture, thorny issues, mental blockers or just best practices for this IETF wire protocol and W3C-blessed API.

But many of these questions have a surprisingly, very common theme.

First, how would you answer this question:

I just learned about TCP today.  Does anyone know how I can implement a message-passing subsystem with TCP?

I’ll get a coffee while you ruminate…

caffeine-molecule.png
Funny… I ordered a latte…

 

You smartly respond with “Why would anyone consider writing low-level TCP code to implement something that was created years ago and already works well?

Yep, exactly.

Most programmers on the planet are application developers.  Yes… you, the one with the Earl Grey tea stain on your blue shirt.  I’m talking to you.  The goal of an application programmer is to write useful programs for users.  Quickly.  And soon as you complete your application and high-five a group of happy users, these audacious users want enhancements (the nerve!) to the app or even worse… they want more apps!  Being agile just doesn’t really describe our lives nowadays.  We need to be hyper-accelerated beings; like the Scalosians (ok, so I’m an old-school trekkie).  

All of us need high-level tools, libraries and frameworks to be productive at writing applications.  Yes, it’s interesting and useful to understand how it works under the hood, but right now you need to deliver an app to a group of waiting users.  You do want to go home at the end of the day don’t you?

pipeline.jpg
A Persistent Connection

Now our old friend the WebSocket is a low-level transport protocol.  This wire protocol was well-defined bit for bit by the IETF in a standard (RFC 6455) back in December 2011.  It is a peer protocol to HTTP.  This means both WebSocket and HTTP (and their TLS/SSL encrypted versions) are physically implemented using TCP.  In addition, there is an official W3C JavaScript API standard to use the protocol.  There are many other language implementations that mimic this official API.  You can easily find Java, Android, Objective-C/Swift-iOS, C#/.NET, C/C++, Python, Go, Haskell, Clojure, Ruby and Erlang bindings.

At this point WebSocket is ubiquitous.  

So is TCP.

But… when was the last time you called recvmmsg() on a Linux machine to setup TCP connection timeouts, juggle the bits in a poll() for I/O multiplexing in an effort to get asynchronous messaging, or develop some makeshift monitoring system to detect a broken TCP connection?  Using these low-level routines is tedious and difficult to get correct.  So system programmers developed high-level abstractions to make it easier for application developers to create useful programs for actual users (oh yes, “them”).  Providing high-level libraries allowed us to focus on the application semantics and develop robust, reliable apps faster.

This aha moment happened over 30 years ago while bands like REO Speedwagon played endlessly on music television.  And yes, that was very, very, very painful.

So now we have WebSocket, a persistent connection over the web.  The API that wraps the protocol seems quite simple enough to use.  There are only a few API calls.

ws.png

How hard can it be, right?  There’s even a really good hello-world implementation that you can cut-and-paste into a working app on websocket.org and immediately test it.  Yep, piece of cake.

But if it’s so simple, how come we see these types of WebSocket questions on Stackoverflow:

  • “I have 1,000 clients connected to my server.  How can I direct certain messages to specific clients using WebSocket?”
  • “How can I make sure I receive exactly the same bytes that I send over WebSocket?”
  • “My server is sending one large JSON payload across multiple WebSocket frames.  How can parse my JSON properly?”
  • “What is the best way to implement different chat rooms with WebSocket?”
  • “How can I guarantee a WebSocket message is received?”
  • “I am receiving WebSocket messages out of order.  How can I prevent this from occurring?”
  • “How do I slow the sending speed of data sent via WebSocket to mobile devices in spotty coverage areas?
  • “My onMessage() is getting multiple responses from many client apps.  How can I tell which WebSocket message belongs to which sender?”
  • “I’m sending a file over WebSocket.  If there is a disconnection during the transfer, how can I restart from where I left off?”
  • “What is the best way to detect if a person is online and available for a chat session with WebSocket?

 

There are many other WebSocket questions similar to these on Stackoverflow and other techie forums.  

Now here’s an exercise.  Replace “WebSocket” with “TCP” in most of those questions.
You sit motionless and stroke your long, white, virtual beard for several minutes…

archimedes.jpg

 

“Weren’t all of these questions basically answered decades ago?!!”  you shout back to the embodied voice in this document while raising the attention of everyone on your morning commuter train.

The simple fact is the WebSocket API was not intended for the average application programmer.  Just like TCP, WebSocket is a low-level transport.   Application protocols that power publish/subscribe, chat, database transactions, tuple spaces, telemetry, data acquisition, system monitoring and other high-level application semantics can certainly be implemented with WebSocket.  But similar to other low-level transports, application programmers should use higher-level APIs to obtain these behaviors under the hood.  

Our JMS Gateway and AMQP Gateways allow you to develop publish/subscribe applications using the familiar JMS and AMQP APIs and not worry about the WebSocket API.  You don’t even have to think about whether WebSocket is physically available on your client device. We implement the WebSocket API regardless whether it’s physically there or not.  We even have a product that takes existing TCP apps and makes them work over the Web using WebSocket with no application code changes.

Of course a few of you may have a legitimate reason to use the WebSocket API or its underlying protocol directly.  You may be implementing your own WebSocket server or developing a high-level protocol or framework that is based on WebSocket.  However the vast majority of programmers encased forever in the large part of the Gaussian curve do not.  Those of us who are responsible for developing cool and useful applications for our user community should not have to program at such a low-level.

Let’s not spend the next ten years totally reinventing the notion of 30 year old application protocols.  Let’s move forward and focus on true innovation to advance the true state of the art in distributed computing.  Application protocols and high-level APIs were invented for a reason.

 

repeat.png

 

Use a higher-level API with the semantics you need in your application.  Don’t reinvent the wheel… or pub/sub… or chat… or tuple-spaces… or presence… or file transfer… or…

Frank Greco

 

 

 

 

 

Posted in Featured, Uncategorized | Leave a comment

Adding Enterprise Features to a Socket.io Application with Kaazing WebSockets

As we discussed in my prior blog post Meeting WebSockets for real, WebSockets enable development of distributed event-driven applications, particularly ones that exchange messages.  Kaazing’s high-level client libraries substantially simplify this effort.  It is possible to add these capabilities to a new Web application in a matter of minutes.

However, what if you already have a NodeJS application and your application already exchanges messages using very popular Socket.io library?

Socket.io is a fantastic open source technology that is very easy to use and adopt. However, many critical requirements of enterprise applications may present some challenges when using socket.io.  Most enterprises require advanced security, enhanced scalability, fault tolerance, etc.

In addition, ‘out of the box’ socket.io does not have support for mobile clients that many enterprises mandate.  In these cases there is a need to transition to an enterprise-class platform and library for using Websocket.

In this article I want to discuss how easy it is to modify your existing code written with socket.io to work with Kaazing WebSockets using a publish/subscribe model.

 

Let’s First Start with a Working Socket.io App

Let’s start with my AngularJS implementation of the canonical TodoMVC application that uses socket.io.   I had a lot of fun building that app; you can find it here.  We are going to make the simple Todo application into a shared app so one user can see the changes of other users).  In addition we can add a NodeJS server component to store the current state of the items; so new users will receive an initial update.  And to prevent potential race conditions when items are being edited by a user, we will simply disable the updating of items by other users; other more sophisticated code can be added later.

Let’s look at several sections of my application’s main controller (complete source available on GitHub).


...

// Connect to pub-sub service
$scope.socket=io();

// Load initial data on connect
$scope.socket.on('connect', $scope.loadData);

// Setup receive callback
$scope.socket.on('todomvc-snd', $scope.processReceivedCommand);

...

The first thing is to connect to socket.io:


$scope.socket=io();

Once a connection is established, we send the request to the server to load any initial data .  We do this by sending the command “init” to “todomvc-rcv” socket together with the attached to the $scope client ID (server will send the reply to this command to all the clients – clients with different IDs will ignore it):

$scope.socket.on('connect', $scope.loadData);

…

$scope.loadData=function(){
        var msg={
                command:'init',
                client:$scope.client
        }
        $scope.socket.emit('todomvc-rcv', msg);
        $log.info(&quot;Sent initialization!&quot;);
}

Now, we need to setup the callback method to receive messages from the server:

$scope.socket.on('todomvc-snd', $scope.processReceivedCommand);

$scope.processReceivedCommand is straightforward and just responds to individual commands.

$scope.processReceivedCommand=function(cmd){
        $log.info(&quot;Received command &quot;+cmd.command);
        if (cmd.command==='insert'){
        ...
        }
        else if (cmd.command==='remove'){
        ...
        }
        else if (cmd.command==='update'){
        ...
        }
        else if (cmd.command==='initdata'){
        ...
        }
}

Note, we are setting up callback on a todomvc-snd topic, while sending the messages to todomvc-rcv topic. I could not find the way to have socket.io send the data from one client to the others directly. To overcome this issue, the client will send the data to a server on the topic A and the server will retransmit the message to the other clients on the topic B.
Sending the data is pretty trivial. For example, to add the item:

var msg={
  command:'insert',
  item:newTodo
}
$scope.socket.emit('todomvc-rcv', msg);

That was the client side of the application.  Let’s now look at the server side NodeJS component.  Besides the code to process the received message and serve static pages it also contains the part that connects to socket.io:

io.on('connection', function(s){
      console.log('a user connected');
     socket=s;
      s.on('disconnect', function(){
          console.log('user disconnected');
      });
      s.on('todomvc-rcv', processMessage);
});

Function processMessage contains the code to store the items that also includes send message calls to retransmit.

function processMessage(cmd) {
        console.log('Command: '+ cmd);
        if (cmd.command === 'insert') {
        ...
        }
        else if (cmd.command === 'remove') {
        ...
        }
        else if (cmd.command === 'update') {
        ...
        }
        else if (cmd.command === 'init') {
        ...
        }
}

Similar to the client side code, sending messages is very simple.  If we want to send the message retCmd to everyone:

var retCmd = {
  command: &quot;initdata&quot;,
  client: cmd.client,
  items: todos
}

socket.emit(&quot;todomvc-snd&quot;, retCmd);

If we want the message to be received to all the sockets except the one that sent it:

socket.broadcast.emit(&quot;todomvc-snd&quot;,cmd);

Now, we can run and test the application.  This page will give you detailed instructions.

Now… Adding the Socket.io Facade to Kaazing WebSockets

To make things easy, we are going to employ the Kaazing Gateway AMQP Edition since NodeJS has robust libraries for AMQP.  While the Kaazing Gateway comes pre-packaged with the Apache Qpid AMQP broker, it can easily be RabbitMQ or another AMQP-compliant broker.  Refer to https://github.com/kaazing/tutorials/tree/develop/todomvc for the instructions for the installation of the Gateway.

Modifying client code

We are going to use Kaazing Universal Client Library for AngularJS to communicate with WebSocket Gateway.  This client library provides a high-level messaging abstraction that is independent of the underlying AMQP or JMS implementations.
Here are the steps we need to take

  • Modify app.js to include the Kaazing Universal Client Library service and create connection parameters contstants (see https://github.com/kaazing/tutorials/blob/develop/todomvc/js/app.js )
    angular.module('todomvc', ['ngRoute', 'ngResource', 'KaazingClientService']).
        .config(function ($routeProvider) {
            ...
        })
        .constant('todoMvcWebSocketConfig', {
            URL: &quot;ws://localhost:8001/amqp&quot;,
            TOPIC_PUB: 'todomvc',
            TOPIC_SUB: 'todomvc',
            username: 'guest',
            password: 'guest';
        });
    
  • In the main controller source code
    • Connect to Gateway and establish all callbacks (replace $scope.socket=io() and all $scope.socket.on calls)
      // Connect to WebSocket
      AngularUniversalClient.connect(
            'amqp, - use AMQP protocol
            todoMvcWebSocketConfig.URL,  // connect URL (default is ws://localhost:8001/amqp)
            todoMvcWebSocketConfig.username,// use guest account
            todoMvcWebSocketConfig.password,// use guest pswd
            todoMvcWebSocketConfig.TOPIC_PUB, // use 'todomvc' as publishing topic
            todoMvcWebSocketConfig.TOPIC_SUB, // use 'todomvc' as subscription topic
              true, // No Local flag set to true which prevents the client to receive messages that it sent
              $scope.processReceivedCommand, // function for processing received messages
                   function(e){alert(e);}, // function to process WebSockets errors
            $scope.logWebSocketMessage, // function to process WebSocket logging messages
            $scope.loadData // function that will be called when the connection is established
      );
      
      
    • Replace $scope.socket.emit with AngularUniversalClient.sendMessage
      var msg={
          command: 'insert',
          item:newTodo
      }
      AngularUniversalClient.sendMessage(msg);
      
      

Note that we no longer need to use different topics for publishing and subscription.  The Kaazing WebSocket Gateway will send published messages to all subscribed clients without the need to retransmit them in the server code!

Server code changes

To preserve our server side code we are going to use the Kaazing Socket.io wrapper located in the node subdirectory of the todomvc implementation.
https://github.com/kaazing/tutorials/blob/develop/todomvc/node/socketioalt.js
The wrapper hides the details of the use of AMQP protocol (which is used for communication with NodeJS) while exposing interface that mimics the one used in Socket.io.

With our socket.io wrapper, we only need to make two changes on the server:

  • Change both send and receive topics to “todomvc”
  • Remove the code that retransmits messages

Here is the final server code implementation.

Summary of Changes

If you were to run the diff:

  • app.js vs app-socketio.js:
    • Added declaration of the Kaazing Universal Client Service
    • Added constant for the connection parameters
  • todoCtrl.js vs todoCtrl-socketio.js
    • Added reference to Kaazing Universal Client Service
    • Added reference to the connection parameters constant
    • Replaced connection and callbacks for socket.io with a single call to initialize Kaazing Unviersal Client
    • Replaced Socket.io socket.emit functions with Kaazing Universal Client sendMessage cals
  • serverws.js vs serversocketio.js
    • Replaced declaration of io:
      var io = require('socket.io')(http);
      

      was changed to

      var io=require('./node/socketioalt.js')('amqp://localhost:5672');
      
    • Removed all retransmit calls socket.broadcast.emit(“todomvc-snd”,cmd);
    • Changed the topics “todomvc-snd” and “todomvc-rcv” to “todomvc

Conclusion

Its very easy to upgrade a socket.io application to use the enterprise-class Kaazing WebSocket Gateway.  There are barely any source changes in your existing code.  Not only do you now get high-performance, advanced security and scalability features, Kaazing technology will extend your former Socket.io applications to work with mobile clients and many B2B and inside-the-firewall applications.

It’s a huge win.

Posted in Featured, html5, Kaazing, WebSocket | Tagged , , | Leave a comment

How to Replace Your Legacy VPN in Minutes

KWICies #007 – When You Gotta Go, You Gotta Go

“Intelligence is the ability to adapt to change”
– Stephen Hawking

“The lion and the calf shall lie down together but the calf won’t get much sleep”
– Woody Allen

 

bw-tv

An Enterprise Parable
The alluring sound of the cloud siren beckons you to write a killer service using the latest server-side technologies to solve a huge problem in your industry. You haul out the buzzword-compliant big guns, i.e., big-data, machine intelligence and Docker microservices. Your team builds this awesome, mission-critical, revenue-generating web service. All this gleaming power is now ready to be used by your Fortune 500 customers.

You pause and secretly sneer with glee.

The management gods smile upon you. It’s an evil smile, but what the heck, at least those bastards are smiling.

You present to your first customers.

“… and it’s scalable and secure. Its accessed with a simple HTTP call. You merely upload your users’ credentials into our repository in the cloud and we take care of authentication.   Thank you.  Payments to ACME Software are due 30 days ARO”.

But the customers don’t rejoice. In fact they remain stone-faced, stand up silently and exit single-file.

The management gods drop their smiles and their lit cigars.   You reach into your pocket and solemnly crinkle that envelope with that down payment on your new digs in the Hamptons.

Cue the sad music.

sad+clown                                     But I like the Beach…

 

What Goes On in the Datacenter Stays in the Datacenter
Most companies have legal constraints, regulatory restrictions or corporate mandates on what types of systems can physically exist in an off-premises cloud. Very often, critical user credentials and other types of “family jewel” information cannot leave the premises of the enterprise. In many geographic locations, in particular Europe, there are stringent rules on where data must reside. Data protection directives and privacy laws can be quite strict and heavily regulated

In addition to data protection and privacy constraints, many corporations simply may not want their highly sensitive services in a public cloud provider. It may not even be for data sensitivity reasons; companies are very reluctant to create subsets of data since it involves costly data synchronization and maintenance. So there are a variety of reasons that certain systems and services must remain on-premises.

Caribbean_Map                              Preferable off-premises islands of information

However, these powerful SaaS-style systems of engagement running in a public cloud commonly require access to the on-premises systems of record.

For example, a CRM system running in Microsoft Azure may require authentication from an on-premises LDAP service. A portfolio reconciliation system running in Google GCP needs real-time market data feeds originating from several on-premises sources. A managed machine intelligence service running in Amazon AWS requires event-based data from your supply chain partners.

These are not unusual on-prem/off-prem scenarios.  Au contraire mon ami, most SaaS services have this requirement.

Historically there were three basic solutions for this type of requirement:

  1. You ask your customers to create a conventional REST-style web service that allows your external cloud service to call them. Your champions at your customer hear you, feel a stabbing sensation in their stomachs and wince politely. This solution is quite painful and very costly for their IT departments. Designing and deploying an application server that requires several months to develop and incurs maintenance expenses is painful for your customers.
  1. You ask your customers to open incoming non-standard TCP ports for your SaaS cloud service.This is potentially a humongous security hole. You are destined to be a case study in the future. Prepare your CV.
  1. You ask your customers to install a legacy VPN.Your customers are familiar with VPNs. They know they can install an expensive hardware VPN device from a large networking company with a lengthy maintenance agreement. Or they can deploy a software SSL VPN, perhaps even an open-source one with the fugly user interface and confusing administrative dashboard. All your customers need is to get approval from their InfoSec and Operations teams. And signoff from your own InfoSec team. And from their Managing Director. And their CTO. And their CIO. Should be simple, right?

The usual 30-year old answer to this scenario is to setup a legacy VPN to connect the two systems.

shrug                                                        Do I really have a choice?

 

However there are many downsides to setting up traditional or cloud-based VPNs:

  • The on-boarding process can be onerous especially between external organizations, despite the straightforward technology setup.
  • They are not easy to manage in an agile, constantly changing federated environment, which is the norm.
  • VPNs may require additional infrastructure for mobile devices that experience disconnects, cross-application network connection retries, additional security, etc.
  • Even one VPN can be quite difficult for a business unit to deploy, maintain and understand the security issues. In a business-driven cloud services world, this reduces agility for the revenue generators in an enterprise.
  • They typically allow low-level potentially dangerous access especially if home computers are used to access corporate assets.
  • VPN Access control commonly uses the hard-to-manage, black list security model.
  • They present huge surface areas with many attack vectors for hackers to exploit. Some researchers have even discovered many VPN vendors leak low-level IP data.
  • VPN vendor hardware and software are not always interoperable or compatible. A particular VPN architecture may not be suitable across multiple VPN vendors.
  • VPN products typically offer poor user experiences.
  • TCP and Web VPN requirements are not necessarily the same. This drives up costs. In terms of security,
  • Do legacy VPNs fit in a multi-cloud, on-demand and microservices world? All connectivity must be uber convenient and on-demand.

And as the Internet-of-Things (IoT) and Web-of-Things (WoT) wave matures over the next 5-10 years, VPNs are simply too clumsy, inconvenient and heavyweight to handle agile remote connectivity for the many billions of devices to come.

And these devices will arrive in huge waves. The connectivity and data volumes are large now, but when IP is implemented over Bluetooth LE, the connectivity fabric will spread faster than a Lady Gaga video on YouTube. You don’t have to be Nostradamus to predict a future discontinuity in the increased data volumes, the increased number of machine intelligence applications and the necessary secure connectivity.

Tweet: “Customers definitely want secure connectivity with all these apps, but they also want convenience.”

 

convenience                                    Is Elon Musk driving that Really Smart Car?

 

Enter WebSocket
We’ve talked about WebSocket in detail back in KWICies #003. To quickly review, our fearless hero WebSocket is an official IETF wire protocol (Dec 2011) and an (essentially) official W3C JavaScript API to use it (note: the W3C only specifies a JavaScript API). WebSocket is a peer protocol to HTTP; in other words both HTTP and WebSocket (and their TLS/SSL encrypted versions) are physically implemented “on top of” TCP.

 

wshttp                       The Web is now a humongous collection of APIs and Services

 

Unlike HTTP, WebSocket is a persistent (and full-duplex) connection between two endpoints. A persistent connection means event-based programming is now finally possible over the web. Btw if you really want to be hip, replace “event-based” with “reactive”; you’ll make the application server developers swoon during your next corporate presentation.

HTTP is clearly an excellent protocol for document up/download and we certainly have tweaked it over the past 5-7 years to do things it was never intended.  And HTTP remains the protocol of choice if you need caching of static entities. But it was never intended for asynchronous distributed computing.

On the other hand, WebSocket can be thought of as a “TCP for the web” (certainly not physically true). As a persistent and full-duplex connection, WebSocket allows all sorts of additional protocols to be implemented over the web, e.g., messaging, events, telemetry, data acquisition, et al.  And like TCP, WebSocket is a low-level transport; many other types of higher-level application protocols and APIs can be implemented over WebSocket.  As a matter of fact, any TCP-based application protocol can use WebSocket as a transport to traverse the web.

Similar to any other wire protocol, WebSocket does not have to be used with a browser (e.g., Slack’s native client uses WebSocket under the hood), but there are certainly a lot of examples of WebSocket use in a browser (Google docs, Trello, BrowserQuest, etc.).

And since WebSocket is like a TCP, you can envision other non-browser use cases like… wait for it… replacing many VPN scenarios.  The Kaazing KWIC software leverages this new communication model by securely converting TCP to WebSocket from one side and reversing the process on the other side. Literally in a few minutes you can have secure hybrid cloud services connectivity using the WebSocket-powered KWIC software without the pain and administrative headaches of a legacy VPN.

If you need on-demand, program-to-program service connectivity for your modern applications, why are you still dealing with old-school, 30 year old VPN technology?

Frank Greco

Posted in cloud, Featured, Kaazing, Security, WebSocket | Tagged , , , , | Leave a comment

Kaazing and NGINX – The Best of Both Worlds

Jesse Selitham

Kaazing is well-known for a multitude of products based on the WebSocket IETF and W3C standard.  Using WebSocket allows us to extend different types of asynchronous, message-oriented infrastructure such as JMS and AMQP easily and securely over the web.

NGINX is another awesome tool.  It is one of the world’s most popular, high-powered web servers.  Many of the large websites on the planet prefer NGINX as their webserver of choice.

Wouldn’t it be really cool to combine the secure messaging features of the Kaazing Gateway together with the high performance Nginx web server?  Your hyper fast website would have additional security measures to protect your internal network from unauthenticated users and you’d be able to automagically connect to internal enterprise messaging systems without learning brand-new APIs.

Now that’s a powerful combination.  Let’s setup a deployment to get the best of both.  

We can have incoming WebSocket-based messaging requests passed through an Nginx webserver (proxy) instance to a Kaazing WebSocket Gateway server instance.  Normal incoming HTTP/S traffic would be directly handled by Nginx.

kaazing-nginx

This topology also allows us to avoid exposing the internal URL or private infrastructure information that hosts the Kaazing WebSocket Gateway server (which is a simple Java process btw).

 

CONFIGURING THE KAAZING GATEWAY

The first step is to download the Kaazing WebSocket Gateway if you haven’t already.  I’m using the standalone JMS Edition 4.0 on Windows that you can find here (Make sure you download the “Gateway + demos” version).  Once you’ve unzipped the file, we’ll want to make one change to the default gateway.config file (gateway-config.xml).  This file is located in the “…\conf” subdirectory below the your install directory.

…\{KAAZING_DIRECTORY}\kaazing-websocket-gateway-jms-4.0.9\conf

Down the middle of the page of the gateway-config.xml file, within the JMS <service> tag, we’ll need to change this (parameterized) line here

<allow-origin>
http://${gateway.hostname}:${gateway.extras.port}
</allow-origin>

This property is enabled for security reasons by default.  This setting will block incoming websocket connections if the request is NOT originating from the specified host (${gateway.hostname}) and port (${gateway.extras.port}).  In a non-proxy topology, you would typically keep the origin URL (typically coming from a browser) set for protection.  But in our case, Nginx will be proxying the connection coming from a different port than the actual origin.  For the purposes of development simplicity, let’s change this setting:

    <allow-origin>*</allow-origin>

Using “*”  allows websocket connections from any origin through to the JMS service.  In production, you will definitely want to strengthen security.  The security documentation for the Kaazing Gateway has detailed information for enhanced security.

 

STARTING THE GATEWAY AND MESSAGE BROKER

The JMS Edition of the Kaazing Gateway was designed to work out-of-the-box with any JMS 1.1 compliant message broker.   For convenience the binary version of the  popular message broker ActiveMQ is included in the JMS Edition distribution.  In addition, the gateway-config.xml configuration file has a simple, default configuration for ActiveMQ.

Let’s start the Kaazing WebSocket Gateway and the ActiveMQ message broker.  The startup scripts for both are located in the …\bin subdirectory.

…\{KAAZING_DIRECTORY}\kaazing-websocket-gateway-jms-4.0.9\apache-activemq-5.10.0\bin\activemq.bat

…\{KAAZING_DIRECTORY}\kaazing-websocket-gateway-jms-4.0.9\kaazing-websocket-gateway-jms-4.0.9\bin\gateway.start.bat

 

CONFIGURING NGINX

The last step is to install and configure Nginx.  Setup is very easy.  The installation documentation on the Nginx website can help you.    Below is my configuration for my nginx.conf file.

events {
    worker_connections 1024;
}

http {
    server {
        listen 9000;

        #websocket
        location /jms {
            proxy_pass http://localhost:8001/jms;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
        }
        location / {
            proxy_pass http://localhost:8001;
        }
    }
}

I’ve stripped the Nginx configuration down to the bare minimum.  This configuration simply proxies requests through to the Kaazing Gateway server.  

Now we simply start up Nginx.   

At this point, we have an instance of Nginx acting as a normal webserver handling HTTP requests and also acting as a WebSocket proxy.  The JMS-over-WebSocket requests (identified by “http://localhost:8001/jms” are passed through Nginx and handled by an instance of the Kaazing WebSocket Gateway.  The Gateway takes that connection request and handles it as it would have if there were no proxy and completes the connection to the instance of the ActiveMQ message broker.   Everything is now in place for a full integration test.

 

TESTING OUR COMPLETE CONFIGURATION

Included with the JMS Edition of the Kaazing Gateway is a simple JavaScript publish/subscribe messaging demonstration.  We can use this demo to test our full setup.  

Start your favorite browser and visit this URL:

http://localhost:9000/demo/jms/javascript/jms.html

If you look in the Location textfield, you will see the URL: ws://localhost:9000/jms

Notice the port we are using here, i.e., 9000.  This is the port that we configured our nginx server to listen on, which means Nginx served up the webpage.  Next click on the Connect button.  If we’ve done everything correctly, we should see “CONNECTED” in the “Log messages” text area to the right.

kaazing-nginx-test

Voila!  We have successfully allowed a WebSocket connection to pass through Nginx, connect with the Kaazing Gateway and subsequently connect to the back-end ActiveMQ message broker.  I will leave the subscribe and publish fun of the demo app up to you!   

Posted in cloud, Featured, html5, IoT, JMS, Kaazing, Uncategorized, WebSocket | Tagged , , , | Leave a comment

Deploying the Kaazing WebSocket Gateway Using Docker

Many of our customers deploy our WebSocket Gateway using traditional operations procedures.  Works perfectly fine, but like typical enterprise-grade middleware products, there’s still a number of moving parts to get correctly configured with other systems.

Enter Docker.

In case you haven’t checked it out yet, Docker is an exciting management platform that makes setting up tech infrastructure a snap.  It allows you to manage container deployments which are self-contained services that share the operating system.  You should think of containers as mini-virtual-machines but significantly lighter weight.  And these days, to help deploy multi-container applications Docker now comes with the “docker-compose” (Compose) utility which makes deployment ultra easy.

To get you caught up, I will walk you through the basics of getting Docker installed and running a short example.  Let’s use the popular echo demo application from websocket.org and deploy it in a single command.  Then I’ll show you how to leverage Compose to easily define and run a sample application that connects the Websocket gateway to a backend JMS message bus.  We’ll keep it brief and point you to the useful Docker docs.  All of these examples are hosted on github.

Sounds good?  Let’s get started.

First, what really is a container?  A container wraps an implementation of a software service in a complete filesystem and OS-like environment that contains everything it needs to run.  Docker provides an API and container management platform that allows people to deploy, run and share them with others.  It’s very similar to traditional virtual machine (VM) management that we’ve used for the past few years.  But Docker has all the bells and whistles that make container management simple and significantly more performant.  

Let’s install Docker by following the Docker installation docs.  After you have installed and started Docker, you can run a single command to deploy and run the WebSocket demo.

docker run -name websocket.container -h gateway.example.com -p 8000:8000 kaazing/gateway

So how does this work?  

On your machine you are running a docker daemon which is listening to commands.  The ‘run’ command tells the docker daemon to launch a docker container on your behalf, specifically the kaazing/gateway container.  But how did you get the kaazing/gateway container?  Well, it is made available to you in the form of an image via a trusted and official docker repository that is accessible to the public called docker hub.  The next question you’ll ask is “Where is my container running”?  Containers are a Linux feature, if you are running on a Linux machine then it is running in an isolated namespace on your OS.  If you have a Mac or Windows machine, then your container needs a Linux VM on your Mac/Windows box as a host environment to run. Luckily, docker distributions now include a Virtual Machine manager like VirtualBox.

So now you have a docker container running.   Cool.

To connect to it you will need to add an entry into /etc/hosts for “gateway.example.com” that points to the IP address of the machine the docker container is running on.  If you are using the docker installation referenced above you can get this by running docker-machine ip your-docker-machinename.  On my machine that returns 192.168.99.100.  So I would add the following to my /etc/hosts.

192.168.99.100 gateway.example.com

Once you configure your /etc/hosts file, you can run a quick test.  Open your browser and visit: http://gateway.example.com:8000/.

Perfect, step one is done!

But setting up a Kaazing Gateway in this way still requires configuring the Gateway to interact with other components in your infrastructure.  Rather than setting up each component separately, you can use Compose to launch and configure them all at once.  For example, a common setup is to use the Kaazing Gateway with a messaging broker that allows internal publish/subscribe messages to be delivered over the firewall.

That’s why we need Compose.

Compose now comes pre-installed with the latest Docker releases.  With Compose you specify the components in your infrastructure via a docker-compose.yml file.  Below is an example:

gateway:
  build: dockerized.gateway
  ports:
    - "8000:8000"
    - "8001:8001"
  links:
    - broker:broker.example.com
  hostname: gateway.example.com
broker:
  build: dockerized.broker 

In this file two containers are defined: broker, and gateway.  Each points to a directory that defines where the container is built from; dockerized.gateway and dockerized.broker respectively.  The gateway container is linked to the broker container via broker.example.com, which means the gateway container can reach the broker on that address.

To run this we will need to checkout the example github repository and run docker-compose up, which launches the configuration.  Here are the commands:

git clone https://github.com/dpwspoon/kaazing.configuration.examples .
docker-compose -f jms.and.broker.yml up

Now point your brower to http://gateway.example.com:8001/demo/jms/javascript/jms.html and you can see the jms demo.

Docker has a fast-growing image repository.  The Docker team recently announced they were 5.6 million docker images pulled every day.  Its immense popularity is based on its ability to enable developers to easily build, package, and deploy sophisticated enterprise applications that consist of a collection of powerful high-performance components.  Now the Kaazing WebSocket Gateway joins the Docker ecosystem as a valuable tool for application developers.

Posted in Featured, Uncategorized | Leave a comment

Wild Week of Web Wonderment – HTML5DevConf

KWICies #006: Thoughts on HTML5 and HTML5DevConf 2015

“We live in a web of ideas, a fabric of our own making.”
– Joseph Chilton Pearce

“Roses are red, violets are blue, I’m schizophrenic, and so am I.”
– Oscar Levant

The Web is Your Oyster, Now Watch Out for the Clams…

 

h5

 

Let’s face it. HTML5 was originally designed as a weapon.

HTML5 is the culmination of a political movement to overthrow Microsoft Internet Explorer (IE) as the web platform for all of humanity.

If you recall from your readings of the ancient dead (ANSI) C scrolls of the Internet circa mid to late 1990’s, Microsoft’s IE (a browser licensed from Spyglass) was the only browser allowed by most companies. And many large companies wrote apps specifically for IE, effectively shutting out any other browser vendor. This was tough to take for the other browser vendors at that time such as Mozilla, Apple and Opera. The browser was the portal to knowledge and Microsoft was the gatekeeper. Not only that, the pace of innovation with Microsoft’s browser back then was glacially slow (and that’s being kind). Microsoft also leveraged this control to constrain the growth of the Java browser plugin to run applets (anyone remember any useful Java applets? Me neither). When you have a monopoly, why rush to innovate? It’s no different than in any other business sector.

 

snail-pix
“I’m certainly not interested in forking a shell”

 

But this situation was only good for Microsoft and gave enterprises a false sense of security. Yes, you can be sure there’s a browser running on your user’s desktop so you can deploy your web app, but its frickin’ IE with its own proprietary implementation of HTML and related technologies. Didn’t we learn portability as a trait of good software back in Computer Science 101?

Since the browser is the portal to knowledge and information, and just an indispensible tool (to buy incredibly bad country music, to rent movies from the 70’s with a laugh track funnier than the movie, and to watch videos of cute kitties riding on Roombas), the other browser vendors were at a disadvantage. They could not run those non-portable, IE-specific apps.

And quite honestly, the W3C as an organization back then was no zippy roadrunner either. It moved quite slowly especially with the evolution of XML-flavored page markup, which thankfully died on the vine. Hopefully the vine died a painful death too.

 

xhtml
What were they smoking?

 

Because of the slow evolution of this markup language by the W3C (and because they needed to stop the IE monopoly), Apple, Mozilla and Opera proposed a new unofficial web standards group called the WHATWG (Web Hypertext Application Technology Working Group) in 2004. These three proposed HTML5 to the W3C as the basis of the next generation of web applications not web documents. Effectively this turned the web into a programmatic platform rather than a document storage platform. HTML5 was not just an upgrade of HTML4, it proposed sophisticated graphics, animation and a collection of useful ECMAScript (note JavaScript is an Oracle trademark) APIs such as File I/O, Geolocation, Database, Messaging, Threading, Touch Events, Audio, MIDI, Speech Recognition, et al.

Cool HTML5 stuff.

 

Eventually Google recognized the pervasive, far-reaching, accessible power of HTML5 and joined the programming plumbing party with the ever-growing list of HTML5 goodies.   And HTML5 is providing all of these features without plugins. Since plugins were attack vectors for hackers, the more plugins you have, the more possible security breaches. HTML5 only allows a single way to connect the browser to the web. This significantly reduces the possible ways that hacker can break in. It certainly doesn’t eliminate breaches, but HTML5’s no-plugin philosophy dramatically reduces the attack surface area (just love that jargon from the security boys).

 

doors
The only time more Doors is better

So now we have a large number of modern browsers (amazing what competition does, right?) all with varying compliance to the list of really cool HTML5 features.

 

 

html5devconf

Any many of these features were on display at the 2015 HTML5DevConf in San Francisco. The conference chairperson Ann Burkett put on a wild week of web wonderment at the Yerba Buena Center for the Arts in the city by the bay.   There were speakers from Netflix, Google, Meteor, Microsoft, Yelp, Dolby, PayPal, Adobe, Wal-Mart, Yahoo, Couchbase, Qualcomm and of course Kaazing.

 

I particularly enjoyed Jennifer Tong’s talk on “Prototyping the Internet of Things with Firebase”. Jennifer, a Mountain View Googler, did an incredible job explaining simple electronics to the web-savvy audience. She brought everyone up-to-speed on simple hardware hacking in the first 20 minutes of her talk and setup her live software demos using Google’s Firebase, the Johnny Five library and the Raspberry Pi small computer. Excellent presentation.

 

Bench_Johnny
The original Johnny “Five”… Johnny Bench

 

Steve Souders is no stranger to the web world; he’s well known in high performance web circles and the web in general. Steve had successful stints at Google and Yahoo! as the lead performance expert. His session on Design+Performance was certainly very informative. Essentially users want both a media-heavy website but a very fast user experience, but how do you design an optimal site that satisfies both criteria. Steve talked about gathering metrics using new tools and employing an interesting development process that joins both requirements at a project’s outset.

 

Peter Moskovits and I delivered a well-attended session on novel uses of WebSocket using our own Kaazing Gateway server. Historically WebSocket (and its technically incorrect but more popular moniker “WebSockets”) has been used to push data from the server to the browser. But now there have been several advances in alternative mechanisms for simple data push such as the Notification specification and the Push API. There is also the new HTTP/2 standard, where multiple HTTP connections can share a single, underlying TCP connection for 20-50% more performance. The use of WebSocket specifically for browsers is now more suitable for certain high-performance or highly reliable messaging use cases.

 

peterm
Kaazing’s Peter Moskovits Talks WebSocket

 

As we pointed out in our session, the overwhelming majority of web usage is not via the browser. Most of the web is consumed via APIs. Currently the dominant API model is REST (there were a few people in the audience actually admitting they used SOAP, poor souls). REST is a very easy synchronous API model that typically uses request/response HTTP as its transport, which means REST calls have to wait for a response.

 

But as streaming and reactive services mature and continue to proliferate (especially with the IoT wave growing exponentially), the need for higher-level asynchronous mechanisms and APIs for developers to use will grow significantly. The world is asynchronous and event-driven; many applications in the future just cannot use REST, which was never truly designed for events. WebSocket is perfectly suitable for these types of use cases.

 

We also proposed a novel application for WebSocket as an alternative to an old-fashioned VPN. Since WebSocket is a bidirectional, web-friendly software tool, why not use it to create an on-demand connection between applications or server processes? Since WebSocket is effectively a “TCP for the web”, let’s use it like a TCP. That’s the basis of our KWIC software, which provides on-demand VPN-like connectivity using WebSocket under the hood.

There were certainly many other sessions with interesting topics and excellent speakers that you can check out at their website. The HTMLDevConf just gets better ever year!

Frank Greco

 

 

Posted in cloud, Events, html5, Kaazing, Security, WebSocket | Tagged , , | Leave a comment