On Tuesday 09 November 2010 12:11:42 pm Steve Cohen wrote: > The company I work for is rearchitecting operator workstations for a > legacy telephony application. > > The legacy workstation still runs on MS-DOS(!) and communicates with a > legacy backend, both client and server written in C. The "interface" > such as it is, is a bunch of C header files. Data is passed by datagram > between client and server and the headers are needed on both sides to > make sense of the data. Since none of the people who developed this 20 > years ago will be around, maintenance is a nightmare. > > Probably because of its origins in a pre-multithreading universe, this > system was developed using primarily asynchronous methods. Client sends > a datagram to server, makes no attempt to wait for a return. Server > periodically sends "synchronization" messages to client (sometimes > triggered by the results of methods invoked by the datagrams from the > client). These synchronization methods are also by datagram. > > Since the server-side is NOT going to be totally rewritten. and must, > after the rewrite, continue to support the old operator workstations as > well as the new ones, the scheme I am thinking of is as follows: > > 1). add an Apache Web Server to the server and a CXF wrapper around the > existing server functionality. > > 2) rewrite the Client as a java swing application that encompasses a CXF > client. > > 3) each operation now initiated from the client will be an asynchronous > Web Service call. These calls would be one-way > > 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. -- Daniel Kulp [email protected] http://dankulp.com/blog
