JBI Doubts

TheServerSide.com has published an article on JBI by Meeraj Kinnumpurath. I don’t have any disagreements with the technical content (it’s on an introductory level, and does a good job at introducing the main concepts). In case you’re not familiar with JBI, though, and have only read a bunch of articles like this, you might have some doubts left. The main one is probably “What’s it good for?”

I have been exposed to JBI in the last few months (I wrote a WS-I binding component for testing purposes on top of ActiveSOAP, and was part of a team that implemented a service engine). Call me a cynic, but from the limited experience I’ve gained in the process, there’s one major question left: “What’s it good for?”

I remember that in the early stages of my professional life, I was a huge framework fan. Any concept had to be turned into a library; the more generic, the better. At some point in time, I recognized most of these efforts did not lead to a customer’s problem being solved, but rather to me having something more interesting than the customer requirements to work on. (Think about it: How many engineering hours have been spent on logging libraries that should rather have gone into solving business problems?) It’s very tempting to fall into this Qualified Engineer’s Procrastination Trap™, and sometimes you end up building something so generic that it ends up serving essentially no purpose at all.

That’s what JBI reminds me off: A generic engine to turn some input into some output by means of some processing … seriously, folks: maybe it’s better to stick with an already established engine, including its customization environment, next time.