MQSeries.net :: View topic - Multiple Sender/Receiver Channels betweem same 2 QMgrs

nimconsult · Posted: Wed Jul 31, 2002 10:28 pm Post subject:

Managing syncpoint frequency is one of the multiple complexities of implementing a MQ-based server application.

I have always recommended to my clients using a generic server implementation instead of letting every application developper re-invent the wheel for each application.

To demonstrate the concept, I have myself written such a generic server. I am still thinking about making it public, or at least distributing a demo version of it. Give me some weeks to prepare that.

The generic server is a framework handling:

* Connect to the appropriate MQ Series queue manager. Handle connection errors and retry in case of problem on the queue manager.
* Open the application queue (input) and application dead-letter queue (output). Handle connection errors and retry in case of problem on the queue.
* Get messages from the application queue. Wait for messages if the queue is empty, according to a specified delay.
* Call the business component to process the message.
* Handle the return code of the business component. Take the appropriate actions: retry or reject the message, syncpoint or rollback the unit of work.
* Reject invalid messages in the application dead-letter queue. Force the server to stop when a maximum number of consecutive rejected messages is reached.
* Retry messages when appropriate. Reject the messages if a maximum number of attempts is reached.
* Manage a syncpoint frequency to process several messages inside a single unit of work, if specified in the XML repository. This is an option to increase the throughput of the application server by decreasing the I/O activity of MQ Series. Intelligent recovery behaviour when an error on one message causes the rollback of a group of valid messages.
* Recognize command messages to start and stop tracing, stop the application server, report statistics.
* Provide exit points to customize the application (on start application, on stop application, on commit, on rollback, on collect statistics, on error)

What does the developper need to do?
* Provide a COM+ or Java component, that responds to a defined interface, implements your business, returns a status or raise an exception to the framework.
* Provide a XML file with parameters: queue manager name, queue names, wait interval value, syncpoint frequency, maximum number of retry messages, maximum number of consecutive rejected messages

Benefits:
* Pre-implemented and pre-tested framework: economy of time
* Tuned performance: benefits to all applications
* Consistent behaviour of production application servers

I have implemented custom implementations of this server in multiple financial institutions, it runs successfully in production and gives entire satisfaction.
_________________
Nicolas MarÃ©chal
Senior Architect - Partner

NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be