Gatti, mules and ESB ... Good evening Another week draws to a close, thankfully. At least my dear Eli returns home.
I started running again with some frequency: Oh God, having gone Monday and Wednesday I believe that speaking rate is a bit 'premature, but the idea is. I have to pick up the pace especially as the number of times a week, to increase the duration of each output there will be time. Needless to go every fortnight and to die for one hour. Best of 35 minutes 3 times a week, easy target, especially if you are home alone with the cat.
(5 minutes later because of that cat that cuddles claim)
I'm back here.
Therefore, changing the subject to spend some nerd considerations.
This week I worked mostly on JMS (
OpenMQ to be precise) and ESB (Mule
2). A lot of things "Enterprise" :-).
Before I give my impressions on the products in question, a couple of considerations, perhaps trivial, but very true, unfortunately, I rediscovered recently:
- A good product does not replace the need for good design , the only ovverto having an ESB will save you from a supplement to spaghetti. Ok it is obvious ... but then how come it happens so often?
- The act of writing xml configuration instead of code makes life easier contrary, may be complicated, especially because it loses most of the tools for developing, debugging and testing.
- Using a complex product that allows you to do complex things is not trivial: an ESB is not a toy. In addition to having compredere the basic model, the components and the programming language (configuration, excuse me ... but in the end what is the difference?) Need a further effort to "play by his rules." Reasoning services and code is the standard way in which the average programmer approaches the problem average. If you miss this fundamental point is liable to pay the price the complexity of an ESB without drawing the maximum benefit.