.

1. Lucas Jellema – AMIS (Nieuwegein)
DON'T CALL US - WE'LL PUSH –
ON CROSS TIER PUSH ARCHITECTURE
JavaOne 2011, Birds of a Feather

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

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

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

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

6. Mobile Mobile
Device Device
Web Browser Web Browser
Non
Complex Event JEE Application JEE Application
Java
Processor Server Server
Server
Email
RDBMS Chat Server
RDBMS Server

7. UPSTREAM NOTIFICATION
• Database to Middle Tier
• Middle Tier to Browser Mobile Device
or Mobile device
• Browser to other Web Browser
Browser or Mobile device
JEE Application Server
RDBMS

8. TYPICAL SERVER-TO-CLIENT PUSH
SCENARIO: CHAT
Web Browser
JEE Application Server

9. AND CLIENT TO SERVER (TO SERVER)
Web Browser
JEE Application Server

10. THE „ONLY TELL WHEN ASKED‟ GAME

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

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

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

14. COMET – IMPLEMENTATIONS
• Client side:
– many libraries – DOJO is most notable
• most are 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
– DWR – Direct Web Remoting
– LightStreamer
– Jetty
– Zie: http://cometdaily.com/maturity.html

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

16. SERVER PUSH WITH DWR
• DWR configuration:
– Servlet in web.xml
– WEB-INF/dwr.xml with beans to expose to JavaScript
Web Browser HTML +
JavaScript
JEE Application Server
Clock

17. CLIENT TO SERVER PUSH TO CLIENT
HTML + Web Browser Web Browser HTML +
JavaScript JavaScript
Servlet
JEE Application Server
Events
Processor
SomeTableWithEvents SomeTableWithEvents
Coordinator Coordinator

18. ASYNCHRONOUS JOB
PROGRESS INDICATOR

19. SPIN OFF ANOTHER THREAD TO DO THE
WORK AND INFORM ON PROGRESS
Web Browser
HTML +
JavaScript
Servlet
ServerSide DWR Bean
Perform long running
job & report progress

20. DEMO

21. 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 key
nudge handler UI Component
Payload
Nudgee Retriever
Nudger

22. CLIENT TO CLIENT
• Usually really a combination of
– Client-to-Server
– and Server-to-the-other-Client push
• Exception: Blue Tooth, Near-Field Communication
Mobile Mobile
Device Device
Web Browser Web Browser
JEE Application
Server

23. SERVER TO MOBILE PUSH:
MULTIPLEXED, SEMI-POLL BASED

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

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

26. ANDROID PUSH NOTIFICATION
MULTIPLEXED FROM THE CLOUD

27. WEB SOCKETS
• Protocol – TCP based, initiated with normal HTTP
exchange
– One more transport option for Comet
– Finalized last month
• 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

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

29. JMS (JAVA MESSAGE SERVICE) ==
THE “INTER APPLICATION MAIL MAN”
• 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
Application A Application B
JMS
Queue
Application C Application X

30. 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
Web JMS Queue or
Topic MDB
Application
• Listen to events on behalf of web application
– And inform web application of relevant stuff
JMS Queue or ? Web
Topic MDB
Application
EJB

31. LIVE VOLLEYBALL REPORTING
Web Browser
JMS Queue
UI handler
Listener
(http
channel,
JMS, ..)

32. CROSS TIER PUSH –
ARCHITECTURE PATTERN
listener listener listener
register
event handler
Scheduled Payload Push
Poll Job Retriever Receptor
‘Events
collector’

33. THE HOLLYWOOD PRINCIPLE:
QUERY RESULTSET CHANGE NOTIFICATION

34. MIDDLE TIER ALERTED BY DATABASE
SQL query

35. REGISTER DATABASE CHANGE
LISTENER

36. QUERY RESULT CHANGE LISTENER

37. UPDATE IN DATABASE
TRIGGERS NOTIFICATION TO JAVA
LISTENER

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

39. DATABASE TO MIDDLE TIER TO CLIENT
NOTIFICATION
Session Application Scope
cache event handler
D
5 3 C 4 9
A
1 servlet servlet
2 8
B HTTP
Proce
7 -dure
EMP 6
Job

40. DEMO CROSS TIER PUSH – DATABASE
 MIDDLE TIER  BROWSER

41. 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 is Application Scope
used to collect event handler session
all „pushable session
Scheduled
events‟ session
Job
– Middle tier poll
retrieves new
entries from the
table and published CD_TBL
events to central
event handler
Notificat
– Listeners registered ions Proce
-dure
with a central
event handler

42. 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 support
in Glassfish and WebLogic
– Project Avatar

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