Games, chat, and financeToward a truly interactive web withComet, BAM, and HMTP
Emil OngChief Evangelist
Caucho Technology
Resin has been around for 10 years Over 8000 customers, even more open source
users User base consists of both early and
conservative adopters Now the top Java web server in NetCraft
http://survey.netcraft.com/Reports/200805/ 340,000 domains
Groundbreaking Innovations
Hessian web services protocol Top clustering implementation Quercus: PHP in Java Server-push And now... a revolutionary approach to the
interactive web
The Interactive Web
Common properties1) Sessions are long-lived2) Must be responsive/ real time3) Must not overburden server
4) Communication is bidirectional
Killer apps Games Chat Finance
The Interactive Web with HTTP
1) Sessions are long-lived2) Must be responsive/real time3) Must not overburden server4) Communication is bidirectional
This is harder with HTTP
Comet has shown thisis possible
Simulating Bidirectional Communication with HTTP
Client generated events are easy They are simply requests
AJAX just makes those requests without changing the page
What about the other direction?
Sending events from server to client using HTTP
Polling Requests at regular intervals that complete
immediately Long Polling
Requests that wait for the next event, then restart Server-push (Comet)
Socket held open with streaming updates from the server
Techniques compared
Advantages DisadvantagesPolling ● Easy to do in
browser now● Event impedance
mismatch● Socket construction/
teardownLong Polling ● Easy to do in
browser now● Less likely to miss
events
● Taxes most currentservers
● Socket construction/teardown
Server Push ● Possible in browsernow
● Unlikely to missevents
● Many servers notprepared
● No standardprogramming model
Server-Push (Comet)
Current hot technology Implementations
Resin Grizzly (Glassfish) Jetty Tomcat
All solve the problem of threads dedicated to a socket
All have a different programming model
The problem of Bidirectional Communication with HTTP
Different techniques for send and receive Use AJAX to send data from client Use Comet to receive data on client
Two connections required* Places limitations on TCP that were necessary
for scalability in the past A necessary evil at the moment
Truly Interactive Communication
Must be capable of long-lived connections Must be responsive/real time Must not overburden server Must be bidirectional Must have a simple, coherent API/architecture
Creating the architecture
Start with the communication patterns Messages Request/response
Truly bidirectional communication Client -> Server Server -> Client Both must be supported in both patterns
Creating the architecture
Representation of entities Agents
Bidirectional communication implies that clients are first class citizens
Agents represent both clients and servers A broker manages communication between
agents
Brokered Agent Messaging (BAM)
Broker Handles communication between
agents It's not CORBA
Agents Represent both clients and services
Messaging Messages Request/response (asynchronous)
Example: Sudoku
Demo
Client 1
Resin
Broker
Client 2
LoginQuery Client
Agent 1
LoginQuery
ClientAgent 2
Logging In
SudokuService
Game 1
AvatarAgent 1
Client 1
Resin
Broker
Client 2
ClientAgent 1
ClientAgent 2
SudokuService
StartQuery
WaitResult
StartQuery
AvatarAgent 2
StartResultStart
Message
Starting a game
Game 1
AvatarAgent 1
Client 1
Resin
Broker
Client 2
ClientAgent 1
ClientAgent 2
SudokuService
MoveQuery
AvatarAgent 2
MoveMessage
MoveResult
Making a Move
Game 1
AvatarAgent 1
Client 1
Resin
Broker
Client 2
ClientAgent 1
ClientAgent 2
SudokuService
MoveQuery
AvatarAgent 2
MoveMessage
MoveResult
Game overMessage
Game overMessage
Ending the Game
Design notes
Agents can be long-lived SudokuService Client
Agents can be short-lived SudokuAvatar
Agents are lightweight and dynamic Non-agents can interact with the system
SudokuGame
Code sample: SudokuAvatar
public boolean sendQuerySet(long id, String to, String from, Serializable value) { if (value instanceof MoveQuery) { MoveQuery query = (MoveQuery) value; MoveResult result = _game.move(query, getJid());
_broker.sendQueryResult(id, from, to, result); return true; ...
BAM API void sendMessage(String to, String from, Serializable value)
boolean sendQueryGet(long id, String to, String from,
Serializable query)
boolean sendQuerySet(long id, String to, String from, Serializable query)
Address space
Agent names look like email addresses: [email protected]/3
First component: service name (sudoku) Second component: domain (caucho.com) Third component: instance identifier (/3) Address structure reflects lightweight nature of
agents
Hessian Message Transfer Protocol(HMTP)
Wire protocol on which BAM is based Uses Hessian for compact serialization Evolved from XMPP (Jabber)
Target platforms
Flash/Flex Silverlight JavaFX Java Applets Comet (interim) Java Quercus (PHP) .NET
Conclusion
Interactive applications will become more common
HTTP is not sufficient to handle them BAM outlines a new architecture and API to
make the development of these applications easier
What's next?
Technical Convenience functions Making a PHP page a BAM service HMTP standardization
Promotional Game contest
Thank you!
Questions? Comments?
Appendix: Bridging BAM and Comet
Initial Comet request creates agent Agent triggers event to client on messages On AJAX requests, pull agent name from
session