Hi Dan, I am interested in the point you made that "if the "client' is behind some sort of NAT based router or similar, that could be very tough to do" I do not follow you on this. By "client" I assume you mean the client component of the original server that will send the sync message. What problem would a NAT router cause in this scenario? It is like an http client accessing an http server via NAT. Right? May be I am rusty on this, but could you please elaborate on what you mean?
Thank you! ________________________________ From: Daniel Kulp <[email protected]> To: [email protected] Cc: Steve Cohen <[email protected]> Sent: Tue, November 9, 2010 10:48:07 PM Subject: Re: Using CXF asynchronously On Tuesday 09 November 2010 3:43:44 pm Steve Cohen wrote: > On 11/09/2010 02:06 PM, Daniel Kulp wrote: > > On Tuesday 09 November 2010 12:11:42 pm Steve Cohen wrote: > >> 4) to handle the synchronization requirement mentioned above, I am > >> envisioning a separate thread in the client that makes an asynchronous > >> "RegisterForSynchMessages()" call to the server. This would be polled > >> continually and would expect REPEATED messages through this channel. > >> That is, the server side handler for this call must continue to run even > >> after it sends a response. It will never complete and must continue to > >> send such responses back through the channel. > >> > >> Is this achievable using CXF's asynchronous support? > > > > Well, is the communication between client/server going though a firewall > > or similar? If not, it might be best to just have the client bring up > > an endpoint on an http port, get the EPR for it, and send that to the > > server as a "registerClient" call or similar. That endpoint would just > > have a couple oneway calls on it that the server would just call when > > needed. It's pretty simple to setup. THere is a "callback" demo in > > the kit that show this. > > Thanks, this is what I needed to know. The main thing is that the > server is able make multiple callbacks to the client, as opposed to just > one. > > But now, what about that firewall? More than likely we'll have to have > one. I don't understand how this impacts the scenario. This system > will not be open to the public, only to a restricted set of clients > which we will have full control over. Because the client has to also act as a "server", the server needs to be able to communicate to the client over a port through the firewall or whatever. For example, if the "client' is behind some sort of NAT based router or similar, that could be very tough to do. If that is the scenario, then the callback method might not work very well. In that case, you may want to investgate using a more polling method in combination of the Jetty continuations on the server side. Doing that works, but is generally a bit more complex. -- Daniel Kulp [email protected] http://dankulp.com/blog
