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 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 properties 1) Sessions are long-lived 2) Must be responsive/ real time 3) Must not overburden server 4) Communication is bidirectional Killer apps Games Chat Finance

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

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 Login Query Client Agent 1 Login Query Client Agent 2 Logging In Sudoku Service

Game 1 Avatar Agent 1 Client 1 Resin Broker Client 2 Client Agent 1 Client Agent 2 Sudoku Service Start Query Wait Result Start Query Avatar Agent 2 Start Result Start Message Starting a game

Game 1 Avatar Agent 1 Client 1 Resin Broker Client 2 Client Agent 1 Client Agent 2 Sudoku Service Move Query Avatar Agent 2 Move Message Move Result Making a Move

Game 1 Avatar Agent 1 Client 1 Resin Broker Client 2 Client Agent 1 Client Agent 2 Sudoku Service Move Query Avatar Agent 2 Move Message Move Result Game over Message Game over Message 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 addresses: 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

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