Point-to-Point Channel

One message, one recipient — the default mode when the sender wants to address one identified partner. This is the semantic of AS2, partner-to-partner SFTP, and 99% of bilateral EDI connections.

Problem

A sender wants to transmit a message to a precise receiver, exactly once. Broadcasting to several consumers risks processing an order twice: two pallets shipped, two invoices emitted. The desired semantic is exclusive delivery: one and only one application receives and processes each message.

Forces

• Broker-level no-duplication guarantee. The channel itself guarantees that a read and acknowledged message is removed, not merely tagged.
• Producer/consumer asymmetry. The producer does not know the physical identity of the consumer, only the queue's name.
• Horizontal scalability. Several consumers can compete on the same queue (competing consumers), still keeping per-message exclusivity.
• Order preservable but costly. Keeping strict arrival order imposes a single sequential consumer (or per-key partitions).

Solution

EIP §103 (Hohpe & Woolf, 2003) defines the Point-to-Point Channel as a channel whose delivery semantic is exclusive: when a consumer reads and acknowledges a message, it is removed and will never be re-read by any other consumer. The classic implementation is a queue (RabbitMQ, IBM MQ, SQS, Azure Service Bus queue, JMS queue), as opposed to topics which implement the publish-subscribe pattern.

one sender                      one receiver (exclusive)
   ──────────                      ──────────────────────────

   ┌────────┐     ┌──────────┐    ┌─────────────┐
   │ A      │ ──▶ │  queue   │ ──▶│ B           │
   └────────┘     └──────────┘    └─────────────┘
                  delete after
                  successful read

   Variant: competing consumers (still one delivery)
                  ┌──────────┐    ┌─────────────┐
                  │  queue   │ ──▶│ worker B1   │
                  │          │    └─────────────┘
                  │          │    ┌─────────────┐
                  │          │ ──▶│ worker B2   │
                  └──────────┘    └─────────────┘
                  (each msg goes to exactly one worker)

EDI implementation

In EDI, most channels are point-to-point:

• AS2 between two partners. A supplier ships over an AS2 dedicated to a specific buyer (Walmart, Stellantis…). The message lands in the unique receiving slot, acknowledged by MDN. A single destination application processes it.
• OFTP2 multi-VAN. OFTP2 flows in automotive (Stellantis, Renault) are strictly bilateral between two named OFTP stations. No broadcast.
• Dedicated partner SFTP. An SFTP directory /in/walmart-edi/ where only the Walmart integration pipeline pulls files. Once read and acknowledged downstream, the file is moved or deleted.
• Classic VAN (GXS, Sterling). A legacy VAN drops each interchange into the recipient's mailbox; no other partner can access this mailbox.

# AS2 partnership entry — a typed point-to-point channel
partnership "WALMART_BUYER -> SUPPLIER_GLN":
  channel-id: walmart-supplier-orders
  protocol: AS2
  url: https://walmart-edi.example.com/as2
  as2-from: WALMART_BUYER
  as2-to: SUPPLIER_GLN
  encryption: AES-256
  signing: SHA-256
  mdn: signed-async
  message-type: ORDERS / 850
  delivery-semantics: at-least-once  # MDN-retry path
  inbox-route: edi.orders.in.canonical
  retention-days: 2555  # ~7 years compliance

Competing consumers

Hohpe distinguishes Point-to-Point from Publish-Subscribe by the delivery semantic, not by the number of consumers. A point-to-point queue can be read by N competing workers (the Competing Consumers pattern, EIP §502): each message goes to exactly one worker, but N workers share the load. That mode makes EDI pipelines horizontally scalable without sacrificing processing uniqueness.

Anti-patterns

• Multiple non-exclusive consumers on a point-to-point queue. If two distinct applications read the same queue, each catches part of the messages — the other has none. Classic symptom: "I moved the app to a second instance and the first lost half the messages".
• Auto-delete without ack. The broker must remove the message after consumer ACK, never on read. Otherwise a crash between read and process loses the message permanently.
• No DLQ. A message failing N times on the main queue must go to a Dead Letter Channel, not loop.
• Sender addressing a specific consumer. Coupling: if the sender knows the worker is called edi-worker-3, the abstract channel is lost.

Related patterns

• Message Channel — the generalisation.
• Publish-Subscribe Channel — the broadcast alternative.
• Dead Letter Channel — where messages go after N failures.
• Idempotency — defense in depth when the broker is at-least-once.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, Point-to-Point Channel (§103). enterpriseintegrationpatterns.com — Point-to-Point Channel
• Hohpe G., Woolf B. — Competing Consumers (§502). enterpriseintegrationpatterns.com — Competing Consumers
• RFC 4130 — AS2, MIME-Based Secure Peer-to-Peer Business Data Interchange. IETF, July 2005.
• Apache Camel — JMS / RabbitMQ / SQS components. Each queue endpoint implements the point-to-point pattern. camel.apache.org — JMS