Wednesday, August 8, 2012

An Introduction to STOMP

STOMP (Simple (or Streaming) Text-Oriented Messaging Protocol) is a simple text-oriented protocol, similar to HTTP.

STOMP provides an interoperable wire format that allows clients to communicate with almost every available message broker. STOMP is easy to implement and gives you flexibility since it is language-agnostic, meaning clients and brokers developed in different languages can send and receive messages to and from each other. 

There are lots of server implementations that support STOMP (mostly compliant with the STOMP 1.0 specification). The following is a list of STOMP 1.0 compliant message servers:




On the client side, there are many implementations for a vast number of technologies. Below, you will find the libraries available for the most popular languages.

























STOMP is an alternative to other open messaging protocols such as AMQP (Advanced Message Queueing Protocol) and implementation specific wire protocols used in JMS (Java Message Service) brokers such as OpenWire. It distinguishes itself by covering a small subset of commonly used messaging operations (commands) rather than providing a comprehensive messaging API. 

Because STOMP is language-agnostic and easy to implement, it’s popular to application developers and technical architects alike. STOMP is also text-based. Since it does not use binary protocols like other message brokers, a wide range of client technologies work with STOMP, like Ruby, Python, and Perl.

STOMP is simple to implement, but supports a wide range of core enterprise messaging features, such as authentication, messaging models (point to point and publish and subscribe), message acknowledgement, transactions, message headers and properties, etc.



Monday, July 16, 2012

The Definitive Guide to HTML5 WebSocket

The book is on the way now! You can pre-order it here. It has been so much fun and a lot of work but I personally hope you can get a copy and enjoy all the content we're putting together.

Here is part of the book description if you want more information about it:

"The Definitive Guide to HTML5 WebSocket is the ultimate insider’s WebSocket resource. This revolutionary new web technology enables you to harness the power of true real-time connectivity and build responsive, modern web applications.   

This book contains everything web developers and architects need to know about WebSocket. It discusses how WebSocket-based architectures provide a dramatic reduction in unnecessary network overhead and latency compared to older HTTP (Ajax) architectures, how to layer widely used protocols such as XMPP and STOMP on top of WebSocket, and how to secure WebSocket connections and deploy WebSocket-based applications to the enterprise. Build real-time web applications with HTML5."


The book gives you an overview of HTML5 WebSocket, the WebSocket API and the protocol, the high level protocols you can use on top of WebSocket, security aspects and enterprise deployment. 


Saturday, July 14, 2012

The WebSocket bufferedAmount attribute


If you have been working or planning to work with HTML5 WebSocket you may end up transporting large amounts of data and/or you may have the requirement to transport data as fast as possible. 

The WebSocket object has an attribute called bufferedAmount that's particularly useful to check for the amount of data buffered for transmission to the server. You can use the bufferedAmount attribute to check the number of bytes that have been queued but not yet transmitted to the server.

The values reported in that attribute don’t include framing overhead incurred by the protocol or buffering done by the operating system or network hardware.

The code below shows an example of how to use the bufferedAmount attribute to keep sending updates every second, if the network can handle that rate, or at whatever rate the network can handle, if that is too fast.

// Buffering threshold at 10k
var THRESHOLD = 10240;

// Create a New WebSocket connection
var mySocket = new WebSocket(“ws://echo.websocket.org/updates”);

// Listen for the opening event
mySocket.onopen = function () {
 setInterval(function() {

// Check for amount of data buffered but not sent yet //and then send an update in case there is nothing //in the buffer
if (mySocket.bufferedAmount < THRESHOLD)
                                    mySocket.send(getUpdateData());
                  }, 1000);
};

Using the bufferedAmount attribute can be useful for throttling the rate at the applications send data to the server avoiding network saturation.

Thursday, June 21, 2012

Checking for WebSocket Support on Your Web Browser


It’s frustrating to execute some code and don’t see anything happening after that. But, depending on the web browser you or the end user running your application is using that may be impacting the WebSocket functionality at this point since not all current browsers in use support HTML5 WebSocket natively yet.

So, let’s take a look on some techniques to make the web browser supports WebSocket.

We are going to use the JavaScript console available in all web browsers to start with the WebSocket support investigation. Each web browser has a different way to initiate the JavaScript console but if you’re using the suggested web browser (Google Chrome) take a look on the following resource to learn more about it (https://developers.google.com/chrome-developer-tools/docs/overview).

If you open your browser’s interactive JavaScript console and evaluate the expression window.WebSocket you should see the WebSocket constructor object:

 function WebSocket() { [native code] }

which means that your web browser supports WebSocket natively.

The same test above in some other browsers comes back blank or undefined indicating no native support.

If you want to add that capability for WebSocket support to your application or on our sample client code, you can use the following approach.

By just adding the following conditional check to your code before you try the WebSocket connection then it would be enough to tell you if the web browser supports WebSocket natively.

if (window.WebSocket){
     console.log("BROWSER SUPPORTED");
} else {
     console.log("BROWSER NOT SUPPORTED");
}

If your target web browser doesn't support HTML5 WebSocket and you want to have that amazing capability on your application, it's time for you to look into some vendors like Kaazing where you have WebSocket emulation that enables any browser (modern or not) to support the HTML5 WebSocket standard APIs.

From the developers perspective they can work in a fully transparent environment, using the client libraries that enable them to simply code against standard WebSocket APIs. And from the end-user point of view, they interact with a WebSocket application that Kaazing’s WebSocket emulation technology kicks in when native WebSocket support is unavailable, giving the user a seamless experience.

There are several web sites available on the Internet to help you with compatibility, not only WebSocket, but also HTML5 features in general. To mention a couple of them, you can navigate to http://caniuse.com/ or http://html5please.com/ and check for the HTML5 feature you want to use on the target web browser manufacturer and/or version.

Saturday, June 9, 2012

The WebSocket readyState attribute


The WebSocket object will report the state of its connection through a read-only attribute called readyState.

There are four different values that the readyState attribute can receive to represent the state of the connection.

0 - CONNECTING – The connection has not been established yet.
1 - OPEN – The connection has been established and messages can be exchanged between the client and the server.
2 - CLOSING – The connection is going through the closing handshake.
3 - CLOSED – The connection has been closed or could not be opened.

When the WebSocket object is first created its readyState is 0, indicating that the socket is CONNECTING.

Thursday, May 10, 2012

Inspecting WebSocket Frames

So far, it has been a challenge for us working with HTML5 WebSocket to analyze the traffic going back and forth from the client to the server and from the server to the client. Without using packet sniffing tools like Wireshark or tcpdump the analysis and debugging of WebSocket messages is almost impossible.

But, recently, things are changing and it's now possible to see frame data along with arrows indicating the direction of the data is going to.

A WebKit patch has been created and you can use Chrome Canary to check the latest changes and start inspecting WebSocket frames. A huge advance for those working with HTML5 WebSocket.

There is also a step-by-step demo located here: http://blog.kaazing.com/2012/05/09/inspecting-websocket-traffic-with-chrome-developer-tools/

Monday, April 30, 2012

Accessing Databases with HTML5 WebSockets and Apache Camel

As I have said on my previous post, I've been working with several companies with the most diverse use cases and one that really brought my attention was the requirement to access databases using HTML5 WebSockets which seems to be a clever thing to do with the right tools.

So, basically what I've setup for this is represented on the picture below:


Let's go over the implementation details of all of the components described here:

From right to left, the backend datasource I had to use was MySQL that you can download from http://www.mysql.com/downloads/. Then, I used Apache Camel as the backend framework accessing the database and also exposing a TCP-based component (Mina in this case). Moving to the left, we have the Kaazing WebSocket Gateway connecting to the Apache Camel framework and exposing WebSocket connectivity to the web clients (browser-based, mobile-based and desktop thick client applications).

The web-browser sample client is pretty straightforward and with a few lines of code you can get the functionality. There are sample javascript clients shipped with the Kaazing WebSocket Gateway that you can re-use or modify to your needs. The Kaazing WebSocket Gateway documentation set is also helpful and good starting point. Check it out: http://tech.kaazing.com/documentation/html5/3.3/o_dev_js.html

Then the only change you have to make in the Kaazing WebSocket Gateway is in the gateway-config.xml (under $KWG_HOME/conf) to include the service you want to expose to the web clients and where you want to connect to the backend framework with access to the database.

Here is what I have included on my configuration:

<!-- Demo JDBC Backend System Config -->
  <!-- Proxy service --> 
  <service>
<accept>ws://${gateway.hostname}:${gateway.extras.port}/jdbc</accept> 
<type>proxy</type>
<properties>
<connect>tcp://${gateway.hostname}:8888</connect>
</properties>
   </service>

Check the Kaazing WebSocket Gateway documentation to get more familiar with these settings.

Last but not least, the Apache Camel route hosting the Mina endpoint and the database connectivity:

 <camelContext xmlns="http://camel.apache.org/schema/spring">
    <package>com.kaazing.gateway.demo.db</package>
    <route id="WSMinaJDBCSample">
        <from uri="mina:tcp://localhost:8888?timeout=30000"/>
        <log message="RECEIVED: ${body}"/>
        <setBody>
        <simple>select * from customers where customers.email = '${body}'</simple>
        </setBody>
        <to uri="jdbc:myDataSource"/>
        <log message="GENERATED: ${body}"/>
    </route>
</camelContext>


<!-- MySQL datasource -->
  <bean class="org.springframework.jdbc.datasource.DriverManagerDataSource" id="myDataSource">
    <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
    <property name="url" value="jdbc:mysql://localhost:3306/test"/>
    <property name="username" value="root"/>
    <!-- <property name="password" value="XXXXX"/>  -->
  </bean>



The MySQL database setup is very simple and you can use any sample database tables you want. Just make sure you update the Apache Camel route and your environment settings accordingly.

Code will be available soon...

UDPATE:
Sample code is now available at: https://github.com/mjabali/DBOverWS

Setting Up Local Environment for Developing Oracle Intelligent Bots Custom Components

Oh the joy of having a local development environment is priceless. For most cloud based solutions the story repeats itself being hard to tr...