Generally I would like to avoid beans/processors/scripts and would rather solve things with solutions/constructs within Camel. Using the DSL and EIP avoids a lot of possible bugs. In my experience integrations bugs are often introduced in the custom code part.
That said now you can already call a Java bean from for example XML: <route> <from uri="direct:hello"/> <to uri="bean:bye"/></route> Also within the language there could be Java interoperability (especially when running on the JDK). Consider Kotlin which can call Java (or the other way around): 1. https://kotlinlang.org/docs/java-interop.html 2. https://kotlinlang.org/docs/java-to-kotlin-interop.html similar can be done with Groovy. Another possibility is using the Script EIP: https://camel.apache.org/components/3.16.x/eips/script-eip.html There could be construct to run other language like SQL, XSLT, Kotlin or Groovy directly. This turns the concept around. Instead of running Camel inside these languages, its running these languages inside Camel. Raymond On Sat, May 21, 2022 at 10:24 AM Vyacheslav Boyko <mail4...@gmail.com> wrote: > How do you think about the Camel now can invoke bean processing which > can be implemented in the "core" language (Java, Kotlin, Groove)? > How to deal with: > > from("...") > .bean(aBean, "aMethod") > > ? > > On 5/20/22 16:49, ski n wrote: > > Some Friday afternoon thoughts... on the Camel DSL and Camel Workflow. > The > > Camel DSL The Camel framework implements a lot of Enterprise Integration > > Patterns, Data Formats and Components. To make it easier to write > > integrations, the Camel DSL (Domain Specific Language) was invented. This > > DSL grew into several parts: - Routes - RoutesConfiguration - Templates - > > Endpoints - REST - Expressions (simple) There are currently several > syntax > > options available to write the DSL (xml, spring xml, yaml, Java, Groovy > and > > Kotlin). However to run these, you need to embed the DSL either in a > > runtime container (for example Karaf) or within code (for example Java). > > Could Camel be a language on its own? Now that the DSL is so extensive, I > > was wondering couldn't Camel be a programming language on its own? 1. By > > combining the DSL's into a consistent Language/Syntax. 2. Enhance the > > language, so developers can code all Camel tasks through the Camel > language > > (Context, Routes, Endpoints and so on). 3. Run the language directly on > JDK > > (converting it maybe first to Java?). Either one syntax could be used > (for > > example Kotlin) or several syntax options could co-exist next to each > > other. Every option could have their own extension: clj (camel language > > java) clx (camel language xml) clk (camel language kotlin) cly (camel > > language yaml) clg (camel language groovy) For example, creating a > project > > with only clk (or a mix with other syntax) > > > > A developer workflow In addition to the Camel language, I was thinking > > about its workflow. Especially in regard to REPL's, notebooks and > > serverless functions. What could a modern workflow in Camel look like? > > Example 1) Create a project in VSC or Jupyter (locally or in the cloud). > 2) > > Create a camel language file. 3) Program Camel in a text editor (with the > > help of Camel LSP) or graphically (with the help Karavan). 4) Test it a) > > locally with Jbang and push result into the cloud witht CamelK b) Test it > > directly in the cloud (CamelK) So no need to learn any other language > > beside Camel Language. Much like SQL XSLT or Gradle. So maybe no a > > full-blown programming language, but on a higher level than a DSL. Of > > course, it should be possible to extend the language through beans and > > other stuff. > > > > Is Camel a framework or a language? What are your thoughts on this topic? > > > > Raymond > > > -- > Vyacheslav Boyko > mailto:mail4...@gmail.com > >
