Another possibility is as I described using jms. As far as I know a jms client can for most providers go through a nat router to the jms server. It only needs a tcp connection to the server. Still it can then receive events asynchronously.
If on the other hand you can only go out with a http proxy then http webservices with polling are probably the only possibility. Best regards Christian Christian Schneider Informationsverarbeitung Business Solutions Handel und Dispatching Tel : +49-(0)721-63-15482 EnBW Systeme Infrastruktur Support GmbH Sitz der Gesellschaft: Karlsruhe Handelsregister: Amtsgericht Mannheim HRB 108550 Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck Geschäftsführer: Jochen Adenau, Hans-Günther Meier -----Ursprüngliche Nachricht----- Von: Daniel Kulp [mailto:[email protected]] Gesendet: Mittwoch, 10. November 2010 16:56 An: [email protected] Betreff: Re: Using CXF asynchronously On Wednesday 10 November 2010 8:05:24 am am am wrote: > 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? When using the "callback" scenario I described, the client really also becomes a server where the server makes a call to the client directly. The client creates an endpoint and spins up an HTTP port to listen on and such. Thus, the server needs to be able to make a normal "http" call to the client. Thus, the NAT traversal becomes an issue. If that's not possible, then you pretty much have to go with a polling method on the client (or a LONG timeout and use continuations on the server). Dan > > 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
