servicemix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <>
Subject Re: Components in Different Threads?
Date Mon, 13 Mar 2006 17:11:22 GMT
ServiceMix lightweight components may implement the
  org.apache.servicemix.MessageExchangeListener interface.
In such cases, JBI message exchanges will be pushed to the component
using this interface, instead of having the component polling the delivery
channel.  This is an optional ServiceMix specific extension to JBI.

In other cases, the component will have to poll the delivery channel, and
therefore threads will not be shared.

Guillaume Nodet

On 3/13/06, Corey Baswell <> wrote:
> Hi,
> I'm new to JBI and ServiceMix and have a question about how components
> interact with each together. In the overview section of the JBI spec the
> following statement is made (page 6)
> Components do not interact with each other directly. Instead, as shown in
> Figure 2, JBI functions as an intermediary to route messages from
> component
> to component. This separation of the participants in an exchange is key to
> decoupling service providers from consumers, which is highly desirable in
> service-oriented architectures generally, and in integration solutions in
> particular. This preserves flexibility, since consumer and provider are
> minimally intertwined, and provides a key point for message processing and
> monitoring in JBI implementations. Note also that this processing is
> inherently asynchronous; provider and consumer never share a thread. This
> also helps keep components decoupled.
> So does this means that JBI components should not share threads? The
> reason
> I ask is that while debugging the HTTP example (in Tomcat) it appears that
> the HttpInOutBinding component and HelloWorldComponent share the same
> thread
> and I expected that they would not. Am I reading the spec incorrectly or
> is
> there a way in the configuration to specify that components run in
> separate
> threads?
> Thanks,
> Corey

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message