You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Steve Kondik <sh...@chemlab.org> on 2007/08/15 15:42:15 UTC
camel + inout mep
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It seems like the servicemix-camel component can only send InOnly MEP..
I need to be able to go thru a sequence of transformers which needs an
InOut.
I don't know enough about Camel yet to implement this, but I think that
if the endpoint isn't the last in the routing chain (or using a
pipeline()), it should send an InOut?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGwwK3MrBfzfMVwMcRApbnAJ9sNySH2NqTjPXapNnsjB097850ZACdEJny
hqR3ZV3gss9c4hefgIO4uoQ=
=ri2B
-----END PGP SIGNATURE-----
Re: camel + inout mep
Posted by James Strachan <ja...@gmail.com>.
On 8/17/07, Steve Kondik <sh...@chemlab.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> James Strachan wrote:
> > On 8/17/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >> I'm not sure how to implement it either :-(
> >> Camel does not really have a notion of InOut.
> >
> > Well, it kinda does - a message Exchange can be in-only, in-out or
> > out-only from the API perspective. i.e. any Camel message Exchange can
> > have an in message, or an in and out.
> >
> > The main difference is there's not an expicit 'createInOnly() v
> > createInOut()) method. The idea being that the MEP could be configured
> > on the endpoint/component as internal metadata or could be a header on
> > the exchange etc. i.e. rather than making the API really different;
> > each processor/component can be kinda polymorphic.
> >
> > Am sure we might need to extend the routing DSL though to deal with
> > InOnly v InOut components in a cleaner way. Right now Camel tries its
> > best to do the right thing. e.g. if you go
> >
> > in -> A -> B -> C
> >
> > then if A is InOnly and it mutates the IN message, its passed to B; if
> > B generates an OUT, then the OUT is passed as the IN to C etc. The
> > idea was to try simplify the component developers perspective of
> > working on the bus; so the routing DSL could try do the right thing;
> > then leave it to the endpoints to figure out how to map the different
> > MEPs to their technologies. e.g. an endpoint could map an InOut to 2
> > different InOnly message exchanges etc.
> >
> >
> >> Are you talking about the jbi -> camel side, or the
> >> camel -> jbi side ?
> >
> > I think the main issue is that right now when a camel message exchange
> > is being dispatched into JBI, its currently no clear way of knowing
> > what kind of JBI exchange type to create. We could fix this by having
> > some kinda property on the Camel Exchange to tell the servicemix-camel
> > what kind of JBI MessageExchange is required. (We could then configure
> > this on a per exchange instance basis, or default it from some
> > configuration on the component or endpoint etc).
> >
> > e.g. take a look at the JbiBinding.createJbiMessageExchange() method.
> >
> > I've just patched this method so that a message exchange pattern
> > property can be specified on a Camel Exchange which will be used to
> > create the right JBI MessageExchange type; if its not specified on the
> > Exchange then its defaulted from the JbiBinding object.
> >
> > Thoughts?
> >
>
> The most important thing would be for a components like pipeline and
> filter to handle this gracefully.
Agreed...
> I think most of the Camel EIPs could
> make a smart decision here. I think most of us using Camel with
> ServiceMix will be using it exclusively for routing- Camel is a breeze
> compared to chaining a dozen SM-EIP endpoints together :)
Agreed and thanks!
Incidentally I've just committed another minor change that should help
even further.
Basically if the Camel exchange has an IN and an OUT message (with a
non-null body in the OUT) then it assumes InOut by default; otherwise
its an InOnly. So you can customize exactly on the JBI component,
endpoint or on the camel Exchange the precise MEP to use - or it
should do the right thing by default if you don't specify anything.
--
James
-------
http://macstrac.blogspot.com/
Re: camel + inout mep
Posted by James Strachan <ja...@gmail.com>.
On 8/17/07, Guillaume Nodet <gn...@gmail.com> wrote:
> Agreed.
>
> We just need to bring camel to the level of functionality of
> servicemix-eip (handling transactions, asynchronous, synchronous, all
> meps that makes sense, etc...)
Agreed. I'm hoping we can unify for of the servicemix-eip and
lwcomponent stuff with camel...
> This will take some time and help is always welcome :-)
Its on my (rather long) list of things to help on :)
--
James
-------
http://macstrac.blogspot.com/
Re: camel + inout mep
Posted by Guillaume Nodet <gn...@gmail.com>.
Agreed.
We just need to bring camel to the level of functionality of
servicemix-eip (handling transactions, asynchronous, synchronous, all
meps that makes sense, etc...)
This will take some time and help is always welcome :-)
On 8/17/07, Steve Kondik <sh...@chemlab.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> James Strachan wrote:
> > On 8/17/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >> I'm not sure how to implement it either :-(
> >> Camel does not really have a notion of InOut.
> >
> > Well, it kinda does - a message Exchange can be in-only, in-out or
> > out-only from the API perspective. i.e. any Camel message Exchange can
> > have an in message, or an in and out.
> >
> > The main difference is there's not an expicit 'createInOnly() v
> > createInOut()) method. The idea being that the MEP could be configured
> > on the endpoint/component as internal metadata or could be a header on
> > the exchange etc. i.e. rather than making the API really different;
> > each processor/component can be kinda polymorphic.
> >
> > Am sure we might need to extend the routing DSL though to deal with
> > InOnly v InOut components in a cleaner way. Right now Camel tries its
> > best to do the right thing. e.g. if you go
> >
> > in -> A -> B -> C
> >
> > then if A is InOnly and it mutates the IN message, its passed to B; if
> > B generates an OUT, then the OUT is passed as the IN to C etc. The
> > idea was to try simplify the component developers perspective of
> > working on the bus; so the routing DSL could try do the right thing;
> > then leave it to the endpoints to figure out how to map the different
> > MEPs to their technologies. e.g. an endpoint could map an InOut to 2
> > different InOnly message exchanges etc.
> >
> >
> >> Are you talking about the jbi -> camel side, or the
> >> camel -> jbi side ?
> >
> > I think the main issue is that right now when a camel message exchange
> > is being dispatched into JBI, its currently no clear way of knowing
> > what kind of JBI exchange type to create. We could fix this by having
> > some kinda property on the Camel Exchange to tell the servicemix-camel
> > what kind of JBI MessageExchange is required. (We could then configure
> > this on a per exchange instance basis, or default it from some
> > configuration on the component or endpoint etc).
> >
> > e.g. take a look at the JbiBinding.createJbiMessageExchange() method.
> >
> > I've just patched this method so that a message exchange pattern
> > property can be specified on a Camel Exchange which will be used to
> > create the right JBI MessageExchange type; if its not specified on the
> > Exchange then its defaulted from the JbiBinding object.
> >
> > Thoughts?
> >
>
> The most important thing would be for a components like pipeline and
> filter to handle this gracefully. I think most of the Camel EIPs could
> make a smart decision here. I think most of us using Camel with
> ServiceMix will be using it exclusively for routing- Camel is a breeze
> compared to chaining a dozen SM-EIP endpoints together :)
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGxaDgMrBfzfMVwMcRAmJcAKCXW/8bakToqOyp9s8jk4GCP8/R1gCfXAYI
> tUaf5MZDX0m92WzsSwZ67Dk=
> =MAVh
> -----END PGP SIGNATURE-----
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: camel + inout mep
Posted by Steve Kondik <sh...@chemlab.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James Strachan wrote:
> On 8/17/07, Guillaume Nodet <gn...@gmail.com> wrote:
>> I'm not sure how to implement it either :-(
>> Camel does not really have a notion of InOut.
>
> Well, it kinda does - a message Exchange can be in-only, in-out or
> out-only from the API perspective. i.e. any Camel message Exchange can
> have an in message, or an in and out.
>
> The main difference is there's not an expicit 'createInOnly() v
> createInOut()) method. The idea being that the MEP could be configured
> on the endpoint/component as internal metadata or could be a header on
> the exchange etc. i.e. rather than making the API really different;
> each processor/component can be kinda polymorphic.
>
> Am sure we might need to extend the routing DSL though to deal with
> InOnly v InOut components in a cleaner way. Right now Camel tries its
> best to do the right thing. e.g. if you go
>
> in -> A -> B -> C
>
> then if A is InOnly and it mutates the IN message, its passed to B; if
> B generates an OUT, then the OUT is passed as the IN to C etc. The
> idea was to try simplify the component developers perspective of
> working on the bus; so the routing DSL could try do the right thing;
> then leave it to the endpoints to figure out how to map the different
> MEPs to their technologies. e.g. an endpoint could map an InOut to 2
> different InOnly message exchanges etc.
>
>
>> Are you talking about the jbi -> camel side, or the
>> camel -> jbi side ?
>
> I think the main issue is that right now when a camel message exchange
> is being dispatched into JBI, its currently no clear way of knowing
> what kind of JBI exchange type to create. We could fix this by having
> some kinda property on the Camel Exchange to tell the servicemix-camel
> what kind of JBI MessageExchange is required. (We could then configure
> this on a per exchange instance basis, or default it from some
> configuration on the component or endpoint etc).
>
> e.g. take a look at the JbiBinding.createJbiMessageExchange() method.
>
> I've just patched this method so that a message exchange pattern
> property can be specified on a Camel Exchange which will be used to
> create the right JBI MessageExchange type; if its not specified on the
> Exchange then its defaulted from the JbiBinding object.
>
> Thoughts?
>
The most important thing would be for a components like pipeline and
filter to handle this gracefully. I think most of the Camel EIPs could
make a smart decision here. I think most of us using Camel with
ServiceMix will be using it exclusively for routing- Camel is a breeze
compared to chaining a dozen SM-EIP endpoints together :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGxaDgMrBfzfMVwMcRAmJcAKCXW/8bakToqOyp9s8jk4GCP8/R1gCfXAYI
tUaf5MZDX0m92WzsSwZ67Dk=
=MAVh
-----END PGP SIGNATURE-----
Re: camel + inout mep
Posted by James Strachan <ja...@gmail.com>.
On 8/17/07, Guillaume Nodet <gn...@gmail.com> wrote:
> I'm not sure how to implement it either :-(
> Camel does not really have a notion of InOut.
Well, it kinda does - a message Exchange can be in-only, in-out or
out-only from the API perspective. i.e. any Camel message Exchange can
have an in message, or an in and out.
The main difference is there's not an expicit 'createInOnly() v
createInOut()) method. The idea being that the MEP could be configured
on the endpoint/component as internal metadata or could be a header on
the exchange etc. i.e. rather than making the API really different;
each processor/component can be kinda polymorphic.
Am sure we might need to extend the routing DSL though to deal with
InOnly v InOut components in a cleaner way. Right now Camel tries its
best to do the right thing. e.g. if you go
in -> A -> B -> C
then if A is InOnly and it mutates the IN message, its passed to B; if
B generates an OUT, then the OUT is passed as the IN to C etc. The
idea was to try simplify the component developers perspective of
working on the bus; so the routing DSL could try do the right thing;
then leave it to the endpoints to figure out how to map the different
MEPs to their technologies. e.g. an endpoint could map an InOut to 2
different InOnly message exchanges etc.
> Are you talking about the jbi -> camel side, or the
> camel -> jbi side ?
I think the main issue is that right now when a camel message exchange
is being dispatched into JBI, its currently no clear way of knowing
what kind of JBI exchange type to create. We could fix this by having
some kinda property on the Camel Exchange to tell the servicemix-camel
what kind of JBI MessageExchange is required. (We could then configure
this on a per exchange instance basis, or default it from some
configuration on the component or endpoint etc).
e.g. take a look at the JbiBinding.createJbiMessageExchange() method.
I've just patched this method so that a message exchange pattern
property can be specified on a Camel Exchange which will be used to
create the right JBI MessageExchange type; if its not specified on the
Exchange then its defaulted from the JbiBinding object.
Thoughts?
--
James
-------
http://macstrac.blogspot.com/
Re: camel + inout mep
Posted by Guillaume Nodet <gn...@gmail.com>.
I'm not sure how to implement it either :-(
Camel does not really have a notion of InOut.
Are you talking about the jbi -> camel side, or the
camel -> jbi side ?
On 8/15/07, Steve Kondik <sh...@chemlab.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> It seems like the servicemix-camel component can only send InOnly MEP..
> I need to be able to go thru a sequence of transformers which needs an
> InOut.
>
> I don't know enough about Camel yet to implement this, but I think that
> if the endpoint isn't the last in the routing chain (or using a
> pipeline()), it should send an InOut?
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGwwK3MrBfzfMVwMcRApbnAJ9sNySH2NqTjPXapNnsjB097850ZACdEJny
> hqR3ZV3gss9c4hefgIO4uoQ=
> =ri2B
> -----END PGP SIGNATURE-----
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/