I'm working on a distributed client-server system that uses TCP. The program's functions is to transfer money to an from the server, but also between the clients, a sort of MobilePay.
When one client wishes to transfer money to another client, that client will need to accept the transfer before it is succeeded (one of the systems requirements).
So, my problem is, I would like the client to get notified (preferably through a message dialog) whenever a transfer is ready to get accepted. All the payments/transfers is stored in a SQL table. I would like the client to get notified when there is a pending payment/transfer in his/hers name, that is, when a new row (with the clients name as receiver) in the transfer table is added, in stead of the client needing to actively see if there is any pending payments (as it is now).
Can anybody help me how to get around this problem?
Best Answer
There's likely a few layers to this solution. I'm assuming of course that the client isn't connected directly to to the database and there's at least one or more application layers in between. Between the client and application server, using a pub/sub protocol like STOMP of AMQP should fit the bill.
Triggering notifications from the database is a bit trickier. Most of the approaches tend to be database specific. If you're using Oracle, you can set up register for data change notifications, and your application and respond to the event. Most likely, you'll need to transform the notification into a meaningful business event before sending that notification to the client.
A slightly less sexy version would be to create an event log table that tacks the changes to the payment/transfer tables. Then create a small process to poll this table and fire events when new data is found and then create a message that is published over your pub/sub layer. Not as sexy as something like Oracle's DCN, but it works.