Service discovery
In a federated system like the BDI, it’s sometimes necessary to contact services that are new to the data consumer. For instance, it’s possible to configure an Authorization Register per Data Owner, even when the data is provided by a single Service Provider. In any case the Data Owner can choose where to host services.
In the BDI, the discovery process is recommended for enabling connections between data providers and consumers. Unlike traditional data marketplaces, where the primary focus is on matching providers with potential consumers to establish new data-sharing relationships, BDI focuses on optimizing existing data exchanges. These exchanges often support operational logistics in the supply chain, where different parties are already connected but require more efficient methods for data exchange.
The BDI supports two methods of service discovery:
- Discovery by defining a standard based on the Domain Name System (DNS)
- Discovery based on the Association Register and standardized endpoints of Service Providers
DNS-based Service Discovery
- Well-Known Subdomain: A predictable subdomain, such as
_bdi.acme-corp.com
, serves as a central point for service discovery. This subdomain is used to organize DNS records related to BDI services, making it easy for data consumers to find relevant endpoints. - SRV Records: SRV records are used to locate the actual endpoints where services are hosted. These records specify the hostname or IP address, port number, protocol, and other parameters necessary to connect to the service.
- Key Fields:
target
(hostname/IP),port
(service port number),priority
andweight
(used to select the best service endpoint if multiple are available). - TXT Records: TXT records provide descriptive information about the services offered by a data provider. These records can include lists of services available under a specific subdomain, details about the protocols used, and any additional attributes required for service access.
- DNSSEC: DNSSEC provides security for DNS by enabling the validation of DNS responses. This is crucial for preventing attacks like cache poisoning, ensuring that data consumers receive accurate and trustworthy information during the discovery process.
More information is available in DNS Service Discovery proposal
Association Register and endpoints-based Service Discovery
BDI provides a framework for discovery based on specifications in the iSHARE Trust Framework. There are three aspects to discovery:
- Associations. Associations (called Data Spaces in iSHARE) are (if they choose to) discoverable through the /dataspaces endpoint of any Association Register (in iSHARE: iSHARE Satellite).
- Members of an Association (called Participants of a Data Space in iSHARE). Participants of an association (data space in iSHARE) are (if they choose to) discoverable through the /parties endpoint of any Association Register (in iSHARE: iSHARE Satellite).
- (Data) Services. All participants providing services must provide a /capabilities endpoint. This endpoint provides information on the available BDI-supported service offerings.
Discovery of the Authorization Registry of a Data Owner
To discover the Authorization Register that is chosen by the Data Owner (optionally for a specific Data Space or Service), the party details can be retrieved using the /parties endpoint or the “Single Party” endpoint. The information is available in the auth_registries
attribute.