Job Design VS Routes

Eight Stars

Job Design VS Routes

I have been using TOS_DI for the longest time. When I wanted to spin off a quick service, I saw TOS ESB, and saw the familiar DI perspective. I put in tRestRequest/ tRestResponse components and bam, my service was up and running.

I see that one can setup REST services using ROUTES also.

 

  • Is there any benefit to use the Routes over the Job Design ?
  • How easily can one migrate the existing code created using "Job designs" to "Routes"?
  • Any good use-case to use "job design" vs "routes"?

I am just trying to see if Routes can add any value to my current setup and learn more.

I could not find much documentation to answer above questions.

Any help is appreciated. Thank you

Eight Stars

Re: Job Design VS Routes

@plumberg :: As plumberg asked, I also want to know difference between Routes and data services.

 

Can anyone explain it with an example. 

Seven Stars

Re: Job Design VS Routes

You can reuse your job in a route with cTalendJob component.

 

Routes are based on Enterprise Integration Patterns, you take benefits of the numerous camel parameters and connectivity, you can route to several recipients, add conditions, filtering, gather several data sources, developp in java with its librairies to do almost everything you want.

 

Jobs are more convenient for graphical design and integrationf of mapping between sources and output. They're usually used as ETL for batch and bulk data processing, routes a usually used for real-time transfer of smaller data sets.

Eight Stars

Re: Job Design VS Routes

@leko: Thank you for the insight.

Are there any specific things which routes handle better than jobs and the other way around? As I said earlier, all my code is currently written using jobs and I would like to learn if routes scalability/ security or something else which may be lacking at the jobs
Seven Stars

Re: Job Design VS Routes

you get benefits of all the EIPs. For routing, duplicating messages, scalability with ActiveMQ to transmit data between several routes (thus you can stop any one, the others will continue working, and MQ stores the messages, then the stopped route restarts and everything is OK with no human action. Very usefull).

You can also encode data for security reasons if you need.

Eight Stars

Re: Job Design VS Routes

@Loko:
Awesome. I feel Routes may be a good in the long run. I have started reading about Camel/ routes. Looks simple, but is very vast. I have posted a question separately if someone can help with an example which will allow me to address a standard flow of a rest service, connecting to db, retrieving data and sending it back.