You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by raulvk <ra...@gmail.com> on 2008/03/26 00:46:21 UTC
ServiceMix & EDA
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?
Thanks a lot for your help! All insights will be appreciated.
Regards,
Raul.
--
View this message in context: http://www.nabble.com/ServiceMix---EDA-tp16291801s12049p16291801.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: ServiceMix & EDA
Posted by Bruce Snyder <br...@gmail.com>.
On Wed, Apr 2, 2008 at 11:15 AM, raulvk <ra...@atosorigin.com> wrote:
>
>
> Hi Bruce,
>
> Yes, that would be excellent. In my opinion, it would give ServiceMix a
> great support for EDAs, without having to use Binding Components to connect
> to a JMS Broker. I come from a TIBCO background and I've used TIBCO
> Rendezvous in previous projects, so I was looking for something similar in
> ServiceMix, sort of like a "meeting point" between publishers and
> subscribers.
>
> The way this used to work was: 1) the publisher published an event/message
> on the ESB, 2) the ESB would apply a mediation flow to: validate the
> message, transform it to a Canonical Data Model and publish it to a topic in
> a "meeting point".
> The parties interested in capturing this event and processing it - for
> example, to update their own databases - would simply subscribe to the topic
> in the "meeting point" and apply the reverse process through another
> mediation flow, finalising with the invocation of the final endpoint.
>
> I am not sure as to whether this is feasible, but perhaps a solution would
> be to create a JMS Service Engine? This way, the "meeting point" between
> publisher and subscribers would stay inside within the JBI domain?
What you're describing is JMS where a JMS destination serves as the
meeting point. But I think your point is that ActiveMQ is technically
not a component plugged into the NMR using the JBI APIs. OTOH, maybe
what you're seeking is the WS-Notification service engine. But like I
said earlier, the WS-Notification implementation is built on top of
JMS.
I don't feel that a JMS service engine is needed because ActiveMQ is
already being run inside the same JVM as ServiceMix. Also, the
Normalized Message Router makes use of ActiveMQ to send/receive
messages to/from JBI components plugged into the NMR.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&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/
Re: ServiceMix & EDA
Posted by raulvk <ra...@atosorigin.com>.
Hi Bruce,
Yes, that would be excellent. In my opinion, it would give ServiceMix a
great support for EDAs, without having to use Binding Components to connect
to a JMS Broker. I come from a TIBCO background and I've used TIBCO
Rendezvous in previous projects, so I was looking for something similar in
ServiceMix, sort of like a "meeting point" between publishers and
subscribers.
The way this used to work was: 1) the publisher published an event/message
on the ESB, 2) the ESB would apply a mediation flow to: validate the
message, transform it to a Canonical Data Model and publish it to a topic in
a "meeting point".
The parties interested in capturing this event and processing it - for
example, to update their own databases - would simply subscribe to the topic
in the "meeting point" and apply the reverse process through another
mediation flow, finalising with the invocation of the final endpoint.
I am not sure as to whether this is feasible, but perhaps a solution would
be to create a JMS Service Engine? This way, the "meeting point" between
publisher and subscribers would stay inside within the JBI domain?
Maybe I am getting it all wrong. Please excuse me if I am...
Thank you very much,
Raul.
bsnyder wrote:
>
> On Wed, Mar 26, 2008 at 5:57 PM, raulvk <ra...@atosorigin.com>
> wrote:
>>
>> Please check out this thread:
>>
>> http://www.nabble.com/Event-driven-component-td5273599s12049.html#a5273599
>>
>> http://www.nabble.com/Event-driven-component-td5273599s12049.html#a5273599
>> .
>>
>> What the poster asked is exactly what I want to achieve, but the post
>> got no
>> answer back then... Could you guys take a look at it and let me know if
>> there is a way to implement the behaviour he describes other than using
>> JMS
>> Binding Components that publish and subscribe to topics nor WSN2005?
>>
>> This would be simple to achieve in Message-Oriented Middleware, but how
>> would we achieve this in ServiceMix?
>
> ServiceMix doesn't currently provide such capability, but we can
> certainly explore the possibility of adding this capability or
> something similar.
>
> So are you simply trying to listen to a given endpoint for any
> messages that endpoint receives?
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&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-tp16291801p16447647.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: ServiceMix & EDA
Posted by Bruce Snyder <br...@gmail.com>.
On Wed, Mar 26, 2008 at 5:57 PM, raulvk <ra...@atosorigin.com> wrote:
>
> Please check out this thread:
> http://www.nabble.com/Event-driven-component-td5273599s12049.html#a5273599
> http://www.nabble.com/Event-driven-component-td5273599s12049.html#a5273599 .
>
> What the poster asked is exactly what I want to achieve, but the post got no
> answer back then... Could you guys take a look at it and let me know if
> there is a way to implement the behaviour he describes other than using JMS
> Binding Components that publish and subscribe to topics nor WSN2005?
>
> This would be simple to achieve in Message-Oriented Middleware, but how
> would we achieve this in ServiceMix?
ServiceMix doesn't currently provide such capability, but we can
certainly explore the possibility of adding this capability or
something similar.
So are you simply trying to listen to a given endpoint for any
messages that endpoint receives?
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&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/
Re: ServiceMix & EDA
Posted by raulvk <ra...@atosorigin.com>.
Please check out this thread:
http://www.nabble.com/Event-driven-component-td5273599s12049.html#a5273599
http://www.nabble.com/Event-driven-component-td5273599s12049.html#a5273599 .
What the poster asked is exactly what I want to achieve, but the post got no
answer back then... Could you guys take a look at it and let me know if
there is a way to implement the behaviour he describes other than using JMS
Binding Components that publish and subscribe to topics and other than
WSN2005?
Thanks!!
raulvk 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?
>
> Thanks a lot for your help! All insights will be appreciated.
>
> Regards,
>
> Raul.
>
--
View this message in context: http://www.nabble.com/ServiceMix---EDA-tp16291801s12049p16319342.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: ServiceMix & EDA
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Mar 27, 2008 at 12:05 AM, Bruce Snyder <br...@gmail.com>
wrote:
> > 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?
>
> No, there is no serialization step because the messages are already in
> an XML format.
>
>
This is not completely exact. For the JMS BC, we usually use text messages,
the text being the xml content as Bruce said. So the whole JBI message is
not serialized. However, when using JMS or JCA flow, the whole JBI
exchange is serialized, so there is a bigger overhead.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: ServiceMix & EDA
Posted by raulvk <ra...@atosorigin.com>.
Bruce, sorry to be such a pain! However, I still don't fully understand when
JMS is used for communication between JBI components. If I've understood
correctly:
* JMS is only used in the JMS and JCA flows (to cluster together
ServiceMix instances)
* JMS is *NOT* used in the other two flows (Straight-through and SEDA),
and these flows
When is the embedded ActiveMQ used, other than in the JMS and JCA flows?
Thanks again!!
bsnyder wrote:
>
> On Wed, Mar 26, 2008 at 4:59 PM, raulvk <ra...@atosorigin.com>
> wrote:
>>
>> 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?
>
> The SEDA flow does not use JMS queuing, it uses a specialized SEDA
> queue. The JMS and JCA flows do use JMS queuing.
>
>> 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?
>
> No, there is no serialization step because the messages are already in
> an XML format.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&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-tp16291801s12049p16318965.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: ServiceMix & EDA
Posted by Bruce Snyder <br...@gmail.com>.
On Wed, Mar 26, 2008 at 4:59 PM, raulvk <ra...@atosorigin.com> wrote:
>
> 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?
The SEDA flow does not use JMS queuing, it uses a specialized SEDA
queue. The JMS and JCA flows do use JMS queuing.
> 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?
No, there is no serialization step because the messages are already in
an XML format.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&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/
Re: ServiceMix & EDA
Posted by raulvk <ra...@atosorigin.com>.
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 <ra...@gmail.com> 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)U8V4\@4VYY9&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.
Re: ServiceMix & EDA
Posted by Bruce Snyder <br...@gmail.com>.
On Tue, Mar 25, 2008 at 7:08 PM, raulvk <ra...@gmail.com> 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)U8V4\@4VYY9&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/
Re: ServiceMix & EDA
Posted by raulvk <ra...@atosorigin.com>.
Yes, I had already come across it. I will do some proofs of concept and let
you guys know how it works out.
Thanks.
bsnyder wrote:
>
> On Wed, Mar 26, 2008 at 4:33 PM, Rick Block <ri...@avaya.com> wrote:
>> Raul,
>> Does http://servicemix.apache.org/servicemix-wsn2005.html help?
>
> The servicemix-wsn2005 component is just a WS-Notification
> implementation on top of JMS.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&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-tp16291801s12049p16318690.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: ServiceMix & EDA
Posted by Guillaume Nodet <gn...@gmail.com>.
Yes, but it sounds to me like it could also solve the problem too. But the
same consideration holds: i.e. it still uses JMS.
On Wed, Mar 26, 2008 at 11:54 PM, Bruce Snyder <br...@gmail.com>
wrote:
> On Wed, Mar 26, 2008 at 4:33 PM, Rick Block <ri...@avaya.com> wrote:
> > Raul,
> > Does http://servicemix.apache.org/servicemix-wsn2005.html help?
>
> The servicemix-wsn2005 component is just a WS-Notification
> implementation on top of JMS.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&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/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: ServiceMix & EDA
Posted by Bruce Snyder <br...@gmail.com>.
On Wed, Mar 26, 2008 at 4:33 PM, Rick Block <ri...@avaya.com> wrote:
> Raul,
> Does http://servicemix.apache.org/servicemix-wsn2005.html help?
The servicemix-wsn2005 component is just a WS-Notification
implementation on top of JMS.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&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/
Re: ServiceMix & EDA
Posted by Rick Block <ri...@avaya.com>.
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 <ra...@gmail.com> 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)U8V4\@4VYY9&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/
>>
>>
>
Re: ServiceMix & EDA
Posted by raulvk <ra...@gmail.com>.
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 <ra...@gmail.com> 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)U8V4\@4VYY9&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-tp16291801s12049p16293376.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: ServiceMix & EDA
Posted by Bruce Snyder <br...@gmail.com>.
On Tue, Mar 25, 2008 at 5:46 PM, raulvk <ra...@gmail.com> 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)U8V4\@4VYY9&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/