JAXM RI asynchronous delivery -- how does it work?

Question

After struggling with using a one-way remote messaging with JAXM provider for several days, I finally got two simple clients working on two machines, one message producer on server1 and the other consumer on server2 (no reply message the other way) -- but only on the condition of both servlets are up. If the producer sends message while the consumer is undeployed or the consumer's container is stopped, the consumer does NOT get the message after it is back on line. But isn't that the whole point of "asynchronousness" which the RI spec says "The application itself may be active or quiescent, but the remote provider continues to try to ... receive any incoming messages on the application's behalf. When an application comes up and establishes a connection to the remote provider, messages received by the provider for that application are delivered to it."?
There are quite some discussions on the confusing topic about configuring the sender and receiver. But I didn't find any discussion on this "asynchronousness" and how it works. any insights would be appreciated. posting my configuration files here.
============================================
Producer side
client.xml:
<Endpoint>
http://Producer
</Endpoint>
<CallbackURL>
http://server1:8080/HelloProducer/Producer
</CallbackURL>
<Provider>
<URI>http://java.sun.com/xml/jaxm/provider</URI>
<URL>http://127.0.0.1:8081/jaxm-provider/sender</URL>
</Provider>
provider.xml
URI: http://Consumer
URL: http://server2:8080/jaxm-provider/receiver/soaprp
============================================
Consumer side:
client.xml
<Endpoint>
http://Consumer
</Endpoint>
<CallbackURL>
http://server2:8080/HelloConsumer/Consumer
</CallbackURL>
<Provider>
<URI>http://java.sun.com/xml/jaxm/provider</URI>
<URL>http://127.0.0.1:8081/jaxm-provider/sender</URL>
</Provider>
provider.xml
No mapping (there is no reply message)
============================================
Bianca

Answer 1

I've only quickly scanned through your post, but one point is that if you stop the web container, then the messaging provider will also stop and will not receive any messages.
Although the documentation mentions being able to retrieve messages from a provider once it re-connects, this would only work if you left the container running and re-deployed the application the message is intended for. I haven't read all of the JAXM specs in detail, but I have found in several instances that the documentation/specs will suggest a specific functionality is available, but then I find it has not been implemented at this time.
Generally, JAXM applications (servlets) tend to initiate a connection to their provider early on, and do not disconnect, so if the JAXM application has an onMessage method, it will receive the SOAP message and process it.
Additionally, if you configure the provider through the GUI tool provided with JWSDP, then you can set how many times the message should be re-sent by a provider (and some other properties).
Finally, the definition of asynchronicity should not be confused with the ability discussed above of providers to deliver messages to an application which has been offline. Synchronous messaging is basically the same as a regular function call. For example,
double ReturnDouble (){
return 4.35;
If this method is called by a class, then it will wait for a double to be returned and the calling class is said to be 'blocked'. Only when the function returns a response to the calling class is the method unblocked and the program execution continues. Similarly with synchronous JAXM (SAAJ) messaging (without providers), the method in a listening servlet is:
SOAPMessage onMessage(SOAPMessage message){
// Create SOAP
return soapMessage;
This method returns a SOAPMessage object to the client, and this client is blocked until it receives this SOAPMessage as a reply.
With asynchronous messaging, the listening servlet does not return a response to an incoming message (and the sending servlet does not expect one), so the sending application (a JAXM servlet) can send a SOAP message to the listening servlet, and then execute the rest of its code without waiting for a response.
(Although the onMessage method in asynchronous messaging using providers has a return type of void, using a return type of void in JAX-RPC messaging does NOT imply an asynchronous method call :) )
Hope that is clear - I haven't had coffee yet ;)
Simon