The Minimum Viable Dataspace (MVD) is a sample implementation of a dataspace that leverages the Eclipse Dataspace Connector (EDC). The main purpose is to demonstrate the capabilities of the EDC, make dataspace concepts tangible based on a specific implementation, and to serve as a starting point to implement a custom dataspace.
The MVD allows developers and decision makers to gauge the current progress of the EDC and its capabilities to satisfy the functionality of a fully operational dataspace.
As a fully decentralized dataspace is hard to imagine, the MVD also serves the purpose of demonstrating how decentralization can be practically implemented.
Developer documentation can be found under docs/developer, where the main concepts and decisions are captured as decision records.
To be able to deploy your own dataspace instances, you first need to fork the MVD repository and set up your environment.
Once your environment is set up, follow these steps to create a new dataspace instance:
Actions
.Deploy
.Run workflow
to trigger the deployment.Follow these steps to delete a dataspace instance and free up the corresponding resources:
Actions
Destroy
Run workflow
Run workflow
to trigger to destroy your MinimumViableDataspace DataSpace.The MVD backend and MVD UI (Data Dashboard) can be run locally for testing and development.
MVD_UI_PATH
to the path of the DataDashboard repository. (See example below.)Publish/Build Tasks
system-tests/README.md to set up a
local MVD environment with the exception to use the profile ui
. (See example below.)
Local Test Execution
in system-tests/README.md
.Using the profile
ui
will create three MVD UIs (Data Dashboards) for each EDC participant in addition to the services described in system-tests/README.md.
Bash:
export MVD_UI_PATH="/path/to/mvd-datadashboard"
docker-compose --profile ui -f system-tests/docker-compose.yml up --build
PowerShell:
$Env:MVD_UI_PATH="/path/to/mvd-datadashboard"
docker-compose --profile ui -f system-tests/docker-compose.yml up --build
In Windows Docker Compose expects the path to use forward slashes instead of backslashes.
The profile ui
creates three Data Dashboards each connected to an EDC participant. The respective app.config.json
files can be found in the respective directories:
resources/appconfig/company1/app.config.json
resources/appconfig/company2/app.config.json
resources/appconfig/company3/app.config.json
That's it to run the local development environment. The following section Run A Standard Scenario Locally
describes a
standard scenario which can be optionally used with the local development environment.
Tip: The console output from the services spun up by Docker compose can be noisy. To decrease the output from the services on the console set
EDC_CATALOG_CACHE_EXECUTION_PERIOD_SECONDS
to a higher value, e.g. 60, for each EDC participant insystem-tests/docker-compose.yml
.Note: The container
cli-tools
will turn into the statehealthy
after registering successfully all participants and will keep running as an entrypoint to the services created by Docker compose. This is useful for local development in order to manually check commands against the participants (e.g.company1
,company2
,company3
).
Sample how to enter the container cli-tools
and test a command manually.
Host:
docker exec -it cli-tools bash
Container:
java -jar registration-service-cli.jar \
> -d=did:web:did-server:registration-service \
> --http-scheme \
> -k=/resources/vault/company1/private-key.pem \
> -c=did:web:did-server:company1 \
> participants get
Output (container)
{
"did" : "did:web:did-server:company1",
"status" : "ONBOARDED"
}
Prerequisite: create a test document manually:
company1assets
, storage account key: key1
.localhost:10000
.src-container
. (Container name is defined for Postman request Publish Master Data
in deployment/data/MVD.postman_collection.json
)deployment/terraform/participant/sample-data/text-document.txt
into the newly created container.
text-document.txt
.All this can also be done using Azure CLI with the following lines from the root of the MVD repository:
Bash:
conn_str="DefaultEndpointsProtocol=http;AccountName=company1assets;AccountKey=key1;BlobEndpoint=http://127.0.0.1:10000/company1assets;"
az storage container create --name src-container --connection-string $conn_str
az storage blob upload -f ./deployment/terraform/participant/sample-data/text-document.txt --container-name src-container --name text-document.txt --connection-string $conn_str
PowerShell:
$conn_str="DefaultEndpointsProtocol=http;AccountName=company1assets;AccountKey=key1;BlobEndpoint=http://127.0.0.1:10000/company1assets;"
az storage container create --name src-container --connection-string $conn_str
az storage blob upload -f .\deployment\terraform\participant\sample-data\text-document.txt --container-name src-container --name text-document.txt --connection-string $conn_str
This should result in a similar output as follows. Via the Microsoft Azure Storage Explorer it would be possible to review the new container and the uploaded blob.
{
"created": true
}
Finished[#############################################################] 100.0000%
{
"etag": "\"0x1CC7CAB96842160\"",
"lastModified": "2022-08-08T15:14:01+00:00"
}
The following steps initiate and complete a file transfer with the provided test document.
Assets
.Catalog Browser
.
Catalog Browser
click Negotiate
for the asset test-document_company1
.Contract Negotiation complete! Show me!
in less than a minute.Show me!
. If you missed it, switch manually to the section Contracts
.
Transfer
to initiate the transfer process.AzureStorage
and click Start transfer
.Transfer [id] complete! Show me!
in less than a minute. (Where id
is a UUID.)company2
.
system-tests/docker-compose.yml
for the service azurite
. Default name
is company2assets
, key is key2
..complete
and test-document.txt
.See how to contribute.