Raul,
Does http://servicemix.apache.org/servicemix-wsn2005.html help?
-Rick Block
raulvk 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?
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.
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).
Don't know if I have explained myself properly. If you need any further
clarification, please don't hesitate to ask.
Thanks a lot,
Raul.
bsnyder wrote:
On Tue, Mar 25, 2008 at 5:46 PM, raulvk <[EMAIL PROTECTED]> wrote:
Hi everyone,
I have a question related to the implementation of EDA messaging
strategies
in ServiceMix. How would you implement the following pattern in
ServiceMix?
1) Some action happens within an application such that it needs to
notify
the ESB so that other systems are updated accordingly, so it casts an
event
onto the ESB.
2) The ESB transforms the data from the applications particular data
model
into a canonical data model and publishes the message in this common
data
format to a certain "topic" (I come from a TIBCO background, so we call
this
a "subject" in Rendezvous terms).
3) All applications interested in snatching this event subscribe to the
topic they know beforehand.
4) The ESB transforms the message from the canonical data model to the
destination's particular model and invokes the appropriate endpoint on
the
target application.
This means that there is no service choreography (one service doesn't
invoke
another one), nor there is service orchestration (as we do not know
beforehand what services should be invoked).
How would you best implement this EDA behaviour in ServiceMix? What
components would you use to: 1) do the transformation
(servicemix-saxon?),
2) publish the message to the ESB on an agreed topic, 3) subscribe to
the
agreed topic, 4) do the reverse transformation?
1) Yes, I'd suggest using the servicemix-saxon component for the
transformation if the data is already XML
2) If the message needs to be published to a JMS destination, then I'd
just publish it using a JMS client. If the use of JMS is not possible,
you can use one of the other binding components to accept the message
using a supported protocol and pushing to a JMS destination.
3) The servicemix-jms component can subscribe to a queue or topic to
consume messages and those can be delivered using any of the supported
binding components.
4) Same as #1 above
Based on what you described above, it sounds like there are two
component flows here. The first flow will just push the messages to a
JMS destination to pile up until there's a request for them. The
second flow will accept a request for a message, consume a message
from the JMS destination and transform it appropriately for the
requestor. Does this make sense?
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/
