Showing posts with label websocket. Show all posts
Showing posts with label websocket. Show all posts

Wednesday, February 5, 2014

Getting Started with HTML5 WebSocket on Oracle WebLogic 12c

The current release of Oracle WebLogic (12.1.2) added support to HTML5 WebSocket (RFC-6455) providing the bi-directional communication over a single TCP connection between clients and servers. Unlike the HTTP communication model, client and server can send and receive data independently from each other. 

The use of WebSocket is becoming very popular for highly interactive web applications that depend on time critical data delivery, requirements for true bi-directional data flow and higher throughput.
To initiate the WebSocket connection, the client sends a handshake request to the server. The connection is established if the handshake request passes validation, and the server accepts the request. When a WebSocket connection is established, a browser client can send data to a WebLogic Server instance while simultaneously receiving data from that server instance. 

The WebLogic server implementation has the following components:
  •  The WebSocket protocol implementation that handles connection upgrades and establishes and manages connections as well as exchanges with the client. The WebLogic server fully implements the WebSocket protocol using its existing threading and networking infrastructure.
  • The WebLogic WebSocket Java API, through the weblogic.websocket package, allows you to create WebSocket-based server side applications handling client connections, WebSocket messages, providing context information for a particular WebSocket connection and managing the request/response handshake. For additional information about the WebLogic WebSocket Java API interfaces and classes, visit the following resource: http://docs.oracle.com/middleware/1212/wls/WLPRG/websockets.htm#BABJEFFD
  • To declare a WebSocket endpoint you use the @WebSocket annotation that allow you to mark a class as a WebSocket listener that's ready to be exposed and handle events. The annotated class must implement the WebSocketListener interface or extend from the WebSocketAdapter class.
When you deploy the WebSocket-based application on WebLogic, you basically follow the same approach using the standard Java EE Web Application archives (WARs), either as standalone or WAR module. Either way, the WebLogic Application Server detects the @WebSocket annotation on the class and automatically establishes it as a WebSocket endpoint.

Here is a simple application that creates a WebSocket endpoint at the /echo/ location path, receives messages from the client and sends the same message back to the client.

import weblogic.websocket.WebSocketAdapter;
import weblogic.websocket.WebSocketConnection;
import weblogic.websocket.annotation.WebSocket;

@WebSocket(pathPatterns={"/echo/*"})
public class Echo extends WebSocketAdapter{

@Override
  public void onMessage(WebSocketConnection connection, String msg){
      try{
          connection.send(msg);
      }catch(IOException ioe){
          //Handle error condition
      }
  }

}

On the client side, you typically use the WebSocket JavaScript API that most of the web browsers already support.


There are many samples out there that you can use to test the implementation above. One quick way of doing that is to navigate to http://www.websocket.org/echo.html and then point the location field to your WebLogic server. If you follow the sample available on https://github.com/mjabali/HelloWorld_WebSocket then you'll end up with something like ws://localhost:7001/HelloWorld_WebSocket/echo/ for the WebSocket server application.

The sample client provided will be available at http://localhost:7001/HelloWorld_WebSocket/index.html after the WebLogic deployment. See the README.md file on GitHub for additional instructions.

Have fun!

Thursday, January 17, 2013

Configuring TIBCO Web Messaging to Securely Connect to TIBCO EMS

If you want to configure your TIBCO Web Messaging gateway, which normally lives in the DMZ, to connect to TIBCO EMS messaging backbone over a TCP connection, the procedure is straightforward. Just point to the TIBCO EMS server hostname and port number, assuming that's already open in the firewall, in the trusted network and that's it.

Something similar to the following service (stomp.jms) configuration should be enough:

<service>
  <accept>ws://${gateway.hostname}:${gateway.nonsecure.port}/jms</accept>
  <type>stomp.jms</type>
    <properties>
      <connection.factory.name>GenericConnectionFactory</connection.factory.name>
      <context.lookup.topic.format>%s</context.lookup.topic.format>
      <context.lookup.queue.format>%s</context.lookup.queue.format>
      <env.java.naming.factory.initial>
            com.tibco.tibjms.naming.TibjmsInitialContextFactory
      </env.java.naming.factory.initial>
      <env.java.naming.provider.url>
            tcp://${EMS.hostname}:${EMS.portNumber}
      </env.java.naming.provider.url>
      <destination.strategy>session</destination.strategy>
    </properties>
    <realm-name>dev_realm</realm-name>
    <authorization-constraint>
      <require-role>AUTHORIZED</require-role>
    </authorization-constraint>
  </service>

Now, if you want to configure an end-to-end secured enabled environment then some extra parameters are necessary to make everything work correctly. The service configuration below will give you what you need (most of them are self-explanatory) to enable that.

<service>
    <accept>wss://${gateway.hostname}:${gateway.secure.port}/jms</accept>
    <type>stomp.jms</type>  
    <properties>
     <connection.factory.name>SecureConnectionFactory</connection.factory.name>
      <context.lookup.topic.format>%s</context.lookup.topic.format>
      <context.lookup.queue.format>%s</context.lookup.queue.format>
      <connection.security.principal>ems_user</connection.security.principal>
      <connection.security.credentials>ems_password</connection.security.credentials>
      <env.java.naming.factory.initial>
          com.tibco.tibjms.naming.TibjmsInitialContextFactory
      </env.java.naming.factory.initial>
      <env.com.tibco.tibjms.naming.security_protocol>
          ssl
      </env.com.tibco.tibjms.naming.security_protocol> 
      <env.java.naming.provider.url>
         ssl://${EMS.hostname}:${EMS.securePortNumber}
      </env.java.naming.provider.url>
      <env.com.tibco.tibjms.naming.ssl_enable_verify_host>
         true
      </env.com.tibco.tibjms.naming.ssl_enable_verify_host>  
      <env.com.tibco.tibjms.naming.ssl_trusted_certs>
         ems_certificate.pem
      </env.com.tibco.tibjms.naming.ssl_trusted_certs> 
      <env.com.tibco.tibjms.naming.ssl_trace>
         true
      </env.com.tibco.tibjms.naming.ssl_trace>
      <destination.strategy>session</destination.strategy>
     </properties>
     <realm-name>dev_realm</realm-name>
     <authorization-constraint>
      <require-role>AUTHORIZED</require-role>
    </authorization-constraint>  
  </service>

The current version of TIBCO Web Messaging also provides you a really nice feature called Reverse Connectivity where you will be able to close all incoming traffic ports while still allowing external clients to initiate the connection. But, this is a topic to be explored on a next post. Stay tuned!

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...