hey I have a question here --- as far as my idea about this topic goes --- a
server cannot do a callback to a client which is outside the firewall -- the
firewall prevents it --- that is why in RMI u cannot do a server callback a
client when the client is outside firewall --- but when it is inside the
server can definitely call back. This is because of the fact that any
protocol like JRMP/IIOP will be packaged as a HTTP call once the client is
outside the firewall --- and since HTTP is a request/response paradigm no
call back is supported.
Your comments pls.
Anamitra
-----Original Message-----
From: Christopher Steel - Java Design Center McLean VA
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 06, 2000 11:08 AM
To: [EMAIL PROTECTED]
Subject: Re: Sending Events to EJB Clents
<[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".
===========================================================================
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".
