DZone
Integration Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Integration Zone > Why Using Camel Was the Right Choice

Why Using Camel Was the Right Choice

It can take a bit of work to transform your mental model of a problem into the EIP domain, but when you do, the solution will be far easier to understand later on.

Matthew Casperson user avatar by
Matthew Casperson
·
Jan. 25, 17 · Integration Zone · Opinion
Like (1)
Save
Tweet
3.03K Views

Join the DZone community and get the full member experience.

Join For Free

Around a year ago, we made the decision to write a new API integration layer with Camel. No one on the project had a great deal of experience with Camel, but we completed and deployed the API and it has been running faithfully ever since.

The choice to use Camel was somewhat controversial. It took developers a little while to get accustomed to the DSL syntax, and there were many debates over exactly what the code should look like.

We eventually moved away from Camel for newer API projects, but I recently had to go back and update some of the Camel code. What I found looking at the code a year or so after it was written surprised me.

At the time, thinking in terms of Enterprise Integration Patterns (EIPs) was quite novel. Terms like multicast, recipientList, aggregate, and wireTap were often hard to appreciate, and harder still to incorporate into a process. We persevered, though, and for the most part, we managed to describe the transformation and integration of data with these patterns. It was sometimes frustrating to try and mold our thinking into these EIPs, and I suspect that in large part, this frustration was the reason why we didn’t embrace Camel for future projects.

However, I have to say that reading this code after enough time had passed for me to forget the details was refreshing.

Too often, code is dumped into classes in an imperative train of thought style that makes perfect sense when you are knee deep in a problem and just need to get something working. However, it is so painful to read later on because, without the mental context of the original developer (even if that developer was you), it takes hours to step through each line of code to determine the intent as well as the action.

For all the rough edges we encountered writing a Camel application, being forced to use the common language exposed by EIPs forces you to write much more declarative code. It can take a bit of work to transform your mental model of a problem into the EIP domain, but when you do, the solution will be far easier to understand later on.

I didn’t appreciate it at the time, but describing and implementing a solution with EIPs and the common language that they enforce had more than enough value to overcome the time it took to learn this style of coding. I’m a little disappointed that we discounted Camel for the short term frustrations it brought to our development cycle, but maybe you can learn from my mistakes.

Enterprise integration Mental model dev API application Data (computing)

Published at DZone with permission of Matthew Casperson, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Flask vs. Django: Which Python Framework to Choose?
  • Understand Source Code — Deep Into the Codebase, Locally and in Production
  • Pattern Matching for Switch
  • Datafaker: An Alternative to Using Production Data

Comments

Integration Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo