Re: Sending Events to EJB Clents

[Christopher Steel - Java Design Center McLean VA]

<[EMAIL PROTECTED]> wrote:
>Date: Thu, 6 Apr 2000 01:06:25 -0400 (EDT)
>Greetings
>
>IHAC who is using Persistence PowrTier EJB app server for on-line trading and
>stock updates.  The client is a standalone Java application that essentailly
>logs in and pulls info from the EJB server.  It also must receive stock updates
>from the EJB server that is in turn receving updates from the a legacy data
>source.  The question is, once the EJB beans has recieved updates from the
>legacy data source (via JMS or other App server supported messaging system) what
>mechanism can be used to push the data to a client acrosss the internet.  One
>option under consideration is using JMS Topics to do pub/sub push to the client.
> I believe the JMS Topics are using multicast underneath (the JMS providers are
>I should say) and if this is the case, can multicast span the internet across
>routers that may not support multicast.  If JMS is not an option what other
>methods can be used (other than sockets of course).  I believe Weblogic has a
>proprietary event delivery mechanism as well.   Any h!
>!
>elp will be greatly appreciated.
>
>
>Denys

Denys,
        JMS does not necessarily use multicast underneath, it depends on the service 
provider.
For instance, if you are using JMS on top of MQSeries, updates are done in a regular 
pub/sub fashion without multicast.
In general, multicast does not work over the internet due to firewall restrictions, 
security concerns, and non supporting routers.
For firewall reasons, I would avoid JMS altogether and stick with HTTP.
The example James Wu mentioned will work, but there are issues to consider. In the 
chat example, the client performs an HTTP request and waits indefinetly for a reply.
This forces the server to hold a socket open while the client waits. If the update 
interval is long, you start eating up resources quickly.
For thousands of users, you have to scale horizontally by adding more webservers.

In general polling is a bad word. But in this case it may be the best solution.
Consider that, if your client does an HTTP request and waits for minutes for a 
response, under the covers the socket is being held open with TCP keepalives.
You may end up generating more network traffic that way, then if you were polling.
If the stock quotes are not real time (15 minutes delayed) polling definitely makes 
sense.
If the stock quotes are realtime or near real time, or the updates are frequent, then 
the chat example works best.

-Chris

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".