Hello Bruce, thanks for your response.
bsnyder wrote:
I have always recommended the use of the Spring Framework for building
Java apps. It's diminishes the complexity of the application and provides
many well-tested, widely used convenience classes. In fact, ActiveMQ
itself is built on
Bruce, thanks again for your answers.
bsnyder wrote:
geronimo-j2ee-management_1.0_spec-1.0.jar
geronimo-jms_1.1_spec-1.1.1.jar
geronimo-jta_1.0.1B_spec-1.0.1.jar
Those JARs are just APIs for a given specification. In other words, those
JARs contain the interfaces put forth by each of
bsnyder wrote:
Request/reply is a versatile style of messaging, but there are no
guarantees about the timeliness of the reply. This is where a
multi-phased approach would work best when using JMS with HTTP similar to
[the workflow approach] you describe below.
[snip]
This [workflow
As a JMS newbie, I am trying to get my head around ActiveMQ. It seems to me
that it could be advisable to write ActiveMQ servers and clients using
Spring technology; at least in theory, one could avoid writing lots of
boilerplate code and tying the code to any ActiveMQ vagaries... at least in
If these questions don't make much sense, please bear with me; I am just
getting into JMS.
I am interested in using ActiveMQ to develop pure JMS applications, that
will run without any J2EE container. I believe this is possible, but was
surprised to see the ActiveMQ minimal JARs include:
Let's say I have a pure JMS-based application, that implements business logic
by integrating decoupled components through messaging, with all the
advantages this entails. These applications are triggered by incoming
payloads (say, files that get dropped into specific folders).
I would also like
