DON'T CALL US - WE'LL PUSH – ON CROSS TIER PUSH ARCHITECTURE

Lucas Jellema – AMIS (Nieuwegein, The Netherlands)

JavaOne 2011, Birds of a Feather

OVERVIEW

• Asynchronous to the max• Push in enterprise architecture• The harsh reality of push• Web-tier to client

– Browser– Mobile App

• Client to client• Database tier to Business tier• Cross Server Push• Push All the way• The future of push

– Real time

ASYNCHRONOUS COMMUNICATION IN THE REAL WORLD• “I’ll get back to you”• “Don’t call us,…”• Low fuel warning in car• “Please let me know”• “Return to sender – address unknown” • Newspaper delivery• Next instruction from car navigation system• Telephone ringing• Alarm clock buzzing• Parking sensors beeping• Fire alarm screaming

ASYNCHRONOUS INTERACTIONS AND PUSH IN THE IT LANDSCAPE

• More timely information– Notification as soon as possible

• Proactive offering– Do not ask and you shall be given

• Lower load on back end – don’t call us (all the time) …– Stop hitting the F5 button!

• Multi-channel information manipulation and dissemination– Changes and events come in from everywhere

• Decouple system components through generic infrastructure for handling events and push– Yet integrate

PUSHING IT … INTO THE USER INTERFACE• Automatically refreshing (part of) a page

– Update table– Redrawing chart

• Displaying popup to alert user to an event– Arrival of message (email or chat)– Signing in or out of contact (presence)– Lock or release of some resource– Notification

• Changing status of items on the page– Highlight change indicator– Show icon– Change text to italic

• Play a sound

Web Browser

RDBMS

JEE Application Server

Mobile Device

Email Server Chat ServerRDBMS

JEE Application

Server

Web Browser

3 rd party

Mobile Device

Complex Event Processor

NonJava

Server

UPSTREAM NOTIFICATION

• Database to Middle Tier• Middle Tier to Browser

or Mobile device• Browser to other

Browser or Mobile deviceWeb Browser

RDBMS

JEE Application Server

Mobile Device

TYPICAL SERVER-TO-CLIENT PUSH SCENARIO: CHAT

Web Browser

JEE Application Server

AND CLIENT TO SERVER (TO SERVER)

Web Browser

JEE Application Server

THE ‘ONLY TELL WHEN ASKED’ GAME

SERVER PUSH CHALLENGES

• How to push against the ‘one way direction’ and despite limitations– HTTP and JDBC are request/response – not

response only– Browser limit of only two channels to one server

• Server side ‘event handling’– Session has to have an active life beyond

requests• Or requests have a life beyond response

– Higher load on the server– How to handle the (potential) volume of

‘concurrent’ channels and the number of open threads• NIO, Servlet 3.0, Jetty Continuations, Tomcat

Advanced I/O

SERVER PUSH CHALLENGES (2)

• Where do events to push actually come from?– Who perceives/receives (real-time) events (on

the server side)– How are they tied in to the appropriate

sessions?• Client (consumer) side: how to

asynchronously receive events and how to process them/turn them into action and UI updates

• How to correlate an asynchronously received message with a previously sent request or a subscription– For example: mobile phone showing SMS or

WhatsApp messages in a conversation thread style

SERVER TO WEB CLIENT

• AJAX – Asynchronous– Not as asynchronous as you might think

• Reverse AJAX – Comet , Push– Comet implementations

• Streaming – never ending response• Poll• Long Poll• Piggy Back (add push message to normal

response)• Embedded Applet doing raw TCP communications

– Flash with BlazeDS event streaming

• WebSockets

COMET – IMPLEMENTATIONS

• Client side: – many libraries – DOJO is most notable

• most AJAX/JavaScript based• Applets could also be used (via Applet/JS bridge)

• Server Side: – plain servlets, – Servlet 3.0 to alleviate the load on the server

from all the open long-lived requests …– Grizzly (GlassFish)– WebLogic HTTP Channel– GWT?– DWR – Direct Web Remoting– LightStreamer– Jetty– Zie: http://cometdaily.com/maturity.html

DIRECT WEB REMOTING

• Call client side JavaScript functions from Server– In multiple browser sessions– Synchronously as part of request handling– Asynchronously – as server (initiated) push

• Call server side Java methods from the Client– Leading to asynchronous (“background”) AJAX

calls

SERVER PUSH WITH DWR

• DWR configuration:– Servlet in web.xml– WEB-INF/dwr.xml with beans to expose to

JavaScript

Web Browser

JEE Application ServerClock

HTML + JavaScript

CLIENT TO SERVER PUSH TO CLIENT

Web Browser

JEE Application Server

SomeTableWithEventsCoordinator

HTML + JavaScript

Web BrowserHTML + JavaScript

SomeTableWithEventsCoordinator

EventsProcessor

Servlet

THE NUDGE

• Event should have small payload – just an indication of the type of event and a key-reference to the payload

• Based on the information, the consumer decides to retrieve the associated payload, using the keynudge handler

NudgeePayload

Retriever

Nudger

UI Component

WEBSOCKETS

• Protocol – TCP based, initiated with normal HTTP exchange– One more transport option for Comet– Finalized last week!

• Client and Server API– JavaScript (client)– Server side?

• Part of HTML 5– A very loose collection of proposals, concepts and

specifications• Supported in Chrome and Safari as well as

Firefox, …– Also from mobile platform

• Server Side Support very fragmented at this point– With the protocol finalized, server support will

rapidly emerge

Web Browser

JEE Application Server

Mobile Device

Web Browser

Mobile Device

CLIENT TO CLIENT

• Usually really a combination of– Client-to-Server– and Server-to-the-other-Client push

• Exception: Blue Tooth, Near-Field Communication

SERVER TO MOBILE PUSH:MULTIPLEXED, SEMI-POLL BASED

APPLE PUSH NOTIFICATION SERVICE• Persistent TCP/IP connection

– Continuously streaming• TCP/IP connection is initially set up by client

– Passing its identifier to APNS• Server side of applications can send

messages to APNS with the device identifier• APNS streams these messages to the device

– Message payload is JSON

APPLE PUSH NOTIFICATION SERVICE• Using APNS, only one channel is used for all

messages to be pushed to a device– Shared by many different applications

• APNS does store-and-forward (to retain messages when the client is off-line)

• Note: the push payload is very small (< 256 bytes)– just enough for the client to initiate a request for

the real information

ANDROID PUSH NOTIFICATION MULTIPLEXED FROM THE CLOUD

CROSS GAP PUSH MECHANISMS

• Many channels are available to push messages from one entity to another– across application, technology and location

boundaries• JMS (Java/JEE specific) • (one way) WebService (SOAP or REST)• “HTTP Channel”• WebSockets• Http Call to Servlet• XMPP

JMS (JAVA MESSAGE SERVICE) == THE “INTER APPLICATION MAIL MAN”

Application A Application B

JMSQueue

Application C Application X

• JMS is perfect for highly decoupled, scalable, cross JVM/cross server, reliable event push

• JMS is available on any JEE platform• JMS is Java only

– Mobile devices, browsers, databases and .NET do not speak JMS

JMS QUEUE/TOPIC LISTENER

• JMS Listener is notified asynchronously of messages

• Start background job on behalf of web app– Note: spawn thread from Servlet or EJB is not

recommended– Create report, send email, execute batch job

• Listen to events on behalf of web application

– And inform web application of relevant stuffJMS Queue or Topic MDB Web Application

?

EJB

JMS Queue or Topic MDBWeb Application

LIVE VOLLEYBALL REPORTING

JMS Q

ueueBAM

Web Browser

Data Object

Listener (http

channel, JMS, ..)

UI handler

CROSS TIER PUSH – ARCHITECTURE PATTERN

event handler

Scheduled Poll Job

listener listener listener

register

Push Receptor

Payload Retriever

‘Events collector’

THE HOLLYWOOD PRINCIPLE: QUERY RESULTSET CHANGE NOTIFICATION

MIDDLE TIER ALERTED BY DATABASE

SQL query

Register

DatabaseChange

Notification

Oracle RDBMS invokes

Java Listener with event

details

REGISTER DATABASE CHANGE LISTENER

QUERY RESULT CHANGE LISTENER

UPDATE IN DATABASE TRIGGERS NOTIFICATION TO JAVA LISTENER

MULTIPLEXED POLL-BASED DATABASE-TO-MIDDLE TIER PUSH• When no Database Query Result Change

Notification is available – a trick is needed• Some databases can do HTTP calls:

DATABASE TO MIDDLE TIER TO CLIENT NOTIFICATION

Application Scope event handler

HTTP

Proce-dure

servlet

Session cache

EMP

servlet1

2

3 45

6

7

8

9A

D

B

C

Job

DEMO CROSS TIER PUSH – DATABASE MIDDLE TIER BROWSER

MULTIPLEXED POLL-BASED DATABASE-TO-MIDDLE TIER PUSH• A poll based approach can emulate the push

behavior– One thread in the middle tier does polling on behalf

of all sessions: a single channel– A single table in

the database isused to collectall ‘pushable events’

– Middle tier pollretrieves new entries from thetable and publishedevents to centralevent handler

– Listeners registeredwith a centralevent handler

Application Scope event handler

Proce-dure

Scheduled Job

Notifications

session

CD_TBL

sessionsession

FUTURE DEVELOPMENTS

• The real time enterprise• The event driven enterprise• Further evolution of push notification at

every tier– Mobile perhaps leading the way

• Infrastructure and frameworks providing push mechanisms

• Servlet 3.0, Java NIO, WebSockets,SPDY, XMPP and other lighter weight solutions for bi-directional communication over TCP– And broad support in browsers

and application servers– For example: upcoming

WebSockets supportin Glassfish and WebLogic

SUMMARY

• Asynchronous interaction is good for decoupling, decreasing load on system and increasing timeliness

• Push is valuable at various levels and between different components in the enterprise architecture

• Challenges: – push is often against the [http, JDBC,..] grain– correlate push notifications into right consumer– handle asynchronously received push messages– prevent swamping of infrastructure

• Server to client push will gain in scalability and ease– Thanks to WebSockets and implementations thereof

and libraries (e.g. Dojo) leveraging it– Also used for server-to-server and client-to-client

• Push is an essential ingredient of modern applications – from browser and mobile to middle tier and database