[
https://issues.apache.org/jira/browse/CAMEL-23613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18083520#comment-18083520
]
Raymond edited comment on CAMEL-23613 at 5/26/26 2:34 PM:
----------------------------------------------------------
An important topic, and I applaud the efforts.
Here some of my thoughts:
Apache Camel originally started as a developer-focused framework. Primarily
used by Java developers. Its versatility however made it excellent to use by
integration specialists (XML/YAML DSL), in (low-code) tools, and now the same
applies for AI Agents. It must be said that much has been done in the last
years to facilitate this.
Nevertheless, the developer gap you mentioned in the post on Zulip is very
real. I first encountered it when developing the Assimbly
[Runtime|https://github.com/assimbly/runtime] and
[Gateway|https://github.com/assimbly/gateway]. This runtime is used standalone,
but also for example in the iPaaS [Fluxygen|https://fluxygen.com/]. As I need
to support various frontends (in for example Angular and React) I needed a
strict contract. Here were some of my initial design reasoning:
1. I draw inspiration from ElasticSearch that is built on top of Lucene. Lucene
is an excellent Java Search framework/library, but it has no easy way to manage
it. ElasticSearch in core just built a REST API around Lucene.
2. I divided my work in two API layers. One is the Java API layer (with an
implementation for Apache Camel). I used for this [How To Design A Good API and
Why it Matters|https://www.youtube.com/watch?v=aAb7hSCtvGw] which is a Google
Tech talk of almost 20 years old, but still have a lot of valid points. For the
second layer I created a REST OpenAPI layer.
3. As base formats I used XML, YAML and JSON, where JSON mostly used in
machine-to-machine traffic. Personally I find XML or YAML more human-readable,
but JSON is more compact and better supported. I am a supporter of
[JSON5|https://json5.org/] (aka JSON for humans).
4. The most important thing is of course the data model. For this I developed
[DIL (Data Integration
Language)|https://raymondmeester.medium.com/data-integration-language-ada578784efa].
I put a lot of my thoughts behind the language in some blog post a few years
ago, but the basic idea is that it's both readable for computers and humans,
with a formalization in a schema. DIL is more focused on design-time (on top of
route template/kamelets), but maybe it can be used as inspiration.
I think you've already covered the main guiding principles above:
1. API-Driven
2. Protocol-based
3. Local-first
I would add some more:
*1. Runtime independent*
Be as runtime independent as possible, thus not specific things for main,
Jbang, Spring or Quarkus. Even to some degree independent of Java if it's need
to be called from external tools. Of course there is no other framework that
can communicate with external protocols than Camel, so it makes sense to
utilize the framework for it.
*2. Embeddable*
I am personally not a huge fan of LSP, or any "server" implementation that
needs to be run outside the CamelContext. I would like to embed it within
Assimbly or any other Camel runtime.
*3. Modular*
You are mentioning runtime information/operation. I think it's good to first
focus on a specific area to implement with a narrow scope. However, this is
something that probably people will ask for extension. So it's good to make
some core, with modular extensions. Such as design-time (developing routes) or
config-time (Context configuration). Last one I
[discussed|https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Uniform.20central.20configuration.3F]
a while ago on Zulip.
*4. Conceptual*
Either you need to be conceptual (naming) as close as possible to Camel, or
make a strict distinction. Something in between will not work.
I think to have more feedback from the community, probably one or two
prototypes are needed to be guided by blog posts, and (code) examples. This is
in practice they only way that most people get a feeling for it, and is now
with AI relatively good to do.
Thanks looking forward to this effort!
h1.
was (Author: skin27):
An important topic, and I applaud the efforts.
Here some of my thoughts:
Apache Camel originally started as a developer-focused framework. Primarily
used by Java developers. Its versatility however made it excellent to use by
integration specialist (XML/YAML DSL), in (low-code) tools, and now the same
applies for AI Agents. It must be said that much has been done in the last
years to facilitate this.
Nevertheless, the developer gap you mentioned in the post on Zulip is very
real. I first encountered it when developing the Assimbly
[Runtime|https://github.com/assimbly/runtime] and
[Gateway|https://github.com/assimbly/gateway]. This runtime is used standalone,
but also for example in the iPaaS [Fluxygen|https://fluxygen.com/]. As I need
to support various frontends (in for example Angular and React) I needed a
strict contract. Here were some of my initial design reasoning:
1. I draw inspiration from ElasticSearch that is built on top of Lucene. Lucene
is an excellent Java Search framework/library, but it has no easy way to manage
it. ElasticSearch in core just built a REST API around Lucene.
2. I divided my work in two API layers. One is the Java API layer (with an
implementation for Apache Camel). I used for this [How To Design A Good API and
Why it Matters|https://www.youtube.com/watch?v=aAb7hSCtvGw] which is a Google
Tech talk of almost 20 years old, but still have a lot of valid points. For the
second layer I created a REST OpenAPI layer.
3. As base formats I used XML, YAML and JSON, where JSON mostly used in
machine-to-machine traffic. Personally I find XML or YAML more human-readable,
but JSON is more compact and better supported. I am a supporter of
[JSON5|https://json5.org/] (aka JSON for humans).
4. The most important thing is of course the data model. For this I developed
[DIL (Data Integration
Language)|https://raymondmeester.medium.com/data-integration-language-ada578784efa].
I put a lot of my thoughts behind the language in some blog post a few years
ago, but the basic idea is that it's both readable for computers and humans,
with a formalization in a schema. DIL is more focused on design-time (on top of
route template/kamelets), but maybe it can be used as inspiration.
I think you've already covered the main guiding principles above:
1. API-Driven
2. Protocol-based
3. Local-first
I would add some more:
*1. Runtime independent*
Be as runtime independent as possible, thus not specific things for main,
Spring or Quarkus. Even to some degree independent of Java if it's need to be
called from external tools. Of course there is no other framework that can
communicate with external protocols than Camel, so it makes sense to utilize
the framework for it.
*2. Embeddable*
I am personally not a huge fan of LSP, or any "server" implementation that
needs to be run outside the CamelContext. I would like to embed it within
Assimbly or any other Camel runtime.
*3. Modular*
You are mentioning runtime information/operation. I think it's good to first
focus on a specific area to implement with a narrow scope. However, this is
something that probably people will ask for extension. So it's good to make
some core, with modular extensions. Such as design-time (developing routes) or
config-time (Context configuration). Last one I
[discussed|https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Uniform.20central.20configuration.3F]
a while ago on Zulip.
*4. Conceptual*
Either you need to be conceptual (naming) as close as possible to Camel, or
make a strict distinction. Something in between will not work.
I think to have more feedback from the community, probably one or two
prototypes are needed to be guided by blog posts, and (code) examples. This is
in practice they only way that most people get a feeling for it, and is now
with AI relatively good to do.
Thanks looking forward to this effort!
h1.
> Explore a shared contract for Camel runtime to enable AI agent and human
> collaboration
> --------------------------------------------------------------------------------------
>
> Key: CAMEL-23613
> URL: https://issues.apache.org/jira/browse/CAMEL-23613
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Affects Versions: 4.x
> Reporter: Otavio Rodolfo Piske
> Priority: Major
> Fix For: 4.x
>
>
> During our AI working group discussion, we identified a gap in the developer
> experience:
> *Context:*
> * Humans and AI agents currently lack a shared, structured view of a running
> Camel application.
> * Humans rely on visual tools (Karavan, Kaoto, TUI, dev consoles), while
> agents interact through logs, MCP tools, and file system changes — but these
> views are disconnected. As integration development shifts toward AI-assisted
> workflows (prompt-first, with visual tools as a display layer), we need a
> common contract that both humans and agents can consume to understand the
> state of a Camel application at design time and runtime.
> *Proposal:*
> # Design a contract (set of APIs / protocol) that exposes Camel runtime
> state: route topology, endpoint inventory, message flow metrics, error
> states, REST/OpenAPI specs, and dev console information.
> # Evaluate the [Agent-Client
> Protocol|https://agentclientprotocol.com/get-started/introduction] as a
> potential standard for agent-IDE/tool communication, rather than inventing a
> custom protocol.
> # Revisit the existing Camel LSP work to assess whether it can be
> improved/extended (with AI assistance) to provide protocol-level integration
> and editing capabilities.
> # Coordinate with the community to ensure this contract becomes the de-facto
> way of consuming Camel runtime information
> {*}Goals{*}:
> * Enable a faster feedback loop where a developer can prompt an agent, the
> agent modifies a route, a running Camel instance hot-reloads it, and both
> human and agent can verify the result through the same interface.
> * Provide a consistent experience across the SDLC — the same contract serves
> design-time visualization, local development, and production observability.
> * Start with local-first (single laptop, no cloud dependency) to validate
> the approach and build field confidence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
