I work on real-time SOA-style applications (read loosely coupled components connected via some messaging protocol - JMS, MQ or HTTP).
The architect who developed this system decided to use JMS to connect the components. This system is real-time, so there is no need to queue messages if one component fails (the transaction simply disconnects). In addition, there is no need for guaranteed delivery or rollback.
In this case, is there any benefit from using JMS over something like an HTTP web service (speed, resource, etc.)?
One thing that I think of is that, since the JMS approach requires us to set the size of the thread pool (the number of components listening on the JMS topic / queue), will the HTTP service be better suited, as this additional configuration is not required (for each HTTP request, a new stream is created that makes the application scalable to an "unlimited" number of requests until there are no resources on the server).
Did I miss something?
source
share