• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

is synchronous messaging suitable for credit card checking

 
Denis Wang
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think, for those transactions demanding instant response, even synchronous messaging is not good enough. Actually synchronous messaging is a very vague statement, which should be replaced as 'synchronous receiver'. I don't know how to implement a asynchronous sender.
any comments?
Best,
Denis
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Neither do I. See my earlier post for the clarification on Credit Card Processing. Synchronous receiver does make sense. Realize that a sender can be a receiver as well on the same administered object or a different administered object (read "channel").
Regards.
Bharat
 
Denis Wang
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
would you please kindly give me your link about Credit Card Process? I cannot find the message with your member #.
I just think it awkward to simulate a synchronous effect through a fundamental asynchronous mechanism.
Best,
Denis
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Dennis,
I am sorry, I can't find it either. It seems like the Credit Card Post got lost, may be my own error. I must have forgotten to upload it?
Anyway, here is the gist of it. There are quite a few situations in Loosely Coupled systems where a synchronous response is required before the requesting program, i.e., calling client, can proceed. I have been involved in a number of architectures where this has happened. Consider the insurance industry for example: we had to design our system to interface with a number of external vendors who provided us with information about a particular request for insurance. One of the vendors used MQ-Series as the connector which was fine with us since we used the WebSphere Application Server and the MQ series software ourselves. The very first question that qualified the requested insurance case for further consideration was whether the person had applied for previous insurance anywhere else which was still under active consideration. If we received an affirmative response then we stopped further automated processing until the matter was manually sorted out by the servicing personnel. This is very similar to credit card processing where you do not want to authorize a purchase until a positive response is received, i.e., it is OK to authorize the purchase. In these situations, the calling client program or the sender itself doubles up as the receiver and these are business critical rules which deem further processing undesirable if the person doesn't pass the business rule. In these circumstances, it is better to send a message and wait for the response synchronously before proceeding further. To prevent the client from waiting forever, generally, some sort of time-out condition is imposed.
Hope this helps.
Bharat
 
Denis Wang
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks for your reply. Basically i got the impression, Messaging system is used as integration tools for legacy/external systems even though the process is a synchronous one.
Obviously JMS is not the only choice for integration tool. Nowadays web services, especially RMI-RPC, can do the work synchronously. However, other considerations/tradeoffs are there, such as existing MQ Queries system.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic