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

I spent about 90 minutes on a call Friday before last talking to a new CDK user with lots of questions.  Good questions... about JBI in general, Component Toolkit, exchange patterns, the OJC build system... all the factors that must be considered when developing a JBI component.  But this post isn't so much about how CDK simplifies these things but rather an analogy that will maybe help how JBI works and where a component fits in.  I will acknowledge up front that while my analogies always make sense to me, my track record with others is... well, let's go with "hit and miss" (because "crappy" would be less glorifying... and more accurate).

You're at work and your boss tells you to run some errands in your Hyper-Text Teal Porsche (which basically means you're color-blind and ruined a nice car by writing on it...moving on).  You have a package of expense reports and an address, not to all the places you're going but rather to where you start.  Your tacky car is clean (as in recently SOAPed) and you head out to your starting point: the Binding Center.  When you arrive, the BC folks find your car offensive and decree you must be normalized before you can continue on your way.  The address you're given is in JBI City, which means you'll need a factory-fresh hover car (including navigation system) to run your errands (can't drive foreign cars in JBI City...only hover cars).  The BC folks enter the address into the navigation system and send you to the NMR highway via the Delivery Channel onramp.

Did I mention the hover cars have auto-pilot?  Once you're buckled in, the hover car gets on the highway and makes a beeline for the offramp you need.  Since you're running business errands, you exit the NMR highway at the offramp for the BPEL Service Emporium.  Upon arrival, you park and head to the Processing Center to find out which group handles expense reports.  You're directed to a Business Processing Activities room, where you're greeted by the Receiving Activity coordinator, who tells you you're first activity is to copy some important values from your expense report to another ledger.  Next, you need to enter the expense report into another system, one that you don't know how to use because all the data fields use different names than the corresponding fields in your report.  Fortunately, this BP room has hover car rentals available (as each hover car's navigational system only knows how to get one place and back) to take you and your expense reports somewhere that translates them into the right format.  Some translations are done in house, but others are sent to the XSLT Service Emporium, which is your next stop.  After checking out your hover rental, you're back on the highway and soon getting off at the XSLT Delivery Channel offramp.  One translation later and you're back on the highway, stopping by the BPEL Service Emporium to pick up your original hover car (the loaner from the Binding Center).  

An important note about renting hover cars: always send a thank you note.  Always.  Either you're done using it or something was wrong with the car and you need to notify the rental center about the error.  Back to the analogy...  You've gotten your expense reports translated, you've returned to the BPEL Service Emporium, and you've sent your thank you note for the translation.  Pick up your original hover car and get back on the NMR highway because you need to get back to work.  Finally, you're back at the Binding Center, where you send your thank you note and grab your teal Porsche on the way back to the office.

So............could you tell I was describing a BPEL process, exposed via HTTP, with an Invoke to XsltSE throw in?  Were you able to follow at all?  Resounding silence is not the response for which I was looking... 

Here's how it breaks down:

Be sure to check out the CDK Concepts wiki for more details on the concepts crammed into this analogy. Thanks for reading!

This entry is looooooong overdue, for which I apologize.  Remember those posts about CRL?  Uh...er....please disregard...hehe...  A little history: when CRL began, we (at Sun) were just starting to build our JBI components.  Problem was, we couldn't anticipate how developers would want to implement their component... so we over-anticipated everything.  Every important piece was an interface, everything was pluggable.  So much effort was made to not get in a developer's way, we ultimately got in the way.  Too many interfaces, too much exposition necessary just to understand how to use CRL.  Es no bueno...  To anyone who read and/or tried to make sense of these epic technical manifestos...I'm really, really sorry.

So I started over.  As in from scratch.  The result: Component Toolkit.  Same basic idea (i.e. help developers implement a JBI component), but much simpler architecture and interfaces.  We've built dozens of components since CRL began and learned there was certain functionality every component needed.  Ok, that's built in.  Systemic qualities...them too.  Other than that, no clutter.  There are only a few interfaces to implement, most of which have base implementations providing all sorts of little helpers to ease the complexity of building a component.  Best thing to do is check out the main wiki and the Using Component Toolkit wiki to learn more.  As always, please post questions/feedback/issues to the OpenESB Users forum.

You can also read my post about the new Component Development Kit (CDK).  It's beta, but one Ant target gets you a brand new JBI component complete with Component Toolkit stubs, installs and starts out of the box... check it out! 

An early New Year's resolution: blog more.  Company's struggling a bit (if you haven't heard), but there's still cool stuff coming down the pipeline and I owe it to both of us (he says hypothesizing a reader) to talk it up some.  So expect more blog entries; less structured perhaps, as my secondary impendiment to blogging has been my compulsive need to prepare a wiki's worth of info versus just jotting down a few thoughts about whatever it is that's keeping me busy...

Towards that end, now that my Trojans have assured themselves a Rose Bowl berth at the expense of my alma mater and Florida has proven that Alabama's no big deal, let's talk us up some Component Development Kit (CDK).  Chikkala has done a lot of awesome work to help JBI component developers get a head start, but there still seemed to be a lot of confusion about how to actually go about implementing a JBI component.  Without wanting to disparage that which came before, we (the slowly-growing CDK team) decided to go in a different direction by integrating Component Toolkit into the mix.

Which brings us (finally...way to bury the lead) to the new CDK.  Wanting to focus a developer's attention on the important moving parts of a JBI component, I wrote a little GUI (the "JBIC Console" ) that displays the most pertinent configuration of a JBI component.  I've attached some screenshots... right now, there are three primary views: Project view, Component view, and Pom view, each represented by a tab.  The status window at the top gives you hints about how to use the editor and the source pane at the bottom highlights the underlying xml you're editing and/or viewing.  Any fields with an "XML" button are not editable (for now); most others are.  There's some info on the wiki, but it's a little out of date.  I'll fire off a quick post as soon as they're updated.  

Ok, so you get a composite view of a JBI component. You can also create a new component with just a few simple steps.  Again, more wiki updating is necessary, but the new CDK is Ant-based and already part of the open-jbi-components project (available for check out here).  From the ojc root, go to jbi-cdk/comptk and type "ant help", which shows you two targets: open and create.  Type "ant open" and you're prompted for a project name, which must match the root folder of a JBI component project, and the JBIC Console displays the project.  (You may need to point to the project's top-level Maven POM, which for now is required.)  Type "ant create" and you're prompted to choose a BC or SE and provide the name of your component project and presto! you've got a project.  A caveat: it's assumed the component will be part of open-jbi-components ojc-core module; in upcoming phases we'll support partner contributions (located in the ojc root) and ojc-external projects, which require a distribution mechanism still under design.

The project that's created will build, install, and start out of the box.  That said, it doesn't do anything.  You'll need to implement Component Toolkit's ExchangeHandler interface, details of which are available now on the Using Component Toolkit wiki and soon in a to-be-written blog entry.  You may also need to manually build service unit artifacts to deploy applications to your component; this is something else that the new CDK will tackle in upcoming phases.  There's still a lot of work to be done, but we're gearing up, adding resources, and will be working hard on making it easier than ever to build a JBI component.

Feel free to play around with the Console and post any issues/feedback/questions to the OpenESB users forum (so I can bore....er, I mean, reach... a larger audience).  Ciao!