[Feat]: Decouple transport layer from the core logic, making it an interchangeable component.

[maeste]

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

This is attempted in #164
That PR cannot be merged because it violates the https://a2aproject.github.io/A2A/v0.2.5/specification/#31-transport-protocol requirement "A2A communication MUST occur over HTTP(S)."
I like anyway the idea to have a pluggable transport layer.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[Denovo1998]

@maeste
I'm curious why communication is restricted to only HTTP(S).
When the system becomes large, shouldn't the EDA architecture be the first choice?
I have looked at many projects, and there hasn't been any attempt in this regard.

[maeste]

@Denovo1998, there are many reasons to use HTTP(S) + SSE in this case. Very briefly, a few points are

• A2A aims to be truly distributed across multiple locations over the internet. HTTP is the best protocol to avoid any problems with firewalls and NAT. Using proprietary protocols, especially binary ones, on non-standard ports introduces various challenges in this area
  HTTP is a well-known standard that is well-supported in all languages. A2A aims to be polyglot or even language-agnostic.
• EDA is great for many reasons, but it also has some negatives. The main one for A2A is it needs to rely on a message broker. A2A instead aims to be fully peer-to-peer protocol with discovery capabilities (like Kubernetes is for pods). IOW HTTP/SSE is more distributed in terms of control, but more tightly coupled in logic. EDA brokers are more centralized in transport, but more decoupled in system design.

Does it mean that an EDA architecture with similar concepts of agents and agent cards does not make sense? Not at all, I think it could make sense and can be an extension to apply on top of A2A-core to be used in a specific case based on local network communication (no firewall) and it may have some advantages. But it cannot be part of the SDK because it's out of the scope of the standard defined by the spec.
So, from here, my proposal: decouple the transport to make it easy to plug different transports to A2A-core. The SDK will use only HTTP/SSE and maybe gRPC in the future, but anyone can build his own local network A2A system over Pulsar, Kafka, MQTT etc. It may also be valuable to have a gateway between different protocols to expose an agent or a set of agents implemented in EDA as standard HTTP agents.

DOes it make sense and does it answer your question?

[Denovo1998]

This discussion is very interesting, and what you said makes sense to me.
Let‘s start focussing on decouple the transport.