[Architecture Review][P0] Single protocol path (HTTP + CloudEvents) and ingress/egress adapters

[qqeasonchen]

Execution meta — see plan: #5296

• Phase: 4 — boundary decoupling
• Severity: P0
• Depends on: [Architecture Review][P0] Partition eventmesh-common into internal packages #5298
• Blocks: [Architecture Review][P1] Standardize Storage SPI capabilities + TCK #5303, [Architecture Review][P1] Unified multi-tenant / security / quota entrypoint #5304

Problem

The boundary between the Runtime, protocol adapters, and legacy protocols is unclear. The README describes HTTP + CloudEvents as the main path, but the Runtime still directly depends on CloudEvents, MeshMessage, and A2A protocol implementations; the SDK still carries multiple historical paths (HTTP, Netty, gRPC, OpenMessaging).

Risks

• New users cannot tell whether to use HTTP/CloudEvents, TCP, gRPC, or the A2A Gateway.
• New features risk being re-implemented in the legacy SDK or across several protocol paths.
• Protocol plugins cannot act as truly replaceable adapters.

Proposed direction

• Declare HTTP + CloudEvents as the single primary path.
• The Runtime internally handles only EventMeshFrame.
• CloudEvents, MeshMessage, A2A, TCP, and gRPC all become ingress/egress adapters.
• Organize the Java SDK by internal packages instead of new modules — the module count is already too high:

org.apache.eventmesh.sdk.core       the primary HTTP + CloudEvents client
org.apache.eventmesh.sdk.streaming  streaming-oriented helpers
org.apache.eventmesh.sdk.a2a        A2A client support
org.apache.eventmesh.sdk.legacy     TCP / gRPC / OpenMessaging (existing users only)

A physical SDK module split is a follow-up only — do it only if the legacy paths must ship as a separate artifact so core users stop pulling Netty / gRPC / OpenMessaging transitively.

Acceptance criteria

• Runtime code paths (UniIngressService and below) reference only EventMeshFrame, never a protocol-specific envelope type.
• Each non-primary protocol has an explicit ingress/egress adapter (package-level is acceptable).
• The core SDK package has no Netty / gRPC / OpenMessaging dependency.
• Documentation marks each protocol path as primary / beta / legacy.

---

Part of the Architecture Review.