DDHub Message Broker is a component that primarily provides message routing, persisting, and delivery for a seamless data exchange between participants within an energy market or supply chain.
The message broker promotes sovereignty of participants by:
The broker does not have authority or logic which assumes the power of the participants
No one except the participant themselves can govern data exchange channels and verify messages
Encryption/decryption, signature validation, authorization, etc must be done under the participants domain (Client Gateway)
Below are the Message Broker components which need to be hosted to deploy a Decentralized Data Hub:
Message Broker App
NATS Jetstream and Jetstream Store to store small data messages (small messages up to 2 MB) and channel configurations
Azure Blob (or other large file) Store for large data messages and delimited files converted into blobs, as well as file metadata
RDBMS for message topic and schema management
In EW Data Exchange, the DDHub Message Broker is analogous to a computer - it is foundational infrastructure upon which participants gain the ability to establish their own “profiles”, exchange messages, and run their own applications. The DDHub Message Broker routes and translates messages between participants. Messages are structured and organised in distinct channels corresponding to specific use cases or business processes, and formatted in topics which define data formats and schemas.
In order to access certain channels and gain permissions to send and/or receive specific message types, participants must acquire roles that reflect their role within the market (or use case), using credentials attached to their self-determined identity. Credentials are granted by a platform governing body and determine the ability to send messages to other participants using channels (what messages are sent and received) and topics (data schemas that define the payload of a message).
Channels are defined at the client gateway, and are what messages are sent and received on. Participants define a channel as:
Type: Publish/Subscribe
Topics: Any that the DID has visibility of
Restrictions: Who will receive a message on a publish channel, or who I will receive a message from on a sub channel. Channels can be restricted by DID or role
An example of a channel definition object is provided below. In this example, the channel will receive RealTimePricing or DayAheadPricing from any DID with the role: user.roles.internal.apps.operator.iam.ewc and does not specify that payload encryption is required.
Topics are data schemas that define the payload of a message within a channel. They are grouped under owners that are used as an authorization unit for visibility. Two examples of Topics for publishing and acknowledging a distribution network line constraint are provided below:
\
The Decentralized Data Hub (DDHub) is one of the primary technologies underpinning EW Data Exchange solutions. The DDHub Environment is composed of multiple DDHub Messaging Client Nodes interacting with each other through the DDHub Message Broker.
Each node (or group of nodes) in the Message Broker cluster is identified with a unique DID and must be issued with a DDHub Messaging Client role
Each node contains an IAM Client that ensures legitimacy of users interacting within the messaging cluster by checking their identities, and issued role or set of roles\
The IAM Client and DIDs provide a layer of protection against unauthorized access to DDHub functionalities
Data exchanged within the cluster is secured in transit with mTLS
The DDHub Client Gateway is an integration gateway SDK that is intended to run on-premises or on the cloud environment of participants. It provides an interface for participant systems to interact with other systems in the shared interacting with a data exchange solution - namely, the DDHub Message Broker.
The Client Gateway is available in Github at https://github.com/energywebfoundation/ddhub-client-gateway or in the Azure Marketplace.
The gateway application is authenticated, authorized, and encrypted (messages) using self-sovereign identities (DIDs) and verifiable credentials rather than a centrally trusted and managed approaches seen in legacy solutions.
The client container is an integral part of the DDHub in achieving its decentralized characteristics as it assumes the power of the identity that it currently holds/represents.
DDHub Client GW UI: the main interface for admins to manage their DDHub Client GWs
DDHub Client GW API: exposes RESTful and Web Socket APIs for integration
DDHub Client GW Scheduler: contains scheduler jobs for caching data including but not limited to channels, topics, and decryption keys
DDHUB Client Gateway Storage: a postgres DB used to store configuration data.
Key Vault - store private keys and other secrets
DDhub Message Broker: The component that routes messages between Client gateways (using API to control NATS messaging).
SSI Toolkit: Libraries and components that implement identity and access management functionalities.
