Extending JMS to Web Devices over HTML5 WebSockets - JavaOne 2011

1 JavaOne 2011 © 2011 – Kaazing Corporation

Extending the Java Message Service

to Web devices over HTML5 WebSockets

Chris Barrow, Peter Moskovits Kaazing Corporation JavaOne - October 5, 2011


Agenda

l  HTML5 WebSockets vs. HTTP l  Java Message Service l  Implementing JMS over WebSockets l  Demos and code examples l  Kaazing WebSocket Gateway, JMS Edition l  Questions


Networked Applications

TCP socket Thick Client

Full duplex

Back-end server


TCP socket

HTTP

Thick Client

Browser Middleware

Half Duplex Full duplex

Full duplex

Networked Applications

Back-end server

Back-end server


HTTP Workarounds & Hacks

Browser Middleware

Half Duplex Full duplex

Back-end server


HTML5 WebSocket

l  Extends TCP across the web l  Full-duplex, single socket, very low overhead l  Shares port with HTTP (80/443) l  Enables new classes of networked apps

l  W3C API (JavaScript) l  IETF Protocol

WebSocket Back-end

server Browser

Full duplex


HTTP WebSocket

Overhead 1000s of bytes (headers) 2-6 bytes/frame (typical) Latency New connection each time None: Reuses existing

connection

Latency (polling) Must wait for next request No waiting Latency (long polling) None, if server is holding

a pending request (+ time to set up new connection)

No waiting

HTTP vs. WebSocket


Overheard…

"Reducing kilobytes of data to 2 bytes… and reducing latency from 150ms to 50ms is far more than marginal. In fact, these two factors alone are enough to make WebSocket seriously interesting to Google." Ian Hickson (Google, HTML5 Spec Lead)


Java

//Create and connect new WebSocket WebSocket mySocket = new WebSocket(); // Associate listener webSocket.addWebSocketListener( new WebSocketListener() { @Override public void onMessage(WebSocketEvent event) { alert(event.getData()); } @Override public void onClose(WebSocketEvent closedEvent) {} }; mySocket.connect(new URI("ws://www.WebSocket.org")); mySocket.send("Hello world!");

Using the WebSocket API


WebSocket Browser Support

Browser native support

§  Chrome §  Firefox (need to turn on)

§  Opera 10.7 (need to turn on)

§  Safari §  Internet Explorer 9+ Beta


Back-end server

Browser

WebSocket

JMS Over WebSocket


Back-end server

Browser

WebSocket

JMS Over WebSocket

JMS

Back-end server

Browser

WebSocket


Java Message Service


Why JMS?

l  WebSocket is a good start but doesn't offer much help to the application developer

l  JMS well established standard, widely available l  Offers important features over pure WebSocket:

l  Publish and subscribe (Topics) for broadcast l  Point to point (Queues) for command processing l  Transactions l  Guaranteed delivery l  Structured data


J2EE Applica+on Server

Why JMS over WebSocket?

Message Broker (JMS Provider)

JMS Web Container

SOAP over HTTP Web

Service

JSP

Firewall

Typical Current JMS Architecture

HTTP

EJB Container

EJB

WEB


J2EE Applica+on Server

Why JMS over WebSocket?

Message Broker (JMS Provider)

JMS Web Container

SOAP over HTTP Web

Service

JSP

Firewall

Typical Current JMS Architecture

HTTP

JMS Over WebSocket

Firewall

EJB Container

EJB

WEB

New WebSocket-based Architecture


Implementing JMS over WebSockets


1. JMS Client library (in browser, web device) 2. Protocol 3. Server (bridge between broker & web) 4. Message Broker (JMS Provider)

JMS over WebSocket


JMS Client Library

●  Implements the JMS objects and API l  Initiate WebSocket connection l  Encode outgoing JMS messages in STOMP l  Decode and deliver incoming messages

●  Manage connections and sessions, stop and start, message listeners, reconnect

●  A single WebSocket connection suffices (full duplex, asynchronous receive)


The Protocol

l  STOMP l  Text-based wire encoding, so suitable for multiple

client languages (Java, JavaScript, ...) l  http://stomp.codehaus.org & http://stomp.github.com !

l  Wireline encoding into STOMP: l  CONNECT\nNAME:name\n PASS:password (once) l  Encode JMS properties as key-value pairs:

-  SEND\nprop1:value\nprop2 -  MESSAGE\nprop1:value\nprop2

l  SUBSCRIBE\ndestination:/topic/stock

l  BEGIN, COMMIT, ABORT


JMS Client Library

●  session.createConsumer l  → SUBSCRIBE destination:xxx l  Await RECEIPT

●  producer.send l  → SEND prop1:val1... <text> l  Await RECEIPT

●  Separate thread(s): read MESSAGE's l  Route to appropriate MessageListener l  Send ACK


JMS Client Library

●  Transactions l  Group message sends and Acks l  Single unit of work

●  Auto-reconnect l  For resilience to network failures l  Reissue SUBSCRIBEs

●  Other client languages: l  Javascript, Flash, .Net


The Server

●  Bridge between Web and Message Broker l  Accepts WebSocket connections l  Connects to JMS provider

●  Converts incoming STOMP frames to JMS API calls

●  Routes messages from provider back to clients ●  Must manage flow control


The Server

l  Simplest implementation: l  Each client connection → 1 broker Connection and

Session l  Each client subscription (message consumer) → 1

consumer in broker l  More scalable:

l  1 connection for many clients l  Single topic subscription for many clients


Demos

http://portfolio.kaazing.me!

http://forex.kaazing.me!


Portfolio Demo

●  "stock" topic for stock price updates l  MessageConsumer stockConsumer!

l  MessageListener: portfolioModel.updateStock()!

●  Temporary queue for command responses l  responseQueue = session.createTemporaryQueue()!

●  "command" queue to send commands l  producer.send (replyTo=responseQueue) l  command property (get_portfolio, get_balance, buy, sell)


Code Examples

l  Creating a connection (omitting exception handling)

env.put(Context.INITIAL_CONTEXT_FACTORY, StompInitialContextFactory.class.getName()); env.put(Context.PROVIDER_URL, “ws://myhost:80/stomp.jms”); InitialContext ctx = new InitialContext(env); ConnectionFactory cf = (ConnectionFactory)ctx.lookup(“ConnectionFactory”); Connection connection = cf.createConnection();

l  Destination look up Topic stockTopic = (Topic)ctx.lookup(“/topic/stock”);


Code Examples

l  From there it's all just standard JMS API Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); MessageConsumer stockConsumer = session.createConsumer(stockTopic); // Listen for stock price changes stockConsumer.setMessageListener(new MessageListener() { @Override public void onMessage(Message message) { try { String stockData = ((TextMessage)message).getText(); portfolioModel.updateStock(new Stock(stockData)); } catch(JMSException e) { } } } connection.start();


A Real World Solution: Kaazing WebSocket Gateway


l  Java and JavaFX

l  JavaScript

l  Microsoft Silverlight and .NET

l  Adobe Flex (Flash)

WebSocket Client Support


WebSocket Emulation

Emulation for browsers with no native WebSocket support:

l  Kaazing WebSocket Gateway: makes WebSocket work in all browsers today:

l  Internet Explorer 6, 7, 8 l  Firefox 3.6 l  And more . . .


Kaazing JMS Edition

l  Messages traverse firewalls and proxies

l  Fast, secure communication over the Internet

l  Message distribution to massive numbers of clients thanks to resource offloading (fan-out)


Resource Offloading

●  Connection + Session offload (fan out) l  Reduces broker resource usage l  Minimal connections, sessions to broker

●  Java NIO (Apache Mina framework) ●  Subscription offload

l  Multiplexed over shared connection, single message consumer

l  Gateway tracks subscribed topics and queues from all connected clients

l  Gateway handles individual client acknowledgments


Resource Offloading


JMS Gateway Features

●  “stomp.jms” service l  Clients speak STOMP to the service. l  Service uses vendor's JMS API to talk to broker l  Connection, session and subscription offload

●  “stomp.proxy” service l  Clients speak STOMP to the service l  Service uses STOMP to talk to “stomp.jms” service

running on another Gateway l  Further offload

●  Gateway clusters for High Availability


Using Multiple Gateways

●  Hundreds of thousands of clients or more can be supported by using a network of gateways

●  “stomp.proxy” gateways at the edge (near users) l  Route messages to central gateway running

“stomp.jms” service l  Connection offloading (single connection to central

gateway)

●  Most network traffic is local ●  Use gateway clusters for HA


Using Multiple Gateways


Writing Applications

l  JMS API is available to code running within the browser or mobile device

l  Gateway provides client libraries l  Written like a Java JMS client l  Similar concepts and APIs for each client technology

(JavaScript, Flash, .Net) l  Application needs to include Kaazing JMS library files

(jars, .js)


Live Customer Application


Take-aways

l  HTML5 WebSockets offers a paradigm shift for highly interactive and scalable Web applications

l  High level protocols can be extended beyond the firewall all the way to Web devices:

l  JMS l  XMPP l  AMQP

l  Production solution with live customers available today


Conclusion

“We’re committed to providing real-time access to critical management information across the enterprise... Kaazing solves the industry’s fundamental issues which have kept yesterday’s web architecture from meeting these needs.”

Quintin Gomez, CTO of ITRS Group, 28 Sep 11


Questions and Answers

Extending JMS to Web Devices over HTML5 WebSockets - JavaOne 2011

Technology

Transcript of Extending JMS to Web Devices over HTML5 WebSockets - JavaOne 2011