This tutorial will require Maven and Karaf. Download maven from the maven website. Download and install karaf as described in the getting started guide on the Karaf website. You will also need the code that goes along with this example. You can get it at my github repo. After getting it, make sure to run ‘mvn install’ from the top-level project. This will build and install all of the bundles into your local maven repository. Although you can install bundles a couple different ways, using maven is easiest. Note that this sample code is mostly made up of package names without any real Java classes (except where the tutorial specifies).

First thing to do is start up karaf. In a plain distribution there should be no bundles installed. Verify this by doing “osgi:list” at the karaf commandline. Going in order, we will test out the rules from part one of this two-part series:

For every Import-Package package declaration, there must be a corresponding Export-Package with the same package

To test this rule, let’s install Bundle A from our sample bundles. Bundle A specifies an Import-Package of “org.apache.foo” package. According to the first rule, this bundle cannot move to the “Resolved” state since there is no corresponding bundle with an “Export-Package” of org.apache.foo.

From the karaf commandline, type “osgi:install mvn:explore-bundle-resolution/bundleA/1.0″. This will install the bundleA bundle. Now do a “osgi:list” again. You should see the bundle installed, and under the “State” column, it should say “Installed”. Now try “osgi:resolve bundle id” where bundle id is the ID listed from the “osgi:list” command. This will try to resolve all bundle dependencies and put it into the “Resolved” state. It won’t resolve, however. Type “osgi:list” again to see the state of the bundle. It’s still in “Installed” state even though we asked OSGI to resolve it. Let’s find out why. Execute the “osgi:headers bundle id“. Under the Import-Package, you should see the package name org.apache.foo listed in a red color. This dependency is missing, so let’s add it. Type “osgi:install -s mvn:explore-bundle-resolution/bundleB/1.0″. Note the ‘-s’ switch in the command. This tells OSGI to start the bundle once it’s installed. Now type the osgi:resolve command again (with the appropriate bundle ID). This will now resolve the bundle.

Import-Package dictates exactly what version (or attribute) it needs, and a corresponding Export-Package with the same attribute must exist

Let’s install bundle C: “osgi:install -s mvn:explore-bundle-resolution/bundleC/1.0″ List the bundles again, and you’ll see that although bundle C depends on org.apache.foo, it specifies an Import-Package with a specific version=1.5. There is no version 1.5 that is resolved, so bundle C will also not resolve. Bundle D happens to export a package org.apache.foo with a version equal to 1.5. Install bundle D the same way we’ve installed the others, using the -s to start it. Now try to resolve bundle C and it should work (“osgi:resolve bundle id“).

Bundles installed first are used to satisfy a dependency when multiple packages with the same version are found

This rule says that if there are multiple packages exported with the same version, OSGI will choose the first-installed bundle to use when trying to resolve bundles that import the package. Continuing on with the previous example where we installed bundle C and D… consider that bundle D exports org.apache.foo;version=1.5. So if we install bundle F that exports the exact same package and version, we should see that bundle C is resolved with the package from bundle D and not bundle F. Let’s see.. install bundle F: “osgi:install -s mvn:explore-bundle-resolution/bundleF/1.0″. Do an osgi:list and see that both bundle D and F are correctly installed and “Active”. This is a cool feature of OSGI: we can have multiple versions of the same package deployed at the same time, (including in this example the exact same version). Now we should uninstall bundle C and re-install it to see which bundle it uses to resolve for its import of org.apache.foo. Try running “osgi:uninstall bundle id” to uninstall bundle C. Now re-install it using the command from above. It should resolve to use bundle D. Use “package:import bundle id” to verify. You can try switching things around to get F to resolve. You may need to use “osgi:refresh” to refresh the OSGI bundles.

Bundles that have already been resolved have a higher precedence that those not resolved

In a way, we have already seen this with the previous rule, but this rule comes into play when hot deploying. This is left as an exercise to the reader as this post is already getting pretty long and I would like to cover the “uses” directive next.

Bundle “uses” directive

The “uses” directive adds one of the last rules and constraints to avoid runtime class-cast exceptions. Please review my previous blog post for details about the “uses” directive. To simulate how the “uses” directive works, we will install bundles G, H, I, and J and notice how the container enforces the “uses” directive.

Bundle G represents a sort of “service” module that client modules can call to “execute” some form of processing and return a result. The result it returns is an object of type BarClass that comes from Bundle H. But if a client makes a call to bundle G, it too must use the BarClass from bundle H or it will result in a class cast exception. In our samples, Bundle I is the client code and Bundle J represents a different version of the BarClass. Install the bundles in any order you like, but my demonstration followed this order: J, H, G, I. Note that the version of org.apache.bar is indeed the 2.0.0 version which comes from bundle H even though bundle H was installed second (contrary to the rule above). This is because bundle G specified the “uses” directive to depend on a specific version of org.apache.bar.

First, you set up your network connectors by configuring them in the ActiveMQ configuration file. This configuration gets mapped to the corresponding ActiveMQ beans using the xbean library for which I have a separate blog post which explains exactly how this is done. To specify network connectors, you add the <networkConnectors/> element to your configuration file and add a <networkConnector/>, <multicastNetworkConnector/>, or <ldapNetworkConnector/>. These three different types of network connectors can be used to establish a network of brokers with <networkConnector/> being most common. Here’s how the three map to Java classes:

<networkConnector/> maps to org.apache.activemq.network.DiscoveryNetworkConnector
<multicastNetworkConnector/> maps to org.apache.activemq.network.MulticastNetworkConnector
<ldapNetworkConnector/> maps to org.apache.activemq.network.LdapNetworkConnector

Each of those inherit from the org.apache.activemq.network.NetworkConnector super type as depicted in this diagram:

So when you have a configuration like this:

<networkConnector uri="static://(tcp://localhost:61626,tcp://localhost:61627)" />

a new DiscoverNetworkConnector will be configured, instantiated, and added as a connector to the BrokerService (which is the main class for where a lot of the ActiveMQ broker details is handled). While the DiscoverNetworkConnector is being assembled from the configuration, the URI that you specify is used to create a DiscoveryAgent. The discover agent is in charge of assembling the connection and handling failover events that are packaged as DiscoverEvents. Determining which DiscoverAgent is picked depends on the DiscoverAgentFactory and the URI specified. In the case of “static”, the SimpleDiscoverAgent is used. Each URI in the list of possible URIs are treated differently and are assigned their own Transport (more on this in a sec). Which means, for each URI you list, a new socket will be established and the broker will attempt to establish a network connector over each of the sockets. You may be wondering how to best implement failover then? In the case described above, you will have multiple connections, and if one of those connections is to a slave that isn’t listening, you will see that the connection fails and the discover agent tries to establish the connection again. This could go on infinitely which consumes resources. Another approach is to use just one URI for the static discover agent that utilizes the failover() logic:

<networkConnector uri="static:failover:(tcp://localhost:61626,tcp://localhost:61627)" />

In this case, only one transport will be created, and the failover logic will wrap it and know about both URIs. If one is not available, it won’t keep retrying needlessly. Instead it will connect to whichever one it can and only reconnect to the failover URL if the current connection goes down. Note this approach had a bug in it before ActiveMQ version 5.5.1.-fuse-00-06.

The discover agent is in charge of creating the bridge, but it delegates that responsibility to a DiscoverListener. In the example from above, the DiscoverListener interface is implemented by the DiscoverNetworkConnector.onServiceAdd() method.

To establish the bridge, a transport is opened up for both the local broker (using VM) and the remote broker (using the specified protocol, in this case TCP). Once the local and remote transports are created, the bridge can be assembled in the DiscoverNetworkConnector.createBridge(…) method. This method uses the Factory pattern again to find which bridge to use.

The possible bridge implementations are shown below:

By default, with conduitSubscriptions=true, the DurableConduitBridge is used. Conduit subscriptions establish a single flow of messages to a remote broker to reduce duplicates that can happen when remote topics have multiple consumers. This works great by default, but if you want to load balance your messages across all consumers, then you will want to set conduit subscriptions to false (see the documentation for conduit subscriptions at FuseSource‘s documentation on Fuse Message Broker). When set to false, the DemandForwardingBridge is used. Once the bridge is assembled, it is configured in the NetworkConnector.configureBridge(…) method.

Once everything is assembled and configured on the bridge, it’s then started. Once it’s started, it begins sending broker Command objects to the remote broker to identify itself, set up a session, and demand consumer info from it. This is in the DemandForwardingBridgeSupport.startRemoteBridge() super class method as seen from the diagram.

If you’re debugging errors with the network connectors, hopefully this helps identify possible locations for where errors can take place.

Bundle Resolution Rules

An OSGI bundle’s lifecycle defines the possible states and transitions for a bundle. We will be discussing the “Resolved” state of a bundle which means the state it can reach after being “Installed” and when all of its required dependencies are satisfied. Traditional Java classloading is susceptible to runtime ClassCastExceptions where two classes with the same fully-qualified name from two different class loaders become mixed up and one is used in the wrong classpath space. One of the main goals of OSGI is to avoiding this kind of runtime exception by resolving all dependencies at deploy time with the idea being failing “fast” at deploy time will be easier to debug than trying to track down classloading issues at runtime. Think about how annoying some of the class not found or class cast exceptions are to debug in a Weblogic deployment, for example. OSGI solves this. For a bundle to reach the “Resolved” state, it must have it’s dependencies fulfilled. Think of the “fail fast” approach to bundle resolution like this: if you use a spring application, and one of your beans cannot be wired properly because a bean definition is missing, you will know this at deploy time instead of when a customer is calling your code. The same principle is applied with OSGI; instead of object-level wiring dependencies, we are wiring module and class-loading dependencies.

A trivial explanation of a bundle having its dependencies resolved could go like this: if a bundle imports (Import-Package) a specific package, that package must be made available by another bundle’s exports (Export-Package). If bundle A has Import-Package: org.apache.foo then there must be a bundle deployed that has an Export-Package: org.apache.foo

For every Import-Package package declaration, there must be a corresponding Export-Package with the same package

Bundles can also attach other attributes to the packages it imports or exports. What if we added a version attribute to our example:

Bundle-Name: Bundle A
Import-Package: org.apache.foo;version="1.2.0"

This means, Bundle A has a dependency on package org.apache.foo with a minimum version of 1.2.0. Yes, you read correctly. Although with OSGI you can specify a range of versions, if you don’t specify a range but rather use a fixed version, it will result in a meaning of “a minimum” of the fixed value. If there is a higher version for that same package, the higher version will be used. So bundle A will not resolve correctly unless there is a corresponding bundle B that exports the required package:

Bundle-Name: Bundle B
Export-Package: org.apache.foo;version="1.2.0"

Note that the reverse is not true… If Bundle B exported version 1.2.0, Bundle A is not required to specify a version 1.2.0. It can use this import and resolve just fine:

Bundle-Name: Bundle A
Import-Package: org.apache.foo

This is because imports declare the versions they need. An exported version does not specify anything an importing bundle must use (which holds for any attributes, not just version).

Import-Package dictates exactly what version (or attribute) it needs, and a corresponding Export-Package with the same attribute must exist

What happens if you have a scenario where Bundle A imports a package and it specifies a version that is provided by two bundles:

Bundle-Name: Bundle A
Import-Package: org.apache.foo;version="1.2.0"

Bundle-Name: Bundle B
Export-Package: org.apache.foo;version="1.2.0"

Bundle-Name: Bundle C
Export-Package: org.apache.foo;version="1.2.0"

Which one bundle does Bundle A use?
The answer is it depends on which bundle (B or C) was installed first.

Bundles installed first are used to satisfy a dependency when multiple packages with the same version are found

Things can get a little more complicated when hot deploying bundles after some have already been resolved. What if you install Bundle B first, then try to install Bundle A and the following Bundle D together:

Bundle-Name: Bundle D
Export-Package: org.apache.foo;version="1.3.0"

As we saw from above, the version declaration in Bundle A (1.2.0) means a minimum version of 1.2.0; so if a higher version was available then it would select that (version 1.3.0 from Bundle D in this case). However, that brings us to another temporal rule for the bundle resolution:

Bundles that have already been resolved have a higher precedence that those not resolved

The reason for this is the OSGI framework tends to favor reusability for a given bundle. If it’s resolved, and new bundles need it, then it won’t try to have many other versions of the same package if it doesn’t need to.

Bundle “uses” directive

The above rules for bundle resolution are still not enough and the wrong class could still be used at runtime resulting in a class-cast exception or similar. Can you see what could be missing?

What if we had this scenario. Bundle A exports a package, org.apache.foo, that contains a class, FooClass. FooClass has a method that returns an object of type BarClass, but BarClass is not defined in the bundle’s class space, it’s imported like this:

public class FooClass {
    public BarClass execute(){ ... }
}

Bundle-Name: Bundle A
Import-Package: org.apache.bar;version="3.6.0"
Export-Package: org.apache.foo;version="1.2.0"

So far everything is fine as long as there is another bundle that properly exports org.apache.bar with the correct version.

Bundle-Name: Bundle B
Export-Package: org.apache.bar;version="3.6.0"

These two bundles will resolve fine. Now, if we install two more bundles, Bundle C and Bundle D that look like this:

Bundle-Name: Bundle C
Import-Package: org.apache.foo;version="1.2.0", org.apache.bar;version="4.0.0"

Bundle-Name: Bundle D
Export-Package: org.apache.bar;version="4.0.0"

We can see that Bundle C imports a package, org.apache.foo from Bundle A. Bundle C can try to use FooClass from org.apache.foo, but when it gets the return value, a type of BarClass, what will happen? Bundle A expects to use version 3.6.0 of BarClass, but bundle C is using version 4.0.0. So the classes used are not consistent within bundles at runtime (i.e., you could experience some type of mismatch or class cast exception), but everything will still resolve just fine at deploy time following the rules from above. What we need is to tell anyone that imports org.apache.foo that we use classes from a specific version of org.apache.bar, and if you want to use org.apache.foo you must use the same version that we import. That’s exactly what the uses directive does. Let’s change bundle A to specify exactly that:

Bundle-Name: Bundle A
Import-Package: org.apache.bar;version="3.6.0"
Export-Package: org.apache.foo;version="1.2.0"";uses:=org.apache.bar

Given the new configuration for Bundle A, the bundles would not resolve correctly from above. Bundle C could not resolve, because it imports org.apache.foo but the “uses” constraint on Bundle A specifies that C must use the same version that A does (3.6.0) for org.apache.bar, otherwise the bundle will not resolve when trying to deploy. The solution to this is change the version in Bundle C for org.apache.bar to be 3.6.0.

If my examples were not clear or there is some misunderstanding, please leave a comment.

Just as an aside, a link that I’ve had tucked away in the recesses of my bookmarks may be of interest for those of you wondering whether your architecture is indeed RESTful or just the same highly coupled RPC style that REST tries to alleviate. Roy Fielding, who wrote his dissertation on REST, actively asserts the notion that hyerlinks within resource representations are a must for REST styles, and even further clarifies the uncertainties around implementing REST.

The source code for this sample can be found on my github repository

Fuse Mediation Router is FuseSource’s enterprise-grade, hardened version of Apache Camel that provides a comfortable DSL for describing integrations, mediations, and routing. It’s free, open-source, and has an Apache License. For those unfamiliar with Mediation Router/Camel, take a look at an introduction from Jon Anstey (co-author of Camel in Action)at DZone’s Enterprise Integration Zone: Apache Camel: Integration Nirvana.

We will be using Mediation Router to help write a simple integration between a REST endpoint and a resource files on a file system. I’ll be using camel-cxfrs component to expose the REST endpoint and will be using the camel-file component to read a directory on the file system. The intention of the sample is to describe the configuration necessary to expose the REST interface with Mediation Router, integrate with a backend somehow, transform the data into an appropriate REST response, and send back the response.

To get started, let’s focus on how to set up the REST endpoint. To do so, you would create a JAX-RS resource that describes the java methods that will act as REST endpoints. This sample code requires familiarity with Java API for RESTful Web Services aka JAX-RS. For those unfamiliar, here are some great tutorials to follow along that help to understand JAX-RS.

@Path("/customerservice/")
public class CustomerServiceResource {

// NOTE: The instance member variables will not be available to the
// Camel Exchange. They must be used as method parameters for them to
// be made available
@Context
private UriInfo uriInfo;

public CustomerServiceResource() {
}

@GET
@Path("/customers/{id}/")
@Produces("text/xml")
public Customer getCustomer(@PathParam("id") String id) {
    return null;
}

@PUT
@Path("/customers/")
public Response updateCustomer(Customer customer) {
    return null;
}

}

As you can see, the annotations are the JAX-RS annotations that describe the operations, HTTP methods, and mime-types involved with the REST endpoint. Notice, the return values are all null as this class will not actually be used to handle the requests that come in to the endpoint; the Mediation Router routes will be responsible for processing and responding. Note, however, that instance members are not available to the Mediation Router exchanges, i.e., any instance members injected via the JAX-RS @Context annotations will not be available. To make them available, add them as parameters to your methods.

Declaring the CXF-RS endpoint with Mediation Router can be done one of two ways: Directly in the endpoint configuration like this:

from("cxfrs://http://localhost:9090/route?resourceClasses=com.fusesource.samples.CustomerServiceResource")

Creating it directly in the configuration requires less xml configuration but offers limited flexibility. Another option is creating a separate bean that’s responsible for the endpoint and then referencing it within the endpoint configuration:

from("cxfrs:bean:rsServer")

The bean rsServer should be defined in the camel context. An example:

<cxf:rsServer id="rsServer" address="http://localhost:9090/route"
              serviceClass="com.fusesource.samples.CustomerServiceResource"/>

This approach allows you to decouple the endpoint configuration and allows to be quicker and less verbose in the endpoint configuration. Both options are shown in the sample code, although the first option is used.

That’s all the configuration required to expose the REST endpoint with Mediation Router. Fairly simple. The next step is to consume a file from the file system based on what comes in from the REST endpoint. The contents of the file will be returned to the client of the REST call. To do this, we use the camel-file component and enrich the Exchange with a pollEnrich call in the DSL:

.setHeader(Exchange.FILE_NAME, simple("test-${body}.xml"))
.pollEnrich("file:src/data?noop=true", 1000, new CustomerEnricher())

We cannot use any dynamic expressions in the pollEnrich call, so we set a header that the file component understands before we do the enrichment. In this case, the body of the REST message is an identifier that can be used to template the file-system resource.

Lastly, we can attach some additional processing to the route:

.process(new CustomerServiceProcessor())

The intent of the example, as described above, is to show how to configure the endpoint and attach it to further Mediation Router processing. Note, the Message Exchange Pattern (MEP) for the REST endpoint is InOut and expects a response. The example is not meant to be a complete end-to-end solution as that will vary depending on intended functionality. Please note above the links to Roy’s discussions on what REST is and is not.

If I have left something out, or you need more clarification around the example, drop me a comment and we can discuss.

 <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>build-helper-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>attach-artifacts</id>
            <phase>package</phase>
            <goals>
                <goal>attach-artifact</goal>
            </goals>
            <configuration>
                <artifacts>
                    <artifact>
                        <file>target/classes/features.xml</file>
                        <type>xml</type>
                        <classifier>features</classifier>
                    </artifact>
                </artifacts>
            </configuration>
        </execution>
    </executions>
</plugin>

If you would like to also filter/tokenize the artifacts before attaching them, add the following resource plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <executions>
        <execution>
            <id>filter</id>
            <phase>generate-resources</phase>
            <goals>
                <goal>resources</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Of course attending a conference like this and hanging out with and listening to some of the leaders in open-source integration software like James, Strachan Claus Ibsen, Jon Anstey, Rob Davies, and many others, is awesome, there’s another reason to attend. Being around people who are highly dedicated to the software craft and developing best-of-breed software really gets you excited and motivated. Seeing others excited and passionate about their projects is contagious. Looking at this year’s conference, the speaker list and sessions here are the ones that appeal to me and I hope to get the most from:

A Hundred Departments, Same Integration Solution

Overview: How integration and SOA fit in a broad enterprise architecture; techniques for adding APIs to and integrating with legacy systems; design patterns for building new enterprise systems with integration in mind; techniques and code for business process management (BPM) using Camel & ActiveMQ; and how the new paradigms are enabling us to work with external partners, lower the cost of software development, and offer new innovative services.

Next Generation Open Source Messaging with Apollo

Overview: Apache Apollo is built from the foundations of the Apache ActiveMQ project but with a radically different threading architecture which lets it scale to large number of concurrent connections and destinations while using a constant number of threads.

Replacing MQSeries with ActiveMQ in Large Scale Retailer

Overview: This session will discuss the development, deployment and lessons learned in a large scale retail implementation (1,000s of stores) where we are converting from IBM MQ Series to ActiveMQ and ServiceMix in a gradual manner

Using Apache Camel in ServiceMix

Overview: Jon Anstey (co-author Camel in Action) will show you the best practices for deploying Camel applications to ServiceMix. Since ServiceMix is built on top of Apache Karaf, most tips are applicable to that container as well.

Apache Camel in Action: Common Problems, Solutions and Best Practices

Overview: Advanced topics like transaction management in Camel (XA and non XA) and when you can live without it. This talk will give examples for how to start, stop, create, or modify Camel routes at runtime. It will also cover basic questions like “Java DSL vs. XML DSL”, “Exchange In-Message vs. Exchange Out-Message” or whether you should use one or multiple Camel contexts.

Apache Camel at a Top 3 Online Retailer

Overview: A Top 3 online retailer recently completed a live integration of their warehouse management and fulfillment systems with those of their parent company. The integration and cutover event was described as “open heart surgery on a moving train” by their CEO. This presentation will highlight how Apache Camel helped to make the integration possible, and how Camel is being leveraged at the online retailer today for a variety of integration solutions. Best practices, lessons learned, and insights based upon use cases from one of the world’s largest online retailers.

There are many others, so check out the complete list. You can use the following discount codes:

SpeakerFriend – $150 off registration
AMQAction -$100 off, and free ebook of ActiveMQ in Action
CamelAction – $100 off, and free ebook of Camel in Action

Hope to see you there!

I wanted to quickly point out something that I’ve noticed to be quite different for the open-source projects supported by FuseSource. Apache ActiveMQ, Camel, ServiceMix and CXF have documentation at their Apache sites that varies in terms of quality. But FuseSource has put together top-quality docs for each of the aforementioned projects focused on helping the reader quickly come up to speed and understand how to use the important features of a product. And it’s not just mickey-mouse examples either. They’ve put together examples gathered from years of experience consulting at various types of clients that focus on the intended way of using the product . When it comes to wanting to know how to use, for example ServiceMix, and the pitfalls to avoid and best practices to employ, having the FuseSource docs for ServiceMix (aka Fuse ESB) close at hand is a must.

Another thing that can frustrate developers is outdated documentation. You may find a page, even hosted at the project’s website, that explains a certain way to develop a solution, but when you try it yourself, it doesn’t work. You can spend hours trying to figure out what you did wrong only to find you’re actually not supposed to do it that way anymore. The FuseSource documentation solves that by organizing all of the documentation for a specific version. When you click on a doc set for a particular version, you can be sure that the features and examples covered are specific for that version and not just clobbered together with whatever else used to work and is outdated.

The docs at FuseSource are tailored to help you quickly coming up to speed and are focused on solving problems with the technology without the unnecessary fluff to get in your way. If you are using ActiveMQ, Camel, ServiceMix, or CXF, I highly recommend checking out the FuseSource docs. If you don’t use those products yet, consider that the documentation is an asset as you explore whether or not to use them.

I believe to be successful and well-rounded in the technology/software space, you have to change jobs every few years or so. Ultimately, as a software engineer, your job is to solve problems using technology. In most cases, a problem can be solved in many different ways, but not all solutions are created equal. The more problems and solutions you’ve seen and experienced, the more apt you are to solve the problem with a “better” or “elegant” solution. In my opinion, you have to experience how problems are solved in different groups, and different companies using different methods, different approaches, etc etc to really become proficient at problem solving and weigh the benefits and tradeoffs that come with a solution. Otherwise, the traditions and customs of a single company crush your mind from thinking “outside the box” or evaluate how similar problems have been solved in the past by similar companies.

Another part of the equation is ability to learn and your exposure to new technologies. Big companies offer the “this is the way we’ve always done it and we’re not going to change” mentality which is really a career killer for a software engineer. If you’re career goals involve trying to climb the corporate ladder, then by all means embrace the corporate mindset but if you want to stay in the technology space and excel, you will have to seek out opportunities to expose yourself to new technologies and problems..

I feel at this point in my career, I can’t settle for all the comforts of a cushy corporate job. I am still young enough and interested enough in technology to the point that I want to push myself. I want to get out and be exposed to new problems. I crave learning and the challenges of doing so. I honestly feel that if you’re not learning and not solving new problems and not thinking outside of the box you’re going to end up like those technology folks complaining about not having a job because the technology they cling to is slowly going away or drying up. I don’t want to end up complaining about something that I have control over right now. In the end, the technology industry is about problem solving, ability to learn, and pushing yourself to not get comfortable. Maybe I’m cynical in this respect, but the longer you stay at a big company, the more locked-in you get and the more dependent you become on that company (pension, retirement, tenure, job-security, whatever). The longer you stay, the less motivated you get to learn the new technologies that aren’t being used at your company. The longer you stay, you *think* you become critical to their operations, but before you know it the operations themselves are being phased out and your chances of being kept around are becoming slimmer and slimmer. I believe times have changed, and trying to stay at a corporate job in a company for 30 years is a career killer for a software engineer. I want my resume to be my job security, not the number of years I’ve had the corporate mentality beaten into me.

Who knows, though. My wife and I are expecting our first child in the next few weeks, and I know my priorities will shift big time. My focus will be on her and my family. Maybe I’ll do a 180 change of opinion about staying at a big company. But while I’m still motivated, I have to explore other options and opportunities that I know will solve all three of those items mentioned above: exposure to problem solving, learning, and staying hungry. So I continue my journey in the software craft by taking on the role of Principal Consultant at an open-source subscription company, FuseSource, who is the support company behind Apache Camel, ActiveMQ, ServiceMix, CXF, and a few others. I will be helping different companies use these open-source projects, facilitate proper design of their architecture, deliver training, and i’m sure much more. It seems to be a good balance of exposure to new problems, learning opportunities, and working with some of the smartest people in the open-source space which will drive me to stay hungry. Wish me luck!