Web and Push Technologies
Benoît Xhenseval.
This paper will describe some (may be most) options offered to a development team for interactions between a browser and a server.
Ultimate Aim: to provide asynchronous data down TO the browser.
To illustrate this example, let’s think about a trading page. The user has logged on and is presented a screen where he/she decides to buy or sell stock but we would like to see the real-time price on this screen so he/she can jump and buy/sell.
The reader will be aware of the difference between an indicative price and a good quote. Only good quote can be traded. They usually have a timeout associated with them (in seconds).
Today’s project managers and technologists are facing a marketing decision: how many people do we want to reach on the Internet? The more you put on the client side, the less people are able to use the application.
Here is a summary list of the technologies: as you go down the list, the reachable audience goes decreasing. We have up-front dismissed options that would require esoteric plug-ins like Flash technologies or so.
- Pure HTML
- Pure HTML with frames
- HTML with Javascript
- Simple Applet with JDK 1.02 and AWT and HTTPS connectivity
- Applet with Swing (plug-in required) and HTTPS connectivity
- Applet with IIOP or socket connectivity (firewall opening)
Now let’s look at the options in details, with pro and cons.
Pure HTML
The dealing screen is a single frame html page. The user must first ask for a quote for a stock (new page download) and reply to the server within a given time in order to get the price displayed.
Pros
- Maximum reach on the internet.
- No firewall issue.
- Client pull à "quote on request", quote server can be stateless (each request is treated as a new one).
Cons
- Simple GUI, no push possible unless refreshing full screen (ugly flickering, possible delays).
- Not a proper responsive platform for real-time dealing.
Pure HTML with frames
The dealing screen is a pure HTML page but can use frames. Typically, one frame could be used to display the prices by refreshing it itself.
The user must still ask for a quote for a stock (new page download) and reply to the server within a given time in order to get the price displayed.
Pros
- Near-maximum reach (who does not have a browser that supports frames?)
- No firewall issue.
- Client poll à quote server can be stateless.
Cons
- Simple GUI, no true-push possible.
- Browser can refresh the price frame but it is by polling only indicative price (it is not on the "dealing screen", the user has to request a quote)
- Not a proper responsive platform for real-time dealing.
HTML with Javascript
The dealing screen is a pure HTML page but can use frames. Typically, one frame could be used to display indicative prices by refreshing it itself but this time, thanks to a bit of javascript, the price can be picked up automatically by the dealing screen.
The user must still ask for a good quote for a stock (new page download) and reply to the server within a given time in order to get the price displayed.
Pros
- Wide-reach on the internet (IE 3.0+ and Netscape 3+)
- No firewall issue on our server side; the client's firewall must let javascript through.
- GUI can be made more interactive and provide some basic "checking" and parameter validation.
- Client poll à quote server can be stateless.
Cons
- Javascript support varies widely between IE and Netscape.
- Browser can refresh the price frame but it is by polling only indicative price (it is not a quote).
- Not a proper responsive platform for real-time dealing.
Simple Applet with JDK 1.02 and AWT and HTTPS connectivity
The client receives a simple applet using JDK 1.02 and AWT. The applet polls the server through HTTP messages for rates. XML could be used between client and server.
Pros
- More professionally-looking GUI more logic can be put there.
- Prices appear automatically in the right place on the screen.
- User can decide anytime to trade.
- No need to open firewall sockets
- Client poll à quote server can be stateless.
Cons
- Firewall at the client side must allow applet.
- Browser at the client must have a JVM and allow it to run. (Navigator 3+ and IE 3+)
- Increased initial download time.
- No real-time price to the browser, it is a client pull.
The HTTP connectivity can be based on one of the following:
- HTTP request sent to a CGI program
- HTTP request handled by a servlet
- RMI or CORBA request through HTTP tunneling, an IIOP request is sent to the server.
HTTP Connectivity Options
HTTP Request handled by CGI
Let’s be serious here...
HTTP request handled by servlets
An http request can be sent to the server, handled by a servlet and the result sent back as XML.
Pros
- No firewall issue (using normal http port)
- Flexible XML
- Client poll à quote server can be stateless.
Cons
- No push, client pull.
- XML parsing at the client, need extra classes.
- Need to define a "protocol" to send request, handle replies and exceptions.
RMI or CORBA through http tunneling
An IIOP request can be sent to the server through http , it is handled by gateway provided by the CORBA-supplier and results are sent back to the client through http.
Pros
- No firewall issue (using normal http port)
- IDL interface, no need to write code to marshall/unmarshall values and exceptions.
- Client poll à quote server can be stateless.
Cons
- No push, client pull.
- IDL interface (fixed!).
- Have to buy a CORBA/HTTP gateway product.
Applet with Swing GUI
This option uses Swing as its GUI package, whether we are using JDK1.1,JDK1.2.,etc
Pros
- Better quality GUI.
- GUI easier to develop.
Cons
- Firewall at the client side must allow applet.
- Browser at the client must have a JVM and allow it to run. (Navigator 3+ and IE 3+)
- Browser must have the plug-in installed, either for JDK1.1 or JDK1.2
- Increased initial download time.
- Might run slower than AWT GUI.
Applet with IIOP or socket connectivity
The applet establishes an IIOP connection to the server through a gateway running on the web server. The browser only requests prices.
Pros
- Only IIOP involved, faster.
- IDL interface, no need to write code to marshall/unmarshall values and exceptions.
- Client poll à quote server can be stateless.
Cons
- Need to open a new port on web server, firewall issue.
- No real push, client pull.
Applet with real server push
The applet receives prices when these are updated on the server side, as such the client has subscribed to a topic. These prices are quotes that can be traded. This is the most responsive, near-time option.
It is suggested that the data format could be XML for maximum flexibility.
Pros
- Most responsive, near-time data sent to each client.
Cons
- Scalability issues on server if lots of users.
- Complexity the server must keep list of users and what they are interested.
- Need to open both firewalls at client site and our side (other socket than http).
Push Technologies Available
Here is a list of the current options available for push technologies.
Socket callbacks
Both client and server are establishing a socket connection and sending subscription request. Subsequently, the server will use the socket on the client applet to send updates.
Pros
- No need for extra software, can run on any JDK.
Cons
- Need to define a low-level protocol for waiting, handling updates and exceptions.
- Server might run out of sockets.
- Complex server needs to store the connections and check their validity on a regular basis (if client has left/crashed).
IIOP callbacks
The applet implements an interface, connects to an IIOP quote server through a gateway and registers on a subject giving a reference to its interface.
Pros
- Simple, well defined interface.
Cons
- Tight coupling between applet and server.
- Server must persist client connections.
- Server must be scalable.
- Server is responsible for contacting each client and handle exceptions (browser closed/etc)
- Need more software on applet.
IIOP with Cos Event/Notification Service
The applet connects to an IIOP quote server through a gateway and registers on a subject. It receives a publisher interface that is handled by a third server in charge of sending the data to each client.
The quote server simply needs to know the appropriate channel for the updates and simply sends the data once, regardless of the number of clients interested.
Pros
- Third party software (Event/Notification service) responsible for persistence, scalability and exception handling for the distribution of data to each client.
- Quality of Service is configurable (delivery guaranteed, connection persistent, etc) with Notification Service.
- Proven technology.
Cons
- More software to buy.
- Need an ORB in the browser.
- Scalability?
JMS: Rendez-vous (Tibco)
The applet connects to an agent on the web server and subscribe to a given topic of interest. It then starts to receive updates from the agent.
The quote server can listen on subscription messages and starts publishing data once the subscription has started.
The quote server simply needs to know the appropriate subject for the updates and simply sends the data once, regardless of the number of clients interested.
The data can be broadcast on the subnet and more than one agent can handle it.
Pros
- Broadcast on server(s) side, scalable to a series of agents.
- Applet and server are totally de-coupled.
Cons
- More software need, Rendezvous is costly. Extra software required in applet.
JMS: MQSeries
The applet connects to a MQ manager sitting on the web server, it subscribe to a given queue with a filter identifying the client. Another option is that a temporary queue could be created.
The applet needs to tell the server which queue to publish to and what data the client is interested in.
The server publishes each update on a queue once.
Pros
- Delivery can be guaranteed, right up to the client.
Cons
- Heavy duty
- More software to buy on client and server.
- MQSeries is mainly point-to-point, pub/sub mechanism is not its main strength.
- Applet to quote server still required in order to establish a subscription.
|
