| Beginning HTTP - HTTP was designed as a protocol for retriving documents from remote servers
- Communication between the client and the server is always initiated by the client and never by the server
- Connections between the client and the server are transient and the server do not maintain any long-term state information regarding the client
|
| Twist the Formula - Why, then, should you want the server to be able to contact the client, and maintain persistent connections?
- There are several suitable common use case - |
| use cases: AdviceME - Monitoring and Data Feeds
- Client as a Dashboard or Monitor
- Demand for monitoring applications
- Market data feeds
- Security Alerting
- SLA Violation Advisor
|
| use cases: Please Wait - Progress Updates
- Communicating progress on long-running server-side activities
- Report progress on long running server task
|
| use cases: Share with me - Chat and Collaboration
- Chat System
- Photo sharing
- On-Line Gaming
- Collaborative Tools
|
| Actual Approachs - Push Using Poling
- Collaborative ability by pooling the server with client regular request asking for update.
- Network wasteful
- Server resource exhaustion
- Client repeatedly contact the server to check for change
- Pooling schedule not affected
|
| Actual Approachs - Piggybacking
- The contents of the response aren’t strictly related to the nature of the request
- Response will also contain any changes to the domain model
- Pooling schedule reset
|
| <<COMET>> - Comet techniques
- Keep the response stream open for a significantly longer time
- Server send several pieces of data back in the response
- Comet request is held open on the server for a while, multiple discrete changes are communicated
- Long Polling
|
| <<COMET>> |
| <<COMET>> - Comet techniques
- Traditional servers allocate a thread to each incoming request
- Design work well when serving large volume of short lived request
- Long polls are held open request for a considerable length of time.
- Thread-per-Request model is generally unable to scale to large numbers of clients.
- Java servlet model itself is inherently a thread-per-request
|
| <<Java COMET>> - Comet techniques
- Java servlet model was developed to serve a very different traffic profile.
- A large number of simultaneous request from Comet clients would exhaust the server’s thread pool. (doesn’t scale well)
- More Comet-Friendly server architectures from the java-community:
- Continuations (Jetty 6)
- Grizzly
- Tomcat 6
- JSR 315 Servlet 3.0
|
|
Bayeux provides a very nice abstraction on top of Comet transport, by casting the transfer data in terms of channels, to which clients can publish and subscribe
Comet and Reverse Ajax Dave Crane and Phil McCarthy (2008) |
| Bayeux --> CometD - Bayeux
- Emerging de facto standard for Comet
- Existing reference implementation:
- COMETD
- Provided by the people at Sitepen:
- (the same as) Dojo Javascript Toolkit
|
| Bayeux --> CometD - Bayeux
- Adopts exactly the same approach and provides a flexible, scalable API based around a publish-subscribe model
- Data sent through, is always assigned a notional “channel”
|
| Bayeux --> CometD - Bayeux
- Channels allows multiple decoupled conversations on top of a single HTTP connection.
- The client-side CometD and the server-side Bayeux implementation communicate over several notional channels, all bundled within a single HTTP request-response.
|
| Purpose - Cometd is a project by the Dojo Fundation to implement Bayeux specification.
- Bayeux is a purpose to implement responsive user interaction for web clients using Ajax and server-push technique called Comet
- The messages are routed via named channels and can be delivered:
- server2client
- client2server
- client2client (via server)
|
| JSON Messages Bayeux message are specified in JSON notation { "channel": "/some/name", "clientId": "83js73jsh29sjd92", "data": { "myapp" : "specific data", value: 100 } } JavaScript Object Notation is a lightweight data-interchange format |
| Channels Style - Channels are by default broadcast publish subscribe.
- Channels are identified by names and always starts with “/”
- Channel pattern support trailing wildcards of either “*” or “**” :
- /news/*
- Valid channels : /news/italy , /news/uk ....
- /news/**
- Valid channels : /news/italy , /news/italy/lazio ...
|
| Bayeux approach - Bayeux event is sent from the server to the client via HTTP response to a HTTP request sent in anticipation:
- Polling Transport
- On receipt of the HTTP response, the bayeux client issues a new bayeux message.
- Streaming Transport
- Use streaming technique (forever response), allowing multiple message to be sent over the same response
|
| Bi-Direction - To solve the issue of bi-directional communications, Bayeux client will use two HTTP connections:
- Messaging may occur asynchronously
|
| Handshake Connect - Bayeux connection are negotiated between client and server with handshake messages that allow to define:
- Connection Type
- Authentication
- Persistence subscription
- Identification .....
|
| Interactions - Bayeux client may send publish and subscribe messages to register interest in a channel:
|
| Server APIs - Web application developers can optionally use server-side pub-sub APIs in their servlets or Java classes to get the Bayeux server context, manage channels, and the incoming and outgoing messages
|
| WebLogic Stock Demo - There is a useful sample in the WebLogic 10.3 installation about this technology:
- Can find it in the folder :
- {ORACLE_HOME}\wlserver_10.3\samples\server\examples\src\examples\webapp\pubsub\stock
- The demo describes a real-world scenario based on stock trading, and makes extensive use of the Bayeux APIs in both the server and client components
- The Demo uses :
- Dojo as its client-side library
- WebLogic Bayeux implementation as server APIs
|
| Web XML-Configuration - Server dedicated file-based configuration environment
|
| Security Model - JEE security configuration based (ssl support)
|
| JMS-Bayeux - Durable subscriber and persistence support, based on JMS architecture
|
| Message Persistance - Persistent Channels and session-message failover support
|
| JS Client APIs - Dojo JS Cometd library (Init and Publish)
- Initialize the Dojo cometd environment.
dojo.io.cometd.init({}, "/servletContextMapping/cometd");
- Publish a message to a channel.
dojo.io.cometd.publish("/a/channel", "message content");
dojo.io.cometd.publish("/a/channel", {"data": "content"}); |
| JS Client APIs - Dojo JS Cometd library (Subscribe)
Subscribe to a channel
dojo.io.cometd.subscribe("/a/channel", null, "onUpdate");
function onUpdate(message) {
if (!message.data) {
alert("bad message format "+message);
return;
} var data = message.data;
} |
| JS Dinamic Demo - Dynamic Channel sub & unsubscription
function subscribe(symbol) { dojo.io.cometd.subscribe("/stock/"+symbol, null, "onUpdate"); } function unsubscribe(symbol) { dojo.io.cometd.unsubscribe("/stock/"+symbol, null, "onUpdate"); }
function subscribeAll() { var count = itemsStore.get().length; for (var i=0; i<count; i++) { subscribe(itemsStore.getDataByIndex(i).symbol); } } |
| Web Publisher - Simple web-based client publisher (stock publisher)
|
| Some useful link - Bayeux specification provides only a protocol definition
- Cometd is a project by the Dojo Foundation to produce a specification (Bayeux) and a set of implementations of that specification (Cometd)
|
| Some useful link - Bayeux Java server-side implementation
|
| Some useful link - Bayeux others-server side implementation
- Flash FlexComet
- Perl CometdPerl
- Python CometdTwist
|
| |
| Nino Guarnacci nino.guarnacci (AT) oracle.com |
Comments (1)
Nino, I would also encourage anyone that is interested in trying this with WLS to look at my series about this:
http://blogs.oracle.com/jamesbayer/2008/10/realtime_updates_on_webpages_p_1.html
The version of Dojo that shipped with the WLS 10.3 sample is old (0.9 maybe?) and the API's have changed in the later releases from the examples that you use in your slides.
Thanks, James
Posted by James Bayer | February 9, 2009 2:37 PM
Posted on February 9, 2009 14:37