Hi Steve,

CXF has very good support for asynchronous calls. You can define methods as 
@Oneway when doing java first.
As your whole API seems to be oneway I would suggest to only have methods with 
a parameter and no return value. Of course they should also be marked @Oneway 
as above.

You can go the way you described by having a server method to subscribe for 
events. I think an even better way would be to use a jms server and the jms 
transport for this. You can use topics for the events. So each client only has 
to register for the topic on the jms server by pulling up his jaxws:endpoint 
with the jms transport. The server then simply sends to the respective 
endpoints via a jaxws:client.

We are using such async interfaces in production and they work very well.

In any case you should also take a look at Apache Camel as an alternative. They 
have very nice support for jms and in your case you could even think about 
sending serialized java objects or jaxb serialized objects instead of soap 
calls.

In that case you can simply do the following:

interface Notifier{
        sendSync(SyncEvent event);
}

class Sender {
        @Produce(uri = "jms:myTopic")
        Notifier notifier;

        public doNotify() {
                notfier.sendSync(new SyncEvent(...));
        }
}

class Receiver {
        @Consume(uri = "jms:myTopic")
        public onSync(SyncEvent event) {
                <do something with it>
        }
}

There is really not much more to it... The only thing is that SyncEvent has to 
be serializeable and of course you need to have some config for the jms 
endpoint "jms:".

You can find more about this here:
http://camel.apache.org/pojo-messaging-example.html
http://camel.apache.org/pojo-producing.html
http://camel.apache.org/jms.html

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: Steve Cohen [mailto:[email protected]] 
Gesendet: Dienstag, 9. November 2010 18:12
An: [email protected]
Betreff: Using CXF asynchronously

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?

Reply via email to