Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History


Agent pattern or Agent architecture


We want access to functionality or data offered by and application or database, but the application/database does not offer the endpoints we want and we do not want to modify the existing application/database. Typical inadequacies which can be addressed:

  • HTTP only, HTTPS not supported
  • Synchronous endpoints, but want asynchronous
  • No payload encryption

Incoming traffic is not possible or unwanted due to firewalls and routing policies.




Implement a standalone application, an agent, with integrates with the application or database you want to extend with new integration functionality. The agent will act as a communication proxy between the target application/database and the outside world.
The agent will initiate all communication, and all communication is HTTPS based. Firewalls must allow outgoing HTTPS traffic (port 443), but can block all incoming traffic.

The agent must have direct access to the endpoints offered by the legacy application and should be deployed on the same machine or at least on a machine as close to the target machine as possible.

The agent will typically poll an incoming queue for requests to process and publish any outgoing messages to another queue, but these endpoints might also be a REST endpoint or similar.

Resulting Context



Related Patterns

Proxy pattern

Known Uses


This pattern was (to my knowledge) first described by Thor Henning Hetland June 2015.

Documentation template from

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.