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

Reply via email to