Kevan's Place: Don't blame me... I was born awesome!

What is CRL?  Where to begin?  There's a lot of information I can throw at you, but I don't want to overwhelm anyone into thinking it's too complicated to merit its use.  At the same time, I need to not only explain clearly what it is but also make a case for using it.  I'll start with a little background and then delve in while trying to avoid turning this into a development guide.

As our teams started building JBI components, we soon found ourselves in a typical development quicksand-like scenario known as the copy-and-paste effect.  We've all done it at one time or another; you need to get your component/module/etc. ramped up quickly but don't want to reinvent the wheel.  So you look at a similar piece of code, imagine that you'll still respect yourself in the morning, and there you are.  Doesn't mean the code is bad or doesn't work (on the contrary), but the cost of supporting code like this is always higher in the long run.  CRL is the antithesis of this quagmire.  I'd had experience building reusable libraries for a homegrown SOA at my previous job (and loved the complexity of designing for scenarios of which I couldn't even conceive), so I found incriminating photos of a few of our team leads and enlisted their help.  To give credit where credit is most certainly due, I present the heart of the CRL team:

• Me, myself, and I - XSLT SE
  
• Murali Pottlapelli - BPEL SE
• Alex Fung - HTTP BC
• Sherry Weng - File BC
• Andi Egloff - JBI component guru/architectural advisor
  
• other contributors included Keith Babo and Ron Ten-Hove
  

Yeah, yeah, background, schmackground.  What is it?!?  CRL stands for the Common Runtime Library ( pronounced "coral" ) and it's a set of utilities which can be assembled into a JBI component.  That's it.  There are certain parts of JBI components that are fairly consistent across components, both service engines and binding components.  These are the areas in which we focused to create utilities that not only could support any conceivable component but also incorporated the best practices as determined by our collective experience.  The XSLT SE was the first guinea pig, but at least two other SEs are using CRL and the BPEL SE will soon undergo refactoring to incorporate CRL.  In a perfect world, we'll get HTTP BC to refactor as well.

There are three aspects of CRL that I think differentiate this library from other similarly intentioned frameworks.  First, it does not attempt to hide all the complexity of the JBI environment.  You should have a decent understanding of the defined message exchange patterns, especially InOnly and InOut, but you won't have to have memorized the JBI spec.  Second, the various interfaces will guide you to the important decisions you'll need to make about the composition of your component.  There was a point at which hiding the complexity would have risked hindering the functionality CRL could provide; instead we settled on designing the interfaces to clearly identify the parts to which you must pay attention when building your component.  Finally, it's optional.  Once you start using one part of CRL, you're not forced to plug in all the other parts in order for your component to work.  Mind you, some things require support; but the focus was on interface-driven design.  So if you don't like how we implemented something, make sure you include how you did it when you tell us where we went wrong (which of course will never happen).  In summary, building a JBI component is not a trivial task, but ideally CRL makes it a much more manageable one.

Over a series of blog entries in the coming weeks, I will describe the process of building a JBI component using CRL.  I'm also working a detailed user manual, which the aforementioned blog entries will complement but not replace.  Until then, enjoy Oscar night.  (And the previously mentioned incriminating photos will be available to the highest bidder...admit it, you're curious!  LOL!)