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