ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Message Channel

Before talking about routing, translation or aggregation, we have to name what separates two applications: the channel. EIP §60 lays down this elementary brick, which the rest of the catalogue dresses up with richer semantics.

Problem

Two applications must exchange messages without knowing each other directly. If the sender opens a TCP socket on the receiver's IP, both sides become coupled to the transport, to simultaneous availability, to network stability. The first outage or third consumer breaks everything. In EDI, we also need encryption, signing and receipts; and the sender often does not know whether the receiver is online. We therefore need an abstraction that represents the conduit itself — addressable, typed, with a defined delivery semantic.

Forces

  • Spatial decoupling. The sender must not know the receiver's IP or availability, only the channel name.
  • Temporal decoupling. Sender and receiver need not run at the same time; the channel can buffer.
  • Typing. A channel does not carry just anything: a type (ORDERS, INVOIC, MDN…) is attached so consumers do not read messages they cannot process.
  • Delivery semantic. At-most-once, at-least-once, exactly-once — each carries a cost and trade-off; the channel must declare it.
  • Durability. Persist messages on disk or not? Latency vs. fault-tolerance trade-off.

Solution

EIP §60 (Hohpe & Woolf, 2003) defines the Message Channel as a named logical conduit between two or more participants. The channel carries five essential attributes: an addressable name (URI, JMS subject, queue ARN, Kafka topic), a direction (input / output / bidirectional), a message type (accepted schema), a delivery semantic (at-most-once, at-least-once, exactly-once) and a durability profile (persistent, in-memory, signed). Application code does not bind to a peer, it binds to a channel.

plaintext topology.txt 
Application A                         Application B
   ─────────────                         ─────────────

   ┌──────────┐         channel          ┌──────────┐
   │ producer │ ───────────────────────▶ │ consumer │
   └──────────┘   addressable conduit    └──────────┘
                  - direction
                  - message type
                  - delivery semantics
                  - durability

EDI implementation

In EDI, every partner connection is, conceptually, a separate channel:

  • Point-to-point AS2 channel. An AS2 connection between two partners (RFC 4130) is a bilateral channel, encrypted (CMS / PKCS#7), signed, with an MDN receipt. The channel's name is typically the pair (AS2-From, AS2-To). One direction per way.
  • SFTP channel. A drop directory on an SFTP server is an asynchronous file-by-file channel. The channel name is the path (/edi/in/walmart/). No transactional delivery by default, hence idempotency required downstream.
  • AS4 PEPPOL channel. An Access Point receives AS4 messages over an HTTPS URL; the channel is the pair (endpoint URL, participant ID). Delivery semantic is at-least-once (NRR via WS-ReliableMessaging).
  • Internal Kafka / RabbitMQ channel. Between the integration hub and the internal microservices, Kafka topics (edi.invoic.in.canonical) or configured-retention RabbitMQ queues.
http as2-channel.http 
# AS2 message envelope — point-to-point encrypted and signed channel
POST /as2 HTTP/1.1
Host: partner.example.com
Content-Type: application/pkcs7-mime; smime-type=enveloped-data
AS2-From: SUPPLIER_GLN
AS2-To: BUYER_GLN
Message-ID: <inv-202605140001@ediverse.io>
Disposition-Notification-To: as2@ediverse.io
Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature;
  signed-receipt-micalg=optional, sha-256
EDIINT-Features: multiple-attachments, AS2-Reliability

<encrypted-EDIFACT-payload>

Reading: the AS2 HTTP header carries the channel's attributes — From / To identify the peers, Message-ID drives uniqueness semantics, Disposition-Notification-To requests the MDN receipt. The emitting application does not know how the channel is implemented underneath (TLS, IP routing, HTTP retry); it publishes on the logical AS2 channel.

Channel taxonomy

Hohpe groups channels into four foundational families:

  • Point-to-Point Channel (EIP §103) — exactly one consumer receives each message. EDI equivalent: AS2 between two partners.
  • Publish-Subscribe Channel (EIP §106) — multiple consumers receive each message. EDI equivalent: a UBL SBDH routed via PEPPOL to multiple destination APs of one invoice.
  • Datatype Channel (EIP §111) — a channel carries one message type only. EDI equivalent: edi.orders.canonical and edi.invoic.canonical kept separate.
  • Invalid Message Channel (EIP §115) — where malformed messages go. See Dead Letter Channel.

Anti-patterns

  • Coupling to the transport. Writing new Socket("partner.example.com", 21) in application code instead of publish("partner.invoic.out"). Migrating to AS4 means rewriting.
  • Grab-bag channel. A channel named edi.in that accepts every message type. You then need a Message Router upstream anyway — name it.
  • Implicit delivery semantic. Not declaring whether the channel is at-most-once or at-least-once inevitably leads to duplicate or loss incidents.
  • Unversioned channels. When a type's schema evolves, create edi.invoic.v2.canonical beside it rather than break every consumer.

Sources