I'll have to clean it up first, and then ask to my project manager (he is on 
holidays until end of august). I'm keeping a follow up on your e-mail.


-----Message d'origine-----
De : Dmitry Ulanov [mailto:[email protected]] 
Envoyé : lundi 17 août 2009 17:18
À : [email protected]
Objet : Re: Camel, JMS - Services - servicemix exemple : Feedback

Can you commit your code, for a example, to GitHub? It may be interesting.

On Mon, Aug 17, 2009 at 7:08 PM, Madesclair Vivian < 
[email protected]> wrote:

>  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