Right Tool for the Job
Business transactions can vary widely in their definitions, but they can basically be classified into two types - those where I need an immediate response so I can continue with my work and those where I'm going to tell you what to do and trust that you'll get it done while I move on to something else. These classifications are otherwise known respectively as synchronous and asynchronous transactions.
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):
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.
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.
Comments