When designing an architecture for solving business problems, it's helpful to figure out which type of problem you're solving and then pick an appropriate technology to support it. For example, HTTP might be a good choice for synchronous applications since it is request/reply by nature. JMS might be a better fit for asynchronous solutions since these structures are typically one way.
Blurring the lines is the JCAPS offering of a request/reply mechanism for JMS messaging - called appropriately enough, JMS RequestReply. A colleague called this mechanism "synchronous by asynchronous" and I think that's an appropriate description.
In JCAPS, when a RequestReply queue is used, a dynamic connection (actually a TCP socket) is created for each RequestReply request. When the reply is generated, it is placed on the dynamic queue using the JCAPS Message sendto method.
On the surface this seems pretty cool... now I have 2 ways to skin the synchronous cat.
But what's the cost of creating that dynamic JMS connection?
I've created a simple tester that tests some number of simultaneous clients, each submitting 100 transaction requests. Comparing the JCAPS RequestReply mechanism with HTTP response times. Here's the data (all times are milliseconds):
| JMS RequestReply | HTTP | |
| 1 User | 5 ms | 0 ms |
| 25 Users | 639 ms | 2 ms |
| 50 Users | 4791 ms | 11 ms |
| 75 Users | 20128 ms | 654 ms |
The RequestReply response time degrades much faster than the HTTP response time. Using JMS in this way is not a good fit for these synchronous transactions. It's a square peg in a round hole.
In this instance JMS (or at least JMS RequestReply) does not seem like the right tool for the job. And further, just because a tool might add some functionality that allows you to do something you couldn't do otherwise, it doesn't mean you should.
0 comments:
Post a Comment