[jira] [Work started] (CAMEL-24741) camel-opa - add an in-process WASM evaluation mode alongside the REST client

["Andrea Cosentino (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-24741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CAMEL-24741 started by Andrea Cosentino.
------------------------------------------------
> camel-opa - add an in-process WASM evaluation mode alongside the REST client
> ----------------------------------------------------------------------------
>
>                 Key: CAMEL-24741
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24741
>             Project: Camel
>          Issue Type: New Feature
>            Reporter: Andrea Cosentino
>            Assignee: Andrea Cosentino
>            Priority: Major
>
> h2. Background
> {{camel-opa}} evaluates policies by calling a running OPA server over its REST Data API ({{com.styra:opa}}). That is the mainstream OPA deployment - a sidecar next to the application - but it is not the only one, and it costs a blocking network round-trip per exchange.
> OPA can compile Rego to WebAssembly ({{opa build -t wasm -e <entrypoint>}}), and {{com.styra.opa:opa-java-wasm}} evaluates such a bundle in-process. The component documentation currently records this as deliberately deferred because the artifact was at 0.0.6; that is no longer true:
> * {{com.styra.opa:opa-java-wasm}} *1.1.0* (2026-06), Apache-2.0, on Maven Central
> * the runtime is {{run.endive:runtime}} - {{bytecodealliance/endive}}, *pure Java*, no native libraries and no platform classifiers, so there is no ppc64le/s390x portability problem
> * {{opa build -t wasm}} is supported by the {{openpolicyagent/opa:1.9.0-static}} image the component already uses for its integration tests
> h2. Proposal
> Add WASM as a *second* evaluation mode rather than replacing the REST client. The two are complementary:
> || || REST / sidecar || WASM in-process ||
> | policy source | live server, centrally managed | compiled bundle shipped with the app |
> | policy updates | bundle polling, live | redeploy or reload |
> | decision logs | yes | none |
> | latency | network round-trip | in-process |
> | unreachable PDP | a real failure mode | cannot happen |
> Removing the REST path would lose decision logging, bundle distribution and central policy management, which is why this is additive.
> h3. Shape
> * {{evaluationMode}} (or inferred from a {{policyBundle}} being set): {{rest}} (default, today's behaviour) or {{wasm}}
> * {{policyBundle}} - the compiled {{.wasm}}, resolvable from file, classpath or URL
> * {{entrypoint}} - the compiled entrypoint name; note this is *not* the same thing as {{policyPath}}, which is a data path. An entrypoint is fixed at {{opa build -e}} time.
> * An {{OpaWasmEvaluator}} satisfying the same internal contract as {{OpaPolicyEvaluator}}, so the producer, {{OpaSecurityPolicy}} and the decision headers are unchanged.
> h3. Thread safety is not optional here
> {{OpaPolicy}} is *not* thread-safe: it carries mutable input/data and a package-private {{reset()}}, and the library ships {{OpaPolicyPool}} with {{borrow()}} / {{Loan}} for exactly this reason. A Camel producer is invoked concurrently, so a single shared {{OpaPolicy}} instance would be a correctness bug under load rather than a performance question. The pool must be used, and its size becomes an option ({{poolSize}}, defaulting to something derived from the context or a small constant).
> h3. Result shape differs
> {{OpaPolicy.evaluate()}} returns a JSON *string*, and the WASM ABI wraps results in an array. The existing {{allowKey}} / {{isAllowed}} handling has to unwrap that consistently so a policy behaves identically in both modes - a route must not have to know which engine evaluated it.
> h3. Options that stop applying
> {{serverUrl}}, {{bearerToken}} and {{failOpen}} are meaningless in WASM mode, as are the health checks from CAMEL-24644 and CAMEL-24736 - there is no server to probe. They must be rejected or ignored explicitly with a clear message rather than silently doing nothing, since silently ignoring {{failOpen}} would be a security surprise.
> h2. Scope
> {{main}} only. Additive; {{rest}} stays the default so existing routes are unaffected.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)