Not sure if this is the "reccomended strategy", but in your EJB impl class, simply forward all WS message objects to a queue.
Then, define an MDB that listens to that queue, and that handles each WS object in the onMessage() function. That way, your WS messages will be delivered immediatly, but you can do whatever you need to do with the objects at a later point as your MDB handles each queue message.
The only downside here is that you can really only provide your WS caller with a return message that indicates their WS message was received. If you wanted to reply to the original WS message using the "queue in the middle", you'd need to define a separate web-service on their end that accepts "replies" in an asynchronous fashion.
A --> Send WS Msg to B.
B places WS msg onto a queue.
MDB on B processes each message on the queue, then sends a new WS "reply" msg to A, at some point into the future (1 minute, 1 hour, 1 day?).
B --> Send reply to A.
A places "reply" message onto its own queue, and processes it at some later point.
I am aware of that solution
The problem is to get to the EJB processing layer, the XML parsing has to happen which is exactly what I am trying to avoid
The 1K messages I am talking about are very small when it comes to processing, I can say the processing is 35-40% XML parsing and marshalling and 65-60% actual processing
The queue has to happen before the XML processing to be effective