Games, chat, and finance
Toward a truly interactive web with
Comet, BAM, and HMTP
Emil Ong
Chief 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

Killer apps

Games
 Chat
 Finance

Common properties
1) Sessions are long-lived
2) Must be responsive/ real time
3) Must not overburden server
4) Communication is
bidirectional
The Interactive Web with HTTP
1) Sessions are long-lived
2) Must be responsive/real time
3) Must not overburden server
4) Communication is bidirectional

This is harder with HTTP
Comet has
shown this
is 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


Long Polling


Requests at regular intervals that complete
immediately
Requests that wait for the next event, then restart
Server-push (Comet)

Socket held open with streaming updates from the
server
Techniques compared
Polling
Long Polling
Advantages
● Easy to do in
browser now
●
●
Server Push
●
●
Disadvantages
● Event impedance
mismatch
● Socket construction/
teardown
Easy to do in
● Taxes most current
browser now
servers
Less likely to miss
● Socket construction/
events
teardown
Possible in browser
● Many servers not
now
prepared
Unlikely to miss
● No standard
events
programming 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
Logging In
Resin
Login
Client
Query1
Client
Agent 1
Broker
Login
Client
Query2
Client
Agent 2
Sudoku
Service
Starting a game
Resin
Start
Client
Query1
Client
Agent 1
Avatar
Agent 1
Game 1
Start
Client
Query2
Client
Agent 2
Broker
Avatar
Agent 2
Sudoku
Wait
Start
Service
Result
Message
Making a Move
Resin
Move
Client
Query1
Client
Agent 1
Avatar
Agent 1
Move
Message
Result1
Game
Client 2
Client
Agent 2
Broker
Avatar
Agent 2
Sudoku
Service
Ending the Game
Resin
Move
Client
Query1
Client
Agent 1
Avatar
Agent 1
Game
Move
over
Message
Result1
Game
Client 2
Client
Agent 2
Broker
Avatar
Agent 2
Sudoku
Service
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?
More information

http://hessian.caucho.com/

http://blog.caucho.com
/
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