Looking for a basic starter pom.xml for your OSGi project?

Here’s a quick and dirty pom.xml to create a simple OSGi bundle that should get you up and running fast (but not so fast that you shouldn’t take a second to change the package names, of course):

I lifted this partly from some materials I have and partly from the Apache Felix docs on the maven-bundle-plugin.

To get it installed in just a few seconds first type mvn clean install. Then boot up something like Apache Karaf and type install mvn:com.michaelrice/my-simple-osgi. Like this:

simple-osgi-install

Done. Stay tuned and maybe I’ll write some posts about how to make it actually do something.

The history of Fabric8, Fuse, ServiceMix, and Camel according to me

For most of my Java career, I’ve been an enterprise application development person, which is to say I’ve principally worked with application servers like Tomcat and JBoss as well as frameworks thereupon like Spring MVC, Struts, JAX-RS, blah blah. At the same time, I’ve tried to keep track of the integration space because it’s fascinating, and now I finally get to work the technologies a lot more. So here’s my chance to do a crash catch up piece on the past ten years.

Let’s start with JBI

jcpThe Java Business Integration (“JBI”) spec is hardly the beginning of enterprise integration, but it’s a good starting point for our discussion. JSR-208 was (and still is) a specification for specifying how an enterprise service bus (“ESB”) should work with pluggable components (sort of like J2EE containers). But it’s a complicated spec; from the intro:

JBI employs concepts similar to J2EE to extend application packaging and deployment functionality to include JBI Components. JBI Components are an open-ended class of components that are based on JBI abstract business process metadata. The JBI JSR itself does not define how developers code Components. Both standard and proprietary ways of coding Components may exist. A specific class of Component may provide rich business process functionality while another class of Component may provide a specialized integration function like a data transformation table or support a domain specific business rule encoding. A JBI Application is composed of one or more JBI Components and service assemblies.

Don’t worry, I didn’t understand it either, which explains the history that follows:

Enter stage left: Apache ServiceMix

servicemixApache ServiceMix started its existence as an open source ESB by implementing the JBI in 2005. It took a couple of years and three versions to fully implement the JBI. While the JBI implementation was complete by the third version, many felt that ServiceMix had become an overly heavyweight container, which contrasted with ServiceMix’s origins as a lightweight implementation of JBI.

Around the same time that ServiceMix was maturing, OSGi was finally starting to take hold (see the withdrawn JSR-8). The ServiceMix team decided to adopt the OSGi model and implement that as a core.

(My source on this stuff is ‘s post, Thoughts about ServiceMix)

Goodbye JBI, hello again ServiceMix

camelBecause JBI was a complex (“overly ceremonious,” according to the Fabric8 documenters) spec that effectively dictated a heavyweight container, competing technologies like Spring Integration and Camel emerged (those of us who were excited about enterprise Java app development back in the 2000s will see the analog to Spring). So the ServiceMix team abandoned JBI in it’s next major revision, version 4, and fully embraced Camel and an OSGi core.

Something else interesting starting happening after this release: ServiceMix evolved from being a monolithic project into something that looked more like a collection of pieces and parts. For example, the ServiceMix core components evolved into Apache Karaf. And ServiceMix started bundling in its other dependencies like ActiveMQ, CXF, Activiti for BPM, and etc.

Because ServiceMix is now really just a prepackaged assortment of OSGi bundles, some developers are simply using the lower-level components themselves, such as Karaf, and then deploying the specific bundles they need for their integration issues.

So what is this Fuse thing?

redhatIt’s probably safe for you to generally think of Fuse as a hardened, supported version of Apache ServiceMix, which is a Big Deal in the enterprise space: I know if I were an IT manager with a budget and mission critical applications, I would look for a supported option over a community-supported open source option every time.

The Fuse project was started by FuseSource, which Red Hat acquired in 2012. Red Hat renamed the project JBoss Fuse, and Red Hat offers all the things that Red Hat does a great job at such as stablizing the code, supporting it, documenting it, and pushing changes upstream (see my about page for disclaimer!).

And what about Fabric8?

fabric8Fabric8 takes Fuse to the next level. Fabric8 builds on Fuse by including a full web-based GUI (itself an open source project called Hawtio) and includes interesting and powerful new features such as fabrics, support for Docker containers, and so on. More about Fabric8 in a future post.

One of the things that’s easy to get confused about is the relationship between Fuse and Fabric8. That is to say that if you install Fuse from the Red Hat Network it’s basically bundled into the Fuse download you get; put differently, you can think of the supported JBoss Fuse as combing both Fuse and Fabric8.

By the way, a lot of this history I gleaned from the Fabric8 documenters here: http://fabric8.io/gitbook/overview.html.

Peggy Noonan touches on consulting

If I could do it all over again, I’d be a writer. And I’d be like Peggy Noonan. Here she is on consulting:

There are reasons for traditions and arrangements. Sometimes they are good and sometimes not, but they are reasons, explanations grounded in some sort of experience. I had a conversation about this a few years ago with a young senior at Harvard who on graduation would go to work for a great consulting firm that studies the internal systems of business clients to see if they can be bettered. He asked if I had any advice, which I did not. Then I popped out, with an amount of feeling that surprised me because I didn’t know I had been thinking about it, that he should probably approach clients with the knowledge that systems and ways of operating almost always exist for a reason. Maybe the reason is antiquated or not applicable to current circumstances, but there are reasons for structures, and if you can tease them out they will help you better construct variations or new approaches. I can’t remember why but this opened up a nice conversation about how consultants walk into new jobs with a bias toward change—the recommendation of change proves their worth and justifies their fees—but one should be aware of that bias and replace it with a bias for improvement, which is different.

The rest of her post is fantastic (as usual), but the point is clear from the introduction’s implications.

“The way it is” or the “way it should be”

This is my blog, so allow me to air my sole weird quirk: for the past five years or so, I just can’t fall asleep without listening to Steven Covey’s The Seven Habits of Highly Effective People. I know it sounds like I’m making it up or it’s it’s an exaggeration, but it’s not. I actually took an old pair of iPhone headphones and cut off one side so the other side would stop bothering me as I fell asleep listening to Dr. Covey.

When the sun’s up, however, I listen to lots of other people too, such as Anthony Valadez on KCRW. Valadez is one of KCRW’s many amazing DJs and one of my favorites; he’s got the perfect LA energy on air. And he posts cool stuff off air too. One of his tweets asked this:

Valadez’s tweet seems like just a casual, fleeting thought or a reaction to something that he might have overheard at some restaurant on the Eastside or something. But it’s actually a profound question that probes more deeply than one’s ability to have a voice in the big issues like race, or Ferguson, or Gaza, or poverty, or the price of a gallon of gas.

I think Valadez’s question goes to the day to day little injustices we see all around us. And I don’t think Dr. Covey really has a direct answer. On the one hand, Covey would remind us that there are two concentric circles: the circle of influence and the circle of concern (the former is usually contained within the latter). He would remind us not to waste energy beyond our circle of concern by not being overly reactive to external forces, like Ferguson — or even something pedestrian like why there’s a bunch of “red tape” when we need to bring some open source software package into the enterprise.

But really I don’t think that would be the end of Covey’s conversation with Valadez.

I want to think that Covey’s answer might be something like I gave to Valadez on Twitter. I said, “I’ve got small kids, so step one is to teach them courage. Then we’ll get to the latter.” What I meant by that is that you have to consider your principles first, then figure out how to act on them. While not stated, surely one of the levers of Covey’s “circle of influence” would be the extent to which you have the courage to act on your other principles. Surely that would naturally give you — or hopefully my kids — a much bigger circle of influence, so maybe my kids will have the circle of influence to not only refuse to accept “the way it is” but to actually change the status quo in the process.

In the world of consulting, where I am, it’s more nuanced than just having the “courage” to starkly your mind, speak the “truth,” or to be the “loudmouth” (as so many on Twitter compete to be), however. I’m contrasting myself with the prototypical activist on the street with a megaphone. While it surely takes a species of courage to be that person, the megaphone activist’s circle of influence will either (1) shrink rapidly or (2) fail to grow in sensitive political environments like Corporate America.

So where is the balance in consulting or professional services in the corporate world, generally? The majority of my peers would probably agree that clients ostensibly hire consultants like me to get them from their perceived point A to a perceived better place called point B, at least in technical engagements.

But I think they hire a lot more than just capabilities and technical prowess. I believe they hire confidence. They hire guarantees of execution. They shift risk. So to do my job — to deliver on those promises — means that I have to sometimes, sensitively and selectively, draw a distinction between the way it is for a client and the way I believe it should be. A megaphone would be so much easier.