In processing mode, 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.)
A standard Job is more convenient for graphical design and integration of mapping between sources and output. It does make sense to use tPrejob and tPostjob. They're usually used as ETL for batch and bulk data processing.
There is some cross over between DI & ESB. A DI Job can be used to process messages; e.g., MS (MicroSoft) and MOM (Message Oriented Middleware) queues; and can be exposed as a Data Service; e.g., tRESTClient, tRESTRequest, tRESTResponse. Similarly, an ESB Route can be used to transform data; e.g., cAggregate and cContentEnricher, cTalendJob, cMap. However, DI functionality is best leveraged for complex data transformations and ESB functionality is best leveraged for complex message distributions.
In processing mode, 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.)
A standard Job is more convenient for graphical design and integration of mapping between sources and output. It does make sense to use tPrejob and tPostjob. They're usually used as ETL for batch and bulk data processing.
There is some cross over between DI & ESB. A DI Job can be used to process messages; e.g., MS (MicroSoft) and MOM (Message Oriented Middleware) queues; and can be exposed as a Data Service; e.g., tRESTClient, tRESTRequest, tRESTResponse. Similarly, an ESB Route can be used to transform data; e.g., cAggregate and cContentEnricher, cTalendJob, cMap. However, DI functionality is best leveraged for complex data transformations and ESB functionality is best leveraged for complex message distributions.
