Re: Using MQSeries for ALL Synchronous Traffic
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
Re: Using MQSeries for ALL Synchronous Traffic
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
Re: Using MQSeries for ALL Synchronous Traffic
Another method where value updates are to be made is a thing called the three message protocol. For example a bank account update. Send a non-persistent request for the account balance to the backend system with an expiry interval of 30 seconds and wait. If no reply advise the user to try again later. Otherwise check balance for sufficient funds and send a fire and forget update as a non-expiring persistent message. This gets around a whole series of issues in terms of where did my updated message get to before it expired. Regards Tim A Glen Larson glen.larson@ZURITo: [EMAIL PROTECTED] CHNA.COMcc: Sent by: MQSeriesSubject: Re: Using MQSeries for ALL Synchronous Traffic List MQSERIES@AKH-WIE N.AC.AT 11/01/2003 09:16 Please respond to MQSeries List Jeff, using CICS as the backend application server, A combination of MQRO_COD, MQRO_EXPIRATION, and Expiry options on the Puts, (Request, and Reply), you can build your own Synchonous Business transaction.The first 3 options will tell you if the messages made it to the application code on the other side. From the requester view. 1. COD (confirm on delivery) the message made it to the remote applicaton 2. Expiration the message expired before the remote application was able to process the message 3. No responseEither the sender or receiver channel is down. Back out the message. because the server application will not be able to get a response on the reply and will backout the message From the server view: 1. COD the reply was delivered to the requester, go ahead and complete 2. Expiration the reply message was not delivered to the requester. Back out the request. 3. No response here you have an indoubt situation. Write to an error log, roll-back commit based on you own requirements.Though you could add one more message from the requester to server to complete application sync level 2 processing. There is still a small indoubt window, but that is there no matter what protocal you are using. Glen Larson Zurich North America Jeff A Tressler [EMAIL PROTECTED]@AKH-Wien.AC.AT on 01/10/2003 03:04:05 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: 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 *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
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
Re: Using MQSeries for ALL Synchronous Traffic
Jeff, using CICS as the backend application server, A combination of MQRO_COD, MQRO_EXPIRATION, and Expiry options on the Puts, (Request, and Reply), you can build your own Synchonous Business transaction.The first 3 options will tell you if the messages made it to the application code on the other side. From the requester view. 1. COD (confirm on delivery) the message made it to the remote applicaton 2. Expiration the message expired before the remote application was able to process the message 3. No responseEither the sender or receiver channel is down. Back out the message. because the server application will not be able to get a response on the reply and will backout the message From the server view: 1. COD the reply was delivered to the requester, go ahead and complete 2. Expiration the reply message was not delivered to the requester. Back out the request. 3. No response here you have an indoubt situation. Write to an error log, roll-back commit based on you own requirements.Though you could add one more message from the requester to server to complete application sync level 2 processing. There is still a small indoubt window, but that is there no matter what protocal you are using. Glen Larson Zurich North America Jeff A Tressler [EMAIL PROTECTED]@AKH-Wien.AC.AT on 01/10/2003 03:04:05 PM Please respond to MQSeries List [EMAIL PROTECTED] Sent by:MQSeries List [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: 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 *** PLEASE NOTE *** This E-Mail/telefax message and any documents accompanying this transmission may contain privileged and/or confidential information and is intended solely for the addressee(s) named above. If you are not the intended addressee/recipient, you are hereby notified that any use of, disclosure, copying, distribution, or reliance on the contents of this E-Mail/telefax information is strictly prohibited and may result in legal action against you. Please reply to the sender advising of the error in transmission and immediately delete/destroy the message and any accompanying documents. Thank you. 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
