Messages travel directly between two parties, without passing through a shared hub. The opposite of the centralised model Elhub is built on. Also called point-to-point.
Definition
Two architectures solve the same task in different ways. In the centralised one, every actor connects to a single hub, and the hub receives, validates and distributes onward. Ten actors mean ten connections. In the bilateral one, A connects directly to B, and every new counterparty is a new setup with its own format, its own transport and its own agreement. Ten actors who all need to talk to each other make forty-five connections.
The arithmetic makes it tempting to say the hub always wins, and on connection count it does. But the hub has to exist. It has to cover your message types, someone has to own and operate it, and it needs a mandate from the whole market. ElhubNational hub for metering data and market processes in the Norwegian electricity market. covers the Norwegian market processes: metering values, supplier switches, moves. It does not cover invoices, delivery schedules or product data between two companies, and it does not exist in the Swedish power market.
The word is not jargon invented for the occasion. It means two-sided, and is used the same way in trade as in architecture. Point-to-point is the common English alternative, and the two say exactly the same thing. The counterpart is usually called hub-and-spoke.
What separates the two models in operation is not speed but who notices that something is missing. The hub knows what it is waiting for and from whom. Two parties talking directly know it only if someone built that in.
Norway runs both models at once, which is worth noting. Metering values and supplier switches go through Elhub. Everything else goes bilaterally: invoices, delivery schedules, product data, settlement documentation between two companies that have agreed something between themselves.
That traffic has rarely been given the same care as the hub integration. It is often solved either with an expensive, closed message broker that sees everything passing through, or with something homebuilt lacking quarantine, acknowledgement or alerting when something fails to arrive. The fault is discovered when the counterparty phones, and by then it has been running for a while.
A system like SEFTA cannot send data out on its own in a market without a hub. That is when HANDSAL carries it, and it is why the transport layer is a product of its own rather than a function inside another one.
In practice
Norway runs both models at once, which is worth noting. Metering values and supplier switches go through ElhubNational hub for metering data and market processes in the Norwegian electricity market.. Everything else goes bilaterally: invoices, delivery schedules, product data, settlementTurning metering data into money. Consumption and production per metering point become what each party owes or is owed. documentation between two companies that have agreed something between themselves.
That traffic has rarely been given the same care as the hub integration. It is often solved either with an expensive, closed message broker that sees everything passing through, or with something homebuilt lacking quarantine, acknowledgement or alerting when something fails to arrive. The fault is discovered when the counterparty phones, and by then it has been running for a while.
A system like SEFTATvimenning’s VEE engine: validates, estimates and edits metering series with versioned time series and a full audit trail, before data goes to Elhub. cannot send data out on its own in a market without a hub. That is when HANDSALTvimenning’s EDI server for bilateral message exchange: receives, translates, routes and acknowledges messages between companies and marketplaces. carries it, and it is why the transport layer is a product of its own rather than a function inside another one.
