I'm glad to see that
Scott Bellware liked my IBF presentation this week. I hear that
his TDD workshop was awesome as well. If nothing else, he managed to draw more people than I - or
IBF - did. In some ways, that's very good. It's encouraging to see that workshops on testing and quality are full to the last seat because it hasn't always been that way in our industry.
I have to admit that I'm even a little jealous because I feel that IBF deserves some more interest. After all, there hasn't been an IT publication in the past 18 months that didn't go overboard praising the benefits of SOA. IBF actually delivers a solution for the client-side, or the visible layer, of a service-oriented architecture.
However, it is somewhat peculiar that most articles on SOA focus on the web services and the orchestrations. Or should I say: the invisible layers? Now here we are with IBF which is as service-oriented a framework as they get from a couple of different angles.
First, the Information Bridge Framework truly delivers on the promise of SOA. It connects the people in the businesses and the processes they execute to the business data regardless of what system or application stores the data. And even better, IBF connects the people to the data by hooking into applications that business people love and cherish like Outlook, Word and Excel.
IBF ships with some serious tools and some serious infrastructure. The loosely coupled design of the framework is poetic. The framework decouples user interface, service layers, query criteria, data views, controller logic… Even the definitions of the available services are abstracted away and provided by a meta data service.
So to answer the headline in Scott's post, yes I do believe IBF is a herald of the service clients to come. An autonomous client that plugs into another applications and communicates with it's host via XML messages. That's what we saw in the Don-and-Chris Show during the PDC 2003 keynote on Indigo. Even this implementation is almost completely decoupled from Office. It runs autonomous during debugging already, but still requires a COM interface (via. NET interop) as the backchannel to the host app. In the future hopefully more and more apps will be able to share their current context, serialized to XML messages, with frameworks like IBF. I have two SO projects going on right now that that would tremendously benefit from such capabilities.
So maybe a year from now, my SO talks will draw as big an audience as TDD does today. Hopefully by then I am ready to answer the other question Scott asked during the seminar: How does one post to IBF without office?