First, Although message do not get lost if you do things correctly. As with
anything. If something can go wrong it WILL!!. Messages do go astray. That
is why there is a dead letter queue.
BUT...Look at the situation.
Customer does an inquiry
Customer update on thescreen what he THINKs is hi data.
Before he hits enter someone else updates his data.
Customer hits enter and the DB gets updated based on what CUST 1 thinks his
data WAS.
Customer 1 & 2 both get confirmation updates.
Granted there are ways of programming around this but it is one of many
things that need to be considered when trying to put the square sync peg in
the round async hole.
bobbee
From: Jeff A Tressler <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Using MQSeries for ALL Synchronous Traffic
Date: Fri, 10 Jan 2003 16:04:05 -0500
Someone has had a wonderful idea. Since MQSeries is fast and reliable, it
should be used for all data traffic. This includes all data transfer that
is
synchronous in nature.
For example, creation of a web front end for out legacy mainframe
applications.
The user enters the data on a web page, the data is formatted into a
message,
sent to the mainframe via MQSeries, the messages is processed and a reply
is sent back through MQSeries, a results web page is created and sent to
the
user.
We have this design implemented in a limited manor and it works. The
design is not bad since it is only being used by a couple dozen people
and the messages sent to the mainframe are actually fire-and-forget
transactions. The reply is along the lines of "message received." If
the message does not get back in 15 seconds we send a "check the
status later" screen.
Now the powers that be want to use this type of asynchronous facility for
all communications. Even if the user MUST get a valid reply on the status
of the request and MUST get this in a timely manner.
Does anyone know of any white papers that may discuss the problems of
using an asynchronous transport mechanism to solve a synchronous task. We
are looking for technical as will as business reason to strengthen our
argument against this direction.
Jeff Tressler
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
