XmlBlaster provides a framework to callback browsers (push mode) using a never
closing HTTP connection.

Description

What is this?

When distributing dynamic, event driven content over the internet, you usually choose an applet.
The applet connects to the server over CORBA (or any other protocol) and may receive
instant notification from the server.
But applets produce some well known problems like higher download time,
firewalls which won't allow TCP/IP connections, applet-javascript communication
problems with some Java-VM's etc.
Note however that our requirement client.java.applet solves most of those problems.

This framework addresses these issues.
It establishes a persistent http connection to allow instant callbacks of xmlBlaster messages to the browser.

The browser callback framework is based on Java Servlets and some Javascript code.

The Java Servlet BlasterHttpProxyServlet.java keeps
a permanent HTTP connection to the browser and a CORBA connection to
xmlBlaster.

Features

Complete object oriented xmlBlaster access in the browser with Javascript, see callback.js

The Javascript files callback.js and util.js provide the functionality
on the browser side, xparse.js allows to parse the xml messages in the browser.

Very frequent message updates break the browsers, therefor the
servlets automatically queues messages until the browser is ready again.

The callBackFrame queues messages until the frames processed them.

The callBackFrame is an own window, to avoid window resize problems
of your application windows, and to avoid a 'waiting' cursor.

The http connection is pinged automatically with small but
big enough dummy data, so that the connection does not close.

The browser responses on a ping with a 'pong', notifying the servlet
that it is alive.

The browser Javascript code is traceable with the Log Javascript class in util.js

If you are logged in with your browser already and want in a later stage
start the persistent connection, you can pass the login name and password using
one of the following ways:

1. Variant: Passing infos using the URL (index.html example see below):
document.location.href = "index.html?ActionType=login" +
"&xmlBlaster.loginName=" + myLoginName +
"&xmlBlaster.passwd=" + myPassword +
"&xmlBlaster.invalidate=false");
// xmlBlaster will read these variables and use them to login to xmlBlaster.
2. Variant: Passing infos in a servlet with the session object:
// prevent BlasterHttpProxyServlet from creating a new session ID:
session.putValue("xmlBlaster.invalidate", "false");
session.putValue("xmlBlaster.loginName", myLoginName);
session.putValue("xmlBlaster.passwd", myPassword);
response.sendRedirect("/index.html"); // index.html example see below
// xmlBlaster will read these variables and use them to login to xmlBlaster.

How does it work?

A callback frame in the browser refers to the BlasterHttpProxyServlet.
Using the ActionType parameter set to login, the BrowserHttpProxyServlet holds the HTTP connection
if login to the xmlBlaster succeeds.
This permanent HTTP connection is held by the HttpPushHandler, which pings each
40 sec the browser. This functionality ensures that the browser won't close the connection.

The ProxyConnection connects to xmlBlaster using CORBA or any other supported protocol.

The messages from the xmlBlaster are directly (ProxyConnection.update - HttpPushHandler.update)
transferred to the browser, which has a Javascript
based XML parser and notifies the interested browser frames about the callback.
You can provide as many own frames as you wish. This is the work which
is left for you to design your web layout.

If you have too many messages in a short time frame, your browser won't process all of this
message. For this you can use an additional ready frame. Connect this frame also with
the BlasterHttpProxyServlet using ActionType=browserReady. Each reload of this frame
indicates your permanent HTTP connection (HttpPushHandler) that your browser is ready to
process more messages. HttpPushHandler will send you the whole queue each update.
The hidden callback frame is always necessary to handle the communication,
in your parent frame you have to include callback.js, util.js and xparse.js.

For Servlet and Javascript examples have a look into the following directory
of the xmlBlaster distribution:

NOTE: Configuration parameters are specified on command line (-someValue 17) or in the
xmlBlaster.properties file (someValue=17). See requirement "util.property" for details.
Columns named Impl tells you if the feature is implemented.
Columns named Hot tells you if the configuration is changeable in hot operation.

Todo

The framework allows to directly subscribe from Javascript,
these requests are routed over the doPost() method of BlasterHttpProxyServlet.