Integration Pattern Provider Lens Notes
Goal
The chapter has kept communication meaning, workflow reliability, partner boundaries, security, audit, and operations provider-neutral. This provider lens translates those responsibilities into Azure examples.
Future AWS or GCP lenses should be added only after official provider documentation is checked.
The durable idea is:
Provider integration services should implement communication meaning, reliability, and ownership requirements.
The Short Version
The weak provider question is:
Which integration service should we standardize on?
The better provider question is:
What does this communication path mean, and which service implements that responsibility?
Azure has API, messaging, event routing, streaming, workflow, identity, secrets, and observability services. They are strongest when each one is mapped to a clear integration responsibility.
Azure Responsibility Map
| Pattern Responsibility | Azure Implementation Lens | Design Note |
|---|---|---|
| API mediation | Azure API Management | Gateway, policies, routing, security, throttling, caching, developer portal, products, and observability for APIs. |
| Durable commands and business messages | Azure Service Bus | Queues, topics, subscriptions, dead-letter queues, sessions, duplicate detection, and reliable work transfer. |
| Event notification and routing | Azure Event Grid | Publish-subscribe event distribution with push and pull delivery, filtering, custom events, system events, and partner events. |
| High-volume streams | Azure Event Hubs | Fully managed event streaming for high-throughput ingestion, partitions, consumer groups, checkpointing, retention, and analytics integration. |
| Workflow orchestration and connectors | Azure Logic Apps | Managed workflows with triggers, actions, conditions, connectors, B2B integration artifacts, and integration across cloud, on-premises, and hybrid systems. |
| Custom handlers and workers | Azure Functions or Azure Container Apps | Functions for event-driven code; Container Apps for containerized workers, jobs, and KEDA-supported scaling. |
| Secrets and certificates | Azure Key Vault | Secure storage and access control for secrets, keys, and certificates, with logging options. |
| Workload identity | Managed identities | Azure resource identities that can access downstream dependencies without developers managing credentials. |
| Observability | Azure Monitor and Application Insights | Metrics, logs, traces, dashboards, alerts, Log Analytics, and application performance monitoring. |
This map is not a prescription. It is a provider lens. Start with the communication meaning, then select the Azure services that implement the responsibilities.
Example: Commerce Enterprise Integration on Azure
One commerce integration architecture might look like this:
Seller and partner APIs
-> Azure API Management
-> domain APIs and validation
Order and fulfillment commands
-> Azure Service Bus queues/topics
-> Functions or Container Apps workers
-> dead-letter review and replay controls
Order, inventory, shipment facts
-> Azure Event Grid
-> notification, support, analytics, and workflow starters
Clickstream, telemetry, and high-volume signals
-> Azure Event Hubs
-> streaming analytics and long-term capture paths
Returns, supplier onboarding, ERP export, and exception handling
-> Azure Logic Apps or workflow service
-> connectors, conditions, waits, manual review, and audit trail
Secrets, identity, and observability
-> managed identities, Key Vault, Azure Monitor, Application InsightsThe important design choice is not that many Azure services appear. The important choice is that each path has a distinct meaning and operating promise.
Service Selection Warnings
Some Azure services can appear to overlap. The overlap is manageable when the architecture keeps communication meaning clear.
| Looks Similar | Better Distinction |
|---|---|
| Service Bus topics and Event Grid | Service Bus is usually stronger for durable business messages and processing guarantees; Event Grid is usually stronger for event notification and routing. |
| Event Grid and Event Hubs | Event Grid routes discrete events to subscribers; Event Hubs is for high-throughput event streaming and consumers tracking position. |
| Logic Apps and Functions | Logic Apps is orchestration-first with connectors and workflow structure; Functions is code-first event-driven execution. |
| API Management and workflow connectors | API Management mediates APIs for consumers; workflow connectors coordinate process steps and system integration. |
| Queues and workflows | Queues move work; workflows make process state and recovery visible across steps. |
Do not let service names replace the design conversation.
Future Provider Lens Notes
Future AWS or GCP lenses should use the same responsibility map:
| Responsibility | Provider Questions |
|---|---|
| API mediation | Which gateway manages API contracts, policies, consumers, quotas, versions, and observability? |
| Durable messaging | Which queue or broker protects business work and failed messages? |
| Event routing | Which service routes event notifications to subscribers? |
| Streaming | Which service handles high-volume ingestion, partitions, retention, and consumer offsets? |
| Workflow | Which service coordinates multi-step processes, waits, connectors, retries, and compensation? |
| Identity and secrets | How do workloads avoid unmanaged credentials and protect sensitive values? |
| Observability | How are metrics, logs, traces, dashboards, alerts, replay, and business impact captured? |
Do not publish provider-specific claims until official documentation has been checked.
Common Mistakes
Treating messaging, event routing, streaming, and workflow orchestration as interchangeable.
Publishing provider claims without official documentation.
Ignoring partner operations because connectors look easy.
Letting provider service names replace communication meaning.
Using a workflow engine to hide unclear ownership instead of clarifying it.
Selecting a streaming service for durable business commands that need dead-letter recovery.
If Someone Asks You
How should provider services appear in an integration pattern article?
A good answer is:
Provider services should appear as implementation lenses after the communication meaning is clear. In Azure, API Management can mediate APIs, Service Bus can protect durable commands and business messages, Event Grid can route event notifications, Event Hubs can handle high-volume streams, Logic Apps can coordinate workflows and connectors, Functions or Container Apps can run handlers, Key Vault and managed identities can support secure access, and Azure Monitor can observe the flow. The service names do not replace contract, reliability, ownership, security, audit, and operating decisions.
What You Should Remember
Provider services are lenses for communication meaning and operating responsibility.
Questions to Check Understanding
Which integration responsibilities should a provider lens translate?
Why should communication meaning lead provider selection?
Which provider facts need official source verification before publication?