Hello Vincent, The routes are defined depending on the origin of the message. In my exemple, "if my message come from thisEndpoint, do a multicast, to theseEndpoints.
At the moment, all is written in the code of the routeBuilder, and the possibility of any dynamicity about that is something I would like to test. However, the routeBuilder beeing a java class, you can possibly make other java class, loading config files for exemples and then make your routeBuilder work according to these other classes. I even dream of the possibility that I could get information about endpoints and or services available and make routes according to that. You are talking about dynamic routes "for each" message. I am wondering if you are refering here to a content router : A route for which target endpoints depends on the content of the message. This can be done in camel, but I haven't tried. If you haven't already, I suggest you try using camel on a simple example you made up. You'll understand better how it works and what might be possible. To sum up I'd say - The routes in camel looks like "for message from (x) do (y) and send them to (z)". The y is limited to the EIP I guess. - The fact that the routes are defined in a java class RouteBuilder, makes camel extendable to quite whatever you want. I do think that the routes are executed for each message at run time. If it really is the case then you can make it depends on whatever you want to have dynamicity. I hope this help and that I made it clear about what I did, what I know, and what I believe ;) Regards, Vivian -----Message d'origine----- De : Vincent GIRARDREYDET [mailto:[email protected]] Envoyé : mercredi 19 août 2009 11:01 À : [email protected] Objet : Re: Camel, JMS - Services - servicemix exemple : Feedback Hi Vivian, Thank you for this interesting feedback. Could you elaborate a bit more about how you use the RouteBuilder ? That is something I am studying in Camel and I am wondering if you can build dynamic routes (for each message) on the fly with this builder, or if routes are built dybamically, but at deployment time (when the SA is loaded). Madesclair Vivian a écrit : > Hello, > > I just finished my prototype (well it's quite ugly at the moment but > hey.. it's working ^^) and I wanted to provide a little feedback about > what I did lately because some stuff where not obvious to me at first > sight and it might help other beginners. I want to talk about Camel, > and the JMS BC use. But first, let me describe quickly my prototype, > so if people feel they are doing something close, they can ask for > more info. In any case, reading this, always remember that my > experience about ESB is limited to that prototype and general study > over a few months, and I never digged into the code of servicemix. > > My prototype is using webservices (CXF components) to implement a very > simple idea : 2 services (external to ESB) offers to look up for > flights from different companies. 1 service (on the ESB) offers to > look for any flight. It will contact any possible look up service. > This is in my opinion, the smallest prototype you can implement to > begin to see the power of ESB, although I would like to check many > more things, I am not sure I will have time. You can check a diagram > of my prototype in [1] > > You can see camel in the middle, with no need of JMS queue. Camel > provide a JBI endpoint for itself and therefore can be used as any > other component inside servicemix. Also, good surprise to me : Camel > support InOut MEP. (I started by using AsyncBridge and Pipelines...) > > About JMS. I did not use it (as you can see) but I though I had to at > one point and because of that, I studied the JMS BC of servicemix a > bit. The first thing I want to tell : It is quite hard to understand > for a beginner, because you can mix up many thing (provider, consumer, > service, message...). And therefore, If you don't read each line of > the documentation, and make some quick diagrams, you may spend much > time on it. So I made a quick diagram (see [2]) about this component > which (I hope) might help understand it at a glance. The fact that a > service is provider or consumer always refers to the ESB and it's > internal structure. On the diagram, the queues should help you see who > provides and consumes the messages. > > Finally, I understood one thing. The possible message format (XML for > sure, but what's inside the XML) in an ESB must be well known and > defined, and then abided by with message translators. That would make > the ideal organization around a connector quite constant, as shown on > [3]. The double sided arrows show InOut MEP, but this can easily be > adapted. An EIP message translator can be implemented in servicemix > using either marshallers or Saxon, or both. > > If anyone want to say anything more, I'd be glad to hear it. I could > be mistaken about something, don't hesitate. Also, I know many of the > things I said are in the documentation, but when (like me) you begin, > this is quite a lot of things to understand quickly and I've always > thought a good diagram is better than a page of explaination. > (although a diagram can't be good on itself) > > Thanks to all the people here, > Best regards, > Vivian > > > > Attached diagrams : > > [1] : ArchitectureESB-AV2CA-finale.jpeg > --------> red rectangles are SA. > > [2] : ServiceMixJMS.jpeg > > [3] : Generic connectors > ---------> The routing slips process from top to bottom
