cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Schneider Christian <Christian.Schnei...@enbw.com>
Subject AW: Using CXF asynchronously
Date Wed, 10 Nov 2010 16:35:35 GMT
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:dkulp@apache.org] 
Gesendet: Mittwoch, 10. November 2010 16:56
An: users@cxf.apache.org
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 <dkulp@apache.org>
> To: users@cxf.apache.org
> Cc: Steve Cohen <scohen@javactivity.org>
> 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
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message