response_msg(*args)
send_msg(@res_session, @res, *args)
end
The only difference here has got to do with the transaction ID. In this kind of communication,
it is important for receivers not to handle messages from themselves. That??™s why you use
the $CURRENT_LIBRARY_ID global, which contains the unique library identifier. Each Rails
instance must have its own value in that global. In that way, the TransactionID can be unique
among instances, and different instances can also recognize messages from themselves. The
reason you don??™t have the same code in response_msg is that the ID you send when doing a
response already has the library ID information baked into it; you want to return this message
to the library it originated from.
There are obviously other ways of doing this too, but in this way many libraries can take
part of information if they want, and the structure can be cleanly multicast in all directions.
The handle_response method is simple and reminiscent of the way you handled
responses from the legacy system:
Responses = {}
def self.handle_response(msg)
tid = msg.getIntProperty("TransID")
(Responses[tid % 10_000] ||= []) <<
msg.getText if tid/10_000 == $CURRENT_LIBRARY_ID
end
You need to unwrap the transaction ID from the library ID, and also make sure that you
only handle responses that are meant for you to handle.
The way you handle requests will include some model classes from the Rails application
you??™ll build in the next chapter.
Pages:
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373