>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.
Matching the best technology to the job at hand should be science, but taking
broad brush strokes make it more like art. (I'm really thinking it makes it more like
something else, but I'll be nice). One thing you can do is point out the places
synchronous transports are already in place. FTP, ODBC, HTTP, SDLC, TELNET, etc. You
might even point out that MQ channels are inherently synchronous. Between you and me,
the statement "ALL communications should be asynchronous" is a (typical management)
over-simplification.
On the otherhand, I do respect the desire to limit the diversity of
technologies that your orgainization must understand and support. So it really becomes
a case of which is better: to take on a different technology that's better suited to
the job or to "stretch" an existing technology. That can only be answered on a
case-by-case basis. I think it makes good sense to standardize on fewer, rather than
more messaging products, but you don't want the stretch to snap any tendons.
In the case of MQ, I'd suggest there are some limitations for synchronous
applications. One is the performance disadvantage, which really only surfaces at
fairly high volumes. Two is distributed transaction support. Another is dependency on
real time. Except where you have definitive requirements like these that justify
otherwise, I side with the argument to "go with what you know".
regards,
Dennis
> -----Original Message-----
> From: Jeff A Tressler [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, January 10, 2003 1:04 PM
> To: [EMAIL PROTECTED]
> Subject: Using MQSeries for ALL Synchronous Traffic
>
> 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
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
