Or perhaps, as mentioned earlier in this thread, having an applet to which the server could "push" information should do the trick.
I would disagree on your conclusion that pull is *the* way to achieve your 'push alert' on http. Some points on which you will base your decision maybe as follows: 1. How frequent do I expect to get alerts? Some thought on the probability distribution of these alerts may be useful while architecting the right mechanism. For example, if I know that every 10 seconds I would 'more_or_less' expect one update that needs to be 'pushed', then I would go with the AJAX model and let the client "pull" every 10 seconds. However, if there is no certainity of the frequency of change events that need to be pushed and if long 'silence' periods are expected (which may or may not be interspersed with bursty updates) then I would go the applet way and let the server "push" when the event needs to be notified. This saves me the "poll traffic" on the network. Imagine polling every 10 seconds, when the change occured only after an hour! You may ask, then I poll every one hour... but if the distribution is really random, then polling after one hour may not save you! What if my first event is after 1 hr, the second after 1 hr 3 seconds, next at 1 hr 12 seconds and the next one after 3 hours! Exagerated time intervals.. but exageration done on purpose to show you how polling every 10 seconds may increase unnecessary network traffic! Mind you, each call may potentially open up a new socket even though the data flowing on it may not be very high. So choose wisely between the AJAX 'pull' model vs. the Applet (or someother client control) 'push' model :-) You will need to analyze the domain a bit and understand the distribution over time for the events to be able to come up with a good architecture! :-) The other important question you need to ask is "are all the changes important or can I miss out to send some changes to the client?" If the answer is that you can miss out, then AJAX is ok. Imagine you poll every 10 seconds, but 3 events happen in those 10 seconds, you would be able to push out only the latest change (unless the server maintains the list of all changes). In case of push, you may not loose any event. Hope this helps you in your decision.:-) ~Raghu~ On 1/4/06, souravm <[EMAIL PROTECTED]> wrote: > > > Thanks Frank/Michael/Rick for your inputs. > > I'm in synch with your arguments and thought points. > > Simulating server side push by using polling solution with right > interval should be the solution having the best trade off in terms of > scalability, and interoperability. > > Regards, > Sourav > > -----Original Message----- > From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 04, 2006 1:53 AM > To: Struts Users Mailing List > Cc: Struts Users Mailing List > Subject: Re: Web Push Technology > > Indeed, Rick is correct, this is not really technically feasible given > the > basic nature of HTTP. Any solution would have to be of pull nature, > unless you get into applets of ActiveX or such things. You essentially > need to have a server running on the client... then the "real" server > could, theoretically, get the IP of the client and "push" requests out > to > it. But, with nothing to receive it, which is the basic nature of HTTP, > your sunk. > > You can of course do a timed pull type thing, which is pretty typical. > For this, AJAX is pretty ideal, assuming you are OK with requiring > scripting. If you go that route, I suggest look at AjaxTags in Java Web > Parts: > > http://javawebparts.sourceforge.net > > Take a look at the Javadocs for the taglib package... I recently added a > <ajax:timer> tag that allows you to set up timed AJAX events that will > fire at a defined interval while still allowing you to use all the > handlers AjaxTags comes with. With this you should be able to do what > you > want with very little effort on your part (aside from what happens on > the > server of course, which AjaxTags says nothing about). > > Whether you use this or not, your talking about a polling solution most > likely. But, if the polling interval is fast enough (but not too fast > lest you crush your server!), it should work pretty well. Usually, > alerts > can tolerate some degree of delay, so if you set the interval to 10 > seconds or some such, it should be OK. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > AIM: fzammetti > Yahoo: fzammetti > MSN: [EMAIL PROTECTED] > > On Tue, January 3, 2006 2:41 pm, Rick Reumann said: > > souravm wrote the following on 1/2/2006 11:34 PM: > > > >> The push will need to be initiated by an alert server or streaming > >> engine, which will keep pushing data (alerts) to the users's > browsers. > > > > I don't believe that is possible unless you create some kind of > Applet, > > but then you aren't really using the browser. > > > >> 2. What are the relevant technologies avaialble in Java/J2EE for this > - > >> a) How AJAX an be used ? > > > > I'd use the buzz word Ajax for that. I only know the very basics of it > > thanks to Frank's info here: > > > > http://www.omnytex.com/articles/xhrstruts/ (download the sample webapp > > at the end of the article and you should be all set with the basics). > > > > > > -- > > Rick > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely for the use of the addressee(s). If you are not the intended > recipient, please notify the sender by e-mail and delete the original > message. Further, you are not to copy, disclose, or distribute this e-mail > or its contents to any other person and any such actions are unlawful. This > e-mail may contain viruses. Infosys has taken every reasonable precaution to > minimize this risk, but is not liable for any damage you may sustain as a > result of any virus in this e-mail. You should carry out your own virus > checks before opening the e-mail or attachment. Infosys reserves the right > to monitor and review the content of all messages sent to or from this > e-mail address. Messages sent to or from this e-mail address may be stored > on the Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
