You are not logged in.

Unanswered posts



Important! This site has been replaced. All content here is read-only. Please visit our brand-new community at https://community.talend.com/. We look forward to hearing from you there!



#1 2017-02-22 17:50:06

plumberg
Member
115 posts

plumberg said:

When to use which perspective?

Is there any benefit to code a RESTful web-service by creating a "Talend job" vs writing a web-service through "Routes"?
When should we use either? Currently, my services are written through the Talend Job using tRestRequest/ tRestResponse and it works fine.
Any pointers are appreciated.
Thank you

Offline

#2 2017-03-10 03:31:27

xdshi
Talend Team


xdshi said:

Re: When to use which perspective?

Hi,
In the Talend open studio, you have two perspectives (and options to build web services) - use Talend Jobs or use Mediation routes (actualy these are Camel routes). 
Please take a look at this related forum:https://www.talendforge.org/forum/viewt … p?id=23122
Best regards
Sabrina


What we can do is to make sure that Talend will be your best choice!

Offline

#3 2017-03-18 01:57:48

archenroot
Member
237 posts

archenroot said:

Re: When to use which perspective?

Actually both ways Talend Jobs/Services and Routes will do the job for you, but from different perspective. Integration and Mediation views overlap a lot in Talend.
Usually you can define synchronous and asynchronous designs in general. When you get to lower level of design after application common SOA and microservices principles with small service, where:
- some need to be accessed from external world (some call these API implemented in REST way, or Proxy services) and these are usually using HTTP protocol as defacto standard (either going with REST with JSON/XML or SOAP with XML). These are also usually sync request/response or request/acknowledgement with async delayed response (this async response is then processed by second type of services, see below)
- some need will be hidden, these are backend services and they can expose also HTTP endpoint, but when you do ESB for long time you realize that the better way is to incorporate some message broker as event/notification/command message bus which these "hidden from world" backend/business services will use for intercommunication process.
If you go with message driven middleware (but maybe you don't need to in your case), you will end up in Camel Routes (Talend Mediation View) and use it heavily for business/backend services anyway, these services will usually only communicate via queue to receive and post data. But why using different perspective for standard basic CRUD or services used for external process orchestration? Well, you can do this with Camel as well and you will soon forget about Talend integration perspective :-)
Look here: http://blog.nanthrax.net/2015/08/talend … rspective/
I actually now use Talend inttegration really only for pure long-running tasks (anything more than 5 seconds processing to few hours) and also deploy it out of Karaf, as soon as these heavy tasks are specific for resource (cpu,memory,io) allocation, so I run them on completely different hosts.
I have done such architecture many times on multiple integration systems by Oracle and IBM, and I am now again applying it to Talend as common practice -> Mediation is the powerful core for you if you have complex service layer.


Emperor wants to control outer space Yoda wants to explore inner space that's the fundamental difference between good and bad sides of the Force

Offline

Board footer

Talend Contributor Agreement - Talend Website Privacy Policy