-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Strachan wrote: > On 8/17/07, Guillaume Nodet <[EMAIL PROTECTED]> 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-----
