JMS Acknowledge Message // Best practice?

One Star

JMS Acknowledge Message // Best practice?

Hi everyone,
since I am relatively new to JMS and message oriented applications (worked more with SOAP so far), I'd like to ask you for your "best practice" advice on now to handle application acknowledge messages with TESB using JMS?
Here is what I think I would like to do:

System A sends Request message to System B
System B verifies the message and persists it
If something goes wrong here, System B sends a "dude, that one went wrong" message to System A, or an "Acknowledge"-Message if things went OK
System B now processes the message (which can take several hours or even days)
System B sends the response to System A

Is this scenario (especially step 3) common in JMS scenarios?
Would such ACK/NACK-Message be sent by means of a special Queue? Or would one use the regular OUT queue?
Are there standard message definitions for this type of ACK/NACK messages? Or would I have to invent them using XSD?
Thanks
Matt
Employee

Re: JMS Acknowledge Message // Best practice?

Matt,
these kind of interaction patterns are indeed commonly implemented using JMS. The kind of acknowledgements that you are talking about here are application level acknowledgments. And yes, you need to design them as part of your interaction / API design. They payloads can be modeled in XSDs if you have an XML payload. You may even use WSDLs to model your interactions but map it to JMS instead of HTTP as a transport. So to use your language: yes you have to "invent" them the same way you "invent" them in SOAP designing your input, your outputs, and your faults.
NOTE: don't confuse your acknowledge message with JMS acknowledgments. You cannot leave a JMS acknowledgement outstanding for weeks. The messaging broker will eventually abort the communication with the ESB / client.
Thomas
Thomas Steinborn
VP Product Management
One Star

Re: JMS Acknowledge Message // Best practice?

THanks for your quick reply. 
Step 3 (sending the ACK/NACK) was not supposed to be taking longer than 1 second.
Just the processing (step 4) might take hours or even weeks.
But the acknowledge would be sent immediately after the application had simply successfully ingested the message.
Could THAT be done with a "client acknowledge" pattern? Like: sending the acknowledge in the "good case" but sending a custom-designed "business error" message in the error case?
Employee

Re: JMS Acknowledge Message // Best practice?

Seconds is fine for JMS level acknowledgments in typical integration scenarios.
I still would not want to mix transport level acks with business acks. This creates confusion and makes the system brittle to maintain. Think separation of concern.
You should only use the JMS ack to confirm that you could technically consume the message and that there was no technical problem in system B (e.g. disk full, db full, whatever). Compare that with an HTTP error code 501. If you don't send the JMS ack then the message gets put back into the queue and the next client receiving from that queue gets the message. This next client might be the very same that did not acknowledge in the first place. This behavior is okay and good for retries. It also serves as a mechanism of back pressure.
Now there might still be problems with the message you just received. Most simply thing might be that it does not contain XML say, just text. That is not a transport (aka JMS) problem. Rather this is an application level problem. Such errors should be responded with application level messages. In JMS you typically use the JMS_ReplyTo property as address to send such responses to.
HTH
Thomas
Thomas Steinborn
VP Product Management
One Star

Re: JMS Acknowledge Message // Best practice?

Yes, Thomas, that helps a lot. And it makes a lot of sense to me, too :-)
So thank you very much. The way you described it made it sound like it is some kind of "best practice" or established pattern to handle these things?
If so: are there commonly used formats for the business acks?
And: if there is a technical JMS Ack, is there also a technical JMS Nack?
Thanks
Matt