If I understand you right you would recommend using JMSFlow to connect
the departments.
While I think JMSFlow will work inside one organisational unit I would
not like to use it to connect separate service buses.
One problem I see is that currently JMSFlow uses a proprietary way to
exchange data. So the other department can only also use servicemix in
the future.
Even when the servicemix versions differ you can run into severe problems.
The other problem is that it is difficult to enforce security in JMSFlow
as it only uses one queue for all services. I would recommend using a
separate queue for each service. So the security settings can be done in
the JMS Server config.
While you can counter the above problems by using a JMS BC for each
service it is quite a lot of handwritten config.
So I would recommend writing a new JMSFlow that works in a standardized
way.
http://incubator.apache.org/servicemix/jmsflow-with-soap-over-jms.html
What do you thing Bruce?
Best regards
Christian
Bruce Snyder schrieb:
On 6/13/07, bluedog <[EMAIL PROTECTED]> wrote:
I am interested in different methods for linking two ServiceMix
buses. The
use case is the customer department has its own set of service
interfaces
and at some point, needs to pass along messages to the finance
department.
Each department has its own bus.
I recommend networking multiple instances of ServiceMix using ActiveMQ
via its network of brokers concept
(http://activemq.apache.org/networks-of-brokers.html). This is how I
always recommend networking distributed instances of ServiceMix
because it provides a logical normalized message router (NMR) between
all distributed instances of ServiceMix. This means that the NMR has
knowledge of all components installed in all instances of ServiceMix,
no matter whether they're local or remote. Then you're just deferring
message routing to the NMR - this is its purpose.
...
The reason I'm making these recommendations is to stick with message
routing completely through ServiceMix instead of picking and choosing
how things work. I've found that it's much easier for my customers to
remain consistent than it is to create custom use cases for everything
- unless (and this is a big cavaet) there's a very good reason for not
doing so.
Bruce
--
Christian Schneider
---
http://www.liquid-reality.de
