Subscriber + Publisher Agent - How It Works

There are several components and implementation practices that make up the Trusted Agent Model. Each work together to provide the functionality of the integration solution. Each enterprise solution has a companion subscriber + publisher agent. The agents talk to each other over the message bus, sharing information of interest.

Enterprise Solution (Solution)

Any software solution that exposes some kind of application programming interface “API” could be considered and enterprise solution and would qualify for this pattern. As this pattern is new, no existing market available solutions directly implement a Subscriber + Publisher Agent. So, until they do SPA’s will need to be implemented by third party vendors and would need specific knowledge of an enterprise solutions API to perform the publisher / subscriber functions.

Message Bus (Domain)

Each independent agent can communicate with one or message buses to publish its messages and receive other agent’s messages they are interested in. Each instance of a message bus is considered a “Domain” that contains a set of “Topics” that any authorized agent can subscribe to. A domain could be private and only accessible to agents from a single organization, or it could be more permissive and allow two or more organizations the ability to share messages business-to-business.

Any durable service bus technology could provide the zero-trust message bus as long as the agents wanting to work with a domain have the ability to create subscriptions and publish to topics in that implementation.

Part of the configuration of any agent is the identification of its domain or domains of interest and what topics it would like to register subscriptions for. The agent just needs to have connection information and authorization to create subscriptions in the domain / topic. Using modern message bus services like Azure Service Bus, agents can be allowed permission at a granular level to all or some of the domain’s topics.

Subscriber + Publisher Agent (SPA)

Each SPA has two primary functions:

  • Publish changes in its solution record’s of information

  • Process receive messages from other SPA’s

Publisher of Change Messages

Each agent is configured to detect changes in solution records of information. Not all information is considered, but only facts identified by the business user is evaluated for change. When a change in the record state is detected only the defined data is emitted to the domain. This reduces the volume of and surface area of the integrations to only the most important data.

When sending a message to the domain, it should conform to a few basic conventions to ensure other agents can reliably accept and process the messages.

Messages should follow these conventions:

• Message subject should be in the pattern of “{Business Object Name}.{Solution Well Know Name}” Where “Business Object Name” should be distinct in the solution and the “Solution Well Known Name” should be unique in the messaging domain.

• The message type should be “application/json” While other types could be supported, this has become the most universal standard.

• The “messageid” should be a guid value.

• The message should have a user-defined property called “origincode” that identifies the source solution.

• Optionally the message could include a user-defined property “agentid” that identifies the source agent.

• If the agent is encrypting the message body, the the message should have a user-defined property “signature” that has a hash signature of the message including the un-encrypted body. The receiving agent will use this to validate the message authenticity.

Receiver of Change Messages

Agents are configured to listen for messages on the domain by creating one or more subscriptions to topics of interest. They are trained to look for messages of interest by the subject of the messages and schema of the message body. This involves mapping samples of messages or published schema definitions to the enterprise records of information and encoding the business rules used for adding new records, updating existing or deleted based on the content of the message. Messages received that do not conform to the agents’ requirements are discarded. If the message is acceptable, the agent will use its configuration to update its records of information.

The agent is responsible for maintaining its subscriptions state. It is responsible for pulling all messages either discarding it, completing it, or sending it the dead-letter queue if not able to process. It should also delete the subscription when no longer required.

Agent Security

The business user gives authorization to the agent via the enterprise solutions native security model so it only has access to information and the ability to update records that the business user allows.

Agents authenticate to one or more domains by holding connection information including authentication keys for each domain. Agents can store secrets locally or optionally utilize Microsoft’s Azure Key Vault.

Message Security

Each agent can provide end-to-end encryption of messages for other trusted agents. Agents broadcast their identity to other agents on the backplane topic. Each can elect to trust another agent by replying to a trust enquire with the other agent’s trust code. The code is communicated from one agent to another out of band. Once an agent trusts another, they exchange each’s symmetric encryption key to allow for the encryption / signing and decryption of each other’s messages.

When a new agent is initialized for the first time, a unique public / private key pair is generated for that specific instance of the agent. This is used to uniquely identify the agent and to allow for the exchange of key information.