I am a developer that wants to create a webservice in order to feed a DataBase that will be the backend of an important software.
I could program this backend with .NET, JAVA or another language. However, we are thinking about using TALEND ESB. The question is simple, why Talend? I have my reasons for using this software but as it's gonna be an important project I want to have more feedback from other developers or Talend staff.
I've been developing commercial software for over 30 years (I did start young!) and these days work as a freelance data and systems integration consultant, mostly with financial, ERP and CRM systems, and lately pretty much exclusively using Talend.
What you realise as you gain experience, with things that go badly long term as well as those that go well, is that maintainability and documentation are often key to the overall success of a project, and this is where Talend can save you a lot of time.
I need to be able to create solutions which can be discussed with various colleagues working on a project, and often the end client. They will probably have very different roles, requirements and degrees of technical knowledge, and most aren't developers, e.g. BA and BI staff, COO, CFO. Having a well structured, well laid out diagram of the integration solution provides a nice middle ground for discussion, and it does look very cool projected on the big screen in a boardroom!
For this reason, I'd recommend using individual components with a specific purpose, rather than packing everything, complex expressions and all, into a tMap or one of the Java components, which as a developer you'll almost certainly be inclined to do. These individual components help create a job which visually conveys what you're doing at a high level, and you can then explain or drill into a component if more detail is required.
If you're an experienced developer, there's no denying that it can be quicker, and usually much more straightforward to implement basic integration jobs in code, and there are certainly times when this makes sense. However, a year later when you need to update the code, or if someone else picks it up, you'll quickly realise that unless you'd put the effort into creating good documentation, and stuck to the agreed coding standards (assuming they haven't changed) you or the new developer will waste a lot of time getting up to speed with everything. You'll almost certainly want to make changes to the code you wrote originally.
As a junior developer, you start out using all of the cool constructs and clever techniques your language/platform provides, because it's fun, exciting and you want to show off, however when you pick up and have to maintain someone else's code which has been written in this way, it can often be confusing, and you'll quickly come to appreciate code (often written by older developers) which is very clearly laid out and uses mostly core language constructs in an immediately obvious way. This will usually be easier to read, understand, and of course test.
Coding standards ideally based upon Best Practice are an absolute must, and you could consider components in the Talend palette to be a set of standards, for particular types of task.
There are still plenty of ways to implement your requirements, and your creativity isn't being beaten into submission too much here, but you'll naturally, and quickly find yourself doing things in a fairly standard "Talend way".
You don't have to worry about the low level stuff, and many of the cross platform considerations are taken care of, however if you absolutely must write some code, or need to interact with the system at a lower level, there are components which allow you to do this - tSystem, tJava etc. and you can even integrate .NET code into your jobs.
All of your knowledge/experience as a developer is still very important, and your database skills will be a big advantage. What you end up working on are "solutions" which are often much simpler because you can rely on heavily tested and widely used building blocks, which wrap all of the messy stuff. You still get to dig around in databases, come up with novel approaches for tricky edge cases, and occasionally save the day/company, but you're writing much less code, which should reduce the amount of debugging massively.
Always remember - aside from you, absolutely nobody cares how clever your solution is, they just want it to work, and continue to do so. If you can implement something quickly that does exactly what's required, even if the hardcore developer in you dies a little because you've used an enterprise tool like Talend, then that's what you should be aiming to do.
Depending on which version (paid/cloud or Community) you're using, there are team collaboration and version control features built into the tools.
The free Community edition is very capable, and ideal for getting started. It may even be all you need, but of course the paid for and cloud offerings include a lot of great additional functionality.
Set yourself a real world challenge, but try to keep it relatively focussed, and see how you get on implementing it in Talend.
There's plenty of good documentation, training material and of course this forum, if you need a hand.
It's probably also worth pointing out, that Talend is actually a code generator.
Each of the components is essentially a Java code template (or actually a set of three, similar to a tJavaFlex) and when the job is run, these templates are compiled, taking the properties, input and output schema, and producing valid Java code, which forms part of the overall source output.
You can write your own components easily enough, but there's rarely any need, and it's usually better (and recommended) to simply use a tJavaFlow component directly in your job for any necessary custom logic.
As a result, with a few clicks it's possible to build completely standalone Data Integration jobs which can be run independently of Studio, on any platform with Java installed, and without the need for a runtime/container.
This can be a massive win, as some other solutions can only run jobs within their own, sometimes platform specific, runtime environments. Of course, there are no such considerations when using Talend's commercial cloud based offerings.
One of the benefits this brings whilst developing, is that if you get an error in Studio, and it's not obvious what's causing it, you can just note the line number shown in the stack trace, and swap to the code view to see exactly where it's failing. As a developer you'll feel right at home, and will be able to see exactly what's going on "under the hood".