On Tue, Mar 25, 2008 at 7:08 PM, raulvk <[EMAIL PROTECTED]> wrote:
>
> Hi Bruce,
>
> Thanks for your prompt reply. I understand the approach you describe and it
> makes perfect sense. However, my concern is that by using the JMS Binding
> Component to capture the transformed message and send it to a topic, I would
> be sending the message out of the ESB (outside the JBI domain). Is this
> right? This would delegate the responsibility to the JMS Broker (probably
> Apache MQ). Is this correct?
ActiveMQ is embedded in ServiceMix and launched from there. ServiceMIx
uses JMS heavily for communication between the NMR and JBI components.
Technically, yes the messages would go through the ActiveMQ broker,
but the broker is running in the same JVM as ServiceMix and uses an
in-VM protocol so that the TCP stack is not used at all for delivery
(unless you're using multiple instances of ServiceMix that are
networked together). So it's extremely common for message flows to use
JMS semantics in this manner.
> My intention is for the message to stay within the JBI domain. When I used
> the term "topic" I was only comparing the behaviour I want to achieve inside
> the bus to what would happen in the JMS world.
Is there something that you're worried about by using ActiveMQ in this
manner? It's really not a problem at all to do so and as I mentioned
is actually a very common practice.
> Basically, as far as I know, once the transformation is done within the
> saxon component, the latter will call a destination JBI service (similar to
> a chain of invocations). Instead, what I want to do is publish the event
> inside the ESB somewhere where it can be captured by other components that
> have declared interest in receiving the event (ideally, they would be
> "listening" for it).
Use of JBI takes place by configuring a JBI component to send messages
it receives to a target service/endpoint. The JBI components send
those messages to the NMR with a service name and an endpoint name of
the target service/endpoint and the NMR takes care of locating the
service/endpoint and delivering the message to that service/endpoint.
So routes are predefined in a sequential manner (i.e., from component
A to component B to component C and so on).
What you have described above is that you'd like to be able to listen
for messages somehow. Most typically this would be fulfilled through
the use of something that can hold the messages such as a message
broker or a database. But messaging via a database is miserably slow
so the most logical choice is a message broker. This is why all ESBs
are message-based. Using JMS semantics actually makes the application
more robust because of the guarantees provided by the JMS spec.
So does this help to clear up some of your questions?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Blog: http://bruceblog.org/
