Analizing technology pairings - Ajax and JMS
I recently read this proposal for Ajax/JMS event queueing and I have to say I initially like the idea of the technology pairing. So how would I evaluate it?
As the author has responded in the TSS blogs, this does not necessarily need to be JMS. The undelying thought is still sound - to combine AJAX communication events to another publisher-subscriber framework where others subscribe. It's a great way to decouple the UI from the middle tier. It actually decouples the middle tier API from the requests.
Would it be performant? That seems to be a chief concern, especially when bundling with JMS. However, I really think it could be, if you set it up correctly. Thoughts that come to mind are having prioritized messages - one for things that need to be snappy, and another for longer running asynchronous requests. I'm sure there are tons of strategies in the JMS community to get the performance that is required.
But why do it? Is there a better way? Where is the "win"?
Pros
Well, any time you introduce an event queue, you tend to get a defacto throttling mechanism built in. Your even queue simply expands if the server falls behind, rather than performance being killed across the board.
Adding an event queue also makes it very flexible to add event consumers, in that you just register other interested parties in the topic. I can see the utility in this too.
If you already have JMS messaging in place - that would certainly leverage existing JMS expertise and codebase, which itself has a very simple and natural API.
Cons
It seems like utilizing AJAX to call web services directly could be just as flexible. This would allow both the UI and third parties to exercise the same API. A limitation to calling web services is the security issue where you can only communicate with your request's originating domain. Therefore, if your services client is external to you, then you need to proxy the service request on your server.
If you don't have JMS in place, then there will certainly be some care and feeding of those components as technology moves forward. And there will be development costs to getting familiar with the framework.
This bumps Ajax in Action to the top of my reading queue.
As the author has responded in the TSS blogs, this does not necessarily need to be JMS. The undelying thought is still sound - to combine AJAX communication events to another publisher-subscriber framework where others subscribe. It's a great way to decouple the UI from the middle tier. It actually decouples the middle tier API from the requests.
Would it be performant? That seems to be a chief concern, especially when bundling with JMS. However, I really think it could be, if you set it up correctly. Thoughts that come to mind are having prioritized messages - one for things that need to be snappy, and another for longer running asynchronous requests. I'm sure there are tons of strategies in the JMS community to get the performance that is required.
But why do it? Is there a better way? Where is the "win"?
Pros
Well, any time you introduce an event queue, you tend to get a defacto throttling mechanism built in. Your even queue simply expands if the server falls behind, rather than performance being killed across the board.
Adding an event queue also makes it very flexible to add event consumers, in that you just register other interested parties in the topic. I can see the utility in this too.
If you already have JMS messaging in place - that would certainly leverage existing JMS expertise and codebase, which itself has a very simple and natural API.
Cons
It seems like utilizing AJAX to call web services directly could be just as flexible. This would allow both the UI and third parties to exercise the same API. A limitation to calling web services is the security issue where you can only communicate with your request's originating domain. Therefore, if your services client is external to you, then you need to proxy the service request on your server.
If you don't have JMS in place, then there will certainly be some care and feeding of those components as technology moves forward. And there will be development costs to getting familiar with the framework.
This bumps Ajax in Action to the top of my reading queue.
posted by DavidVTHokie at 12:09 PM
0 Comments:
Post a Comment
<< Home