So, I went to this conference.

To some folks I know, the mention of the word “enterprise” causes them to immediately imagine stodgy old farts talking about how awesome CORBA was, along with “solutions” that involve using huge proprietary software packages that cost a small fortune. Also, those same people dismiss Java as “that thing that may have once been cool in the 90s, but is so done now”.

Enterprise software need not be expensive as purchasing a small island, nor boring as all hell. In fact, one of the things about this conference is that it has made me terribly excited about doing things that really amount to being the trench warfare and/or plumbing of software development. There’s nothing glamorous about either of those analogies, but at the end of the day, that’s what companies of all sizes face: integrating less-than-ideal systems, automating them, managing them, all in the name of getting things done. Oh, and getting paid.

Apache Camel and its growing constellation of sister projects ActiveMQ¹, CXF, and ServiceMix are awesome open-source projects written and maintained by smart, passionate folks. Those packages—especially Camel—allow you to do some pretty incredible integration tasks with less code, allowing you to spend more time writing code that actually matters to your company (i.e. the stuff that makes you money, or saves the world, or both).

Do you work for a company whose customers drop their requests onto a server using (gasp!) FTP? Oh, and did I mention that those customers might use slightly less than ideal data formats, like, say, a pipe-delimited monstrosity? Oh, and some customers might use different fields in that aforementioned monstrosity to mean different things?² If so, you should really look into Camel.

It gets better. If you manage to -browbeat- persuade some customers to join the modern era and use a web service with well-formed XML to give you requests, you can add that on without having to switch your old customers over or throw away code.

Best of all, you can do much of this without writing much code at all. A Camel route to achieve this using the Java Fluent API reads almost like plain English:

    // Handle archaic crap
    from("ftp://ftp.electronecromegastompers.com/dropbox/")
        .choice()
            .when(header("CamelFileName").startsWith("CustomerA"))
                .to("bean:normalizeCustomerData?method=handleCustomerA")
                .to("direct:handleNormalizedData")
            .when(header("CamelFileName").startsWith("CustomerB"))
                .to("bean:normalizeCustomerData?method=handleCustomerB")
                .to("direct:handleNormalizedData")
        .end();

    // Handle modern stuff; customer's identity is part of the request
    // rather than encoded in the file name.
    from("jetty://0.0.0.0:16666/spankyNewWebservice/")
        .to("bean:normalizeCustomerData?method=handleWebserviceRequest")
        .to("direct:handleNormalizedData");

    // The route that everything funnels into
    from("direct:handleNormalizedData")
        .to("bean:processNormalizedRequests")
        .to("bean:getPaidCashMoney");

Of course, I’m assuming that you have already written a bean that can handle a common data format, a bean to get various data into that format, and of course, a bean that makes you cash money³. Even so, this beats the pants out of using shell scripts and cron any day⁴.

Oh, did I mention that you can write routes like this using the hipster-compliant Scala, if you so desired?

tl;dr: the company I work for is using this stuff for real production work, and it’s great. The developers who work on these Apache projects are universally smart, approachable people, and I got to meet several of them at the conference, as well as Gregor Hophe, who wrote the book that inspired Apache Camel. FuseSource, the company that rewards a lot of these guys with paycheck for their hard work seem like good eggs, too.

I’m hoping to come back next year.

¹ Apache Camel was initially concieved as a mediation or routing engine to be embedded directly into an ActiveMQ broker.

² The real world is very, very ugly. It’s not all federated APIs, JSON, and ponies.

³ If you have ideas on how to do this, let me know.

⁴ Which is not to say that Taco Bell Programming is without merit.