Yes, it does clarify some questions. I actually wasn't aware that ServiceMix
runs along with an embedded ApacheMQ broker inside its JVM.
I am interested in learning more about how this works. Does this mean that
straight-through flow and SEDA flow operate on top of JMS? Can you provide
some references on how exactly this relationship works?
As to the pattern that I am looking to implement, using the JMS BC means
deserialising from and serialising between the JMS and NMR formats, right?
Thanks a lot.
bsnyder wrote:
>
> 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/
>
>
--
View this message in context:
http://www.nabble.com/ServiceMix---EDA-tp16291801s12049p16318492.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
