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

Name

Agent pattern or Agent architecture

Problem

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.

Context

Forces

Solution

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.

The agent may also run a web server and expose SOAP, REST or json-over-http endpoints.

Resulting Context

Examples

Rationale

Related Patterns

Proxy pattern

Known Uses

Credits

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

Documentation template from http://www.opengroup.org/public/arch/p4/patterns/patterns.htm

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