Assignment related question - JMS interface and response time

[Katrin Perry]

Hi,

My application should take advantage of Java Message Service interface in order to retrieve some type of data. The service provider has committed to 1 sec. response time.
I am trying to interpret the above.
S
Do you think the above information suggests that there is a provider queue that we send a request to and it takes 1 sec. for a response to be posted back to my JMS client. Or could one interpret it as meaning that my application has subscribed to a topic and it takes 1 sec from the time the data has been posted to the topic (by the provider) to to the time when the data reaches my application JMS client.


Your views are appreciated.
Regards

[Katrin Perry]

Please could you let me know if my question is not clear and I would try to clarify?
I would appreciate your opinions on my question

[Amritendu De]

I am not sure I understand the requirement completely. But based on the information provided I see the scenario as a synchronous JMS point-to-point architecture. You need an input queue where the message will be posted and will have a unique identifier. Next the application will listen to an output queue which will look for the message with the request unique identifier. If the wait crosses 1 sec, an error will be shown.

[Katrin Perry]

Hi Amritendu,

Thanks for your reply. The interpretation you propose would be one way to interpret the requirements.

As you know the requirements in the Assignment are vague. Mine states: (I made small alterations to the original text)
The SUD will take advantage of the Java Message Service (JMS) interface to "Pricing" to retrieve the current price for any asset. "Pricing" has committed to a 1 second response time.

does this suggest "synchronous JMS point-to-point architecture"? or could it be interpreted as topic that SUD could subscribe to in order to receive price updates, that could then be stored in the DB, cached... so that the SUD always has the current price?

[Amritendu De]

I think the requirements are talking about JMS and response time so you can go for point-to-point JMS synchronous. If you were to go with asynchronous you could have gone with MDB which will update the DB and cache. But then the response time would not have mattered.

[Katrin Perry]

Thanks Amritendu.

I think I would need to use the JMS queue that provides me with prices in both synchronous and asynchronous manner.

If I just need to pick up a price for the purpose of displaying to the user yes synchronous would be the way, as you suggest. (1 sec response time is OK)
But I would also need to monitor prices and act if the price has reached a certain level. In this case I am planning to send requests for prices every say 10 sec and use MDB to process the response (if not the right price discard, otherwise act on it)

[guru prasanth]

Hi,
Even if you implement the synchronous messaging with caching mechanism there is no guarantee that the processing can happen within a second becuase the messaging server depends on vendor implementation.
So you can put that in the risk items and mention that a POC is required to find the exact vendor to mitogate the risk.

[Katrin Perry]

Thanks for making a valuable point Guru. I suppose this and other external systems the SUD relies on are a major risk.
How would one mitigate such risk?
- if I need to rely on a external JMS interface to get prices and it is down... I can't think of anything else but persist all request to buy and sell (price needs to checked first) and attempt to fulfill them once pricing is up and running again.
Similarly if the we need to rely on External Web Services to execute the requests to buy and sell. This would be a major risk. Any hints on how to mitigate? Again persist and attempt to fulfill later perhaps?

Regards

[guru prasanth]

Hi,
If you are depending on an external system then it should be put under assumption.You should be making assumption that external system will be available 24/7 and will respond back with a time frame say 0.5 sec.If the system is down and when it comes back how fast can you respond back also would matter.