Question: IntentEvent has no targetApp property

[Roaders]

Question Area

• App Directory
• API
• Context Data
• Intents
• Use Cases
• Other

Question

There is no targetApp (or equivalent but better named property) on the IntentEventPayload. There is an originatingApp optional property but nothing that the routing logic or the receiving agent can use to determine where the message should be sent or to validate that the message is in fact intended for this agent.

We are implementing a smart routing solution as the main mechanism for managing messages in our implementation but we also want to support dumb routing where every agent and proxy gets every message and the proxy then decides if if should respond to the message. With no targetApp this is not possible.

[Roaders]

This also applies to ChannelChangedEvent and to a lesser extend BroadcastEvent (broadcast even can be sent to many agents, the other events I think would only be sent to one app).

[kriswest]

As discussed in another thread, the protocol and the FDC3 API itself are not really designed for an open bus that 'agents' in multiple apps pull things from when they are addressed to them. FDC3's design is based on the concept of a single Desktop Agent which acts as a broker or router for messaging between apps, each of which has an API endpoint to communicate with the agent.

We've then extended that conceptual framework in FDC3 2.1 with Desktop Agent Bridging to enable multiple agents to communicate with each other, allowing the apps in each of their scopes to talk to each other - in that situation we've again got a router or broker in the 'bridge' which decides who to forward requests and responses on to. Router can be dumber, but not quite dumb.

Having been involved in container implementations with a lot of messaging, I tend to assume everyone getting every message is a bad idea. It generates resource usage in unneccessary places and what you lose in spending resources on routing, you gain back many times in efficiency, particularly as the number of interoperating apps increases (or indeed as the rate that they send messages increases). Further, message routing is easier (or in fact possible!) to secure, which was a key consideration we had when designing a solution.

[kriswest]

Hence, I will close this issue for now (reopen if anything didn't make sense) as we shouldn't add routing fields to the communication protocol messages, which need to be routed by the Desktop Agent itself as introduced in the overview of the API standard:

A Desktop Agent ... serves as a ... message router (broker) for applications in its domain