3 ms·

Not sure. Camel allows working with multiple transport technologies and normalizes them to a single API. It doesn't implement those multiple technologies. If i

Not sure. Camel allows working with multiple transport technologies and normalizes them to a single API. It doesn't implement those multiple technologies. If it doesn't solve the problems you have then it probably does seem complicated--but it solves a certain class of complicated problems reasonably well. Let's flip the question on its head: what should people use instead?

unclebucknasty 10y ago
Hmm. Seems like it does implement many transport technologies: HTTP, FTP, etc. It also seems to encourage processing of raw requests/responses via XSLT/XPath, etc. Anyway, I'm not familiar with alternatives like Mule, but visual tools do seem to be in order for complex integrations. But, I am not 100% sure that people "should use" anything, per se. The promise of RESTful interfaces, SOAP, and other integration approaches was to allow code/objects to be used and semantics imposed per domain/use case, not to treat them as declarative, agnostic data exchanges. So, I'm not sure why we need much more than good old coded logic and transport libraries when it's time to hit the wire. But, this mish-mash of declarative routing XMLs, DSLs, etc. just feels hacky. Instead of just writing the integrations in code, I now have this added layer to manage. And, I don't know what I'm getting for it in return.
- davelnewton 10y ago
  The transport technologies already exist; Camel unifies them under a single API. What you get in return is precisely not having to manage all of them in your own code. Simplistic problems don't demand complex solutions. Complex problems do. If you're not doing anything complex enough to require a complex solution, then of course you wouldn't need something like Camel or any other ESB-like solution. ¯\(°_o)/¯
  - unclebucknasty 10y ago
    Sure. I'm saying that Camel doesn't seem to provide what's advertised for those complex cases. Instead, it adds a layer of obfuscation and more constructs to manage to what could otherwise be clean code. I think we just disagree on that point, as I apparently do with everyone regarding Camel. But, I don't fret. I also thought J2EE was completely nuts when everyone still believed it was the new sliced bread. :)

unclebucknasty 10y ago

Hmm. Seems like it does implement many transport technologies: HTTP, FTP, etc. It also seems to encourage processing of raw requests/responses via XSLT/XPath, etc. Anyway, I'm not familiar with alternatives like Mule, but visual tools do seem to be in order for complex integrations. But, I am not 100% sure that people "should use" anything, per se. The promise of RESTful interfaces, SOAP, and other integration approaches was to allow code/objects to be used and semantics imposed per domain/use case, not to treat them as declarative, agnostic data exchanges. So, I'm not sure why we need much more than good old coded logic and transport libraries when it's time to hit the wire. But, this mish-mash of declarative routing XMLs, DSLs, etc. just feels hacky. Instead of just writing the integrations in code, I now have this added layer to manage. And, I don't know what I'm getting for it in return.

davelnewton 10y ago
The transport technologies already exist; Camel unifies them under a single API. What you get in return is precisely not having to manage all of them in your own code. Simplistic problems don't demand complex solutions. Complex problems do. If you're not doing anything complex enough to require a complex solution, then of course you wouldn't need something like Camel or any other ESB-like solution. ¯\(°_o)/¯
- unclebucknasty 10y ago
  Sure. I'm saying that Camel doesn't seem to provide what's advertised for those complex cases. Instead, it adds a layer of obfuscation and more constructs to manage to what could otherwise be clean code. I think we just disagree on that point, as I apparently do with everyone regarding Camel. But, I don't fret. I also thought J2EE was completely nuts when everyone still believed it was the new sliced bread. :)