One Star

Intended usage of Mediation and Integration perspectives

I have been evaluating Talend Open Studio 5.0.2 for possible use in an integration project and have found it to be a useful and impressive tool. However, I am struggling a bit to understand what the guidelines are for building functionality with Routes (Camel) as opposed to Jobs, as there seems to be a lot of functional overlap between the items in the Mediation and Integration perspectives. For example, I have created an Integration Job that is functionally almost exactly the same as the Mediation Route created in this Talend demo:
Because of the overlap between the two sets of tools, I am finding it difficult to know where to start when planning to build functionality - Jobs or Routes. I also don't know what the pros and cons and implications are of using Jobs vs. Routes and vice versa. Can someone point me to a screencast or a section of the docs that I may have missed that clearly describes this information?

Re: Intended usage of Mediation and Integration perspectives

Jobs are primarily for data integration batch processing moving data from one data source to another. Routes are primarily for real-time, event driven, often transactional integration between service endpoints. So typically ESB routes endpoints that are always listening for new events. The route never stops running. In contrast, when you trigger a job it starts, runs, and then stops. (Of course, you can build jobs that have loops and other behavior that periodically poll which in essence acts as a listener).
Both Routes and Jobs can consume web services. Jobs can host web services as well, but the support for WS-* is stronger in routes and probably a bit more performant. Also, web services often entail rich xml schemas that are better handled in routes.
Both Jobs and Routes handle transactions against databases, but the Routes are better at handling transactions or integration patterns for guaranteed message delivery. For example 2pc between a JMS system and a RDBMS. Or just plain JMS transactions spanning both a receive and a send (very common use case).
Another major difference is that Routes are message centric and payload agnositc. This means that there is no schema enforced by the route on the payload message, and in fact the message can be a variety of types, e.g. string, file handle, pojo. In contrast, the connectors in Jobs are always strongly typed with a schema. Both approaches have pros and cons. The strongly typed schema works well with traditional rdbms schemas. It struggles with more hierarchical schemas and rich xml formats. The payload agnostic approach is more flexible and can handle both structured and unstructured payloads, but it lacks the self-documentation of the schema metadata.