## 4 Application Implementation
### Technical Architectural View  
This section clarifies the complete technical architectural components connection and integration in a single system. The presented application combines, in a nutshell, an Alastria node which is part of the titular blockchain network, an external NoSQL database where the music asset data is read from through the dedicated API service, namely the Bloomen API, and the core application which associates and blends everything together.  
In Figure 5, the core application, named as the Decentralized Rights Management App, is visualized together with its interaction components. The Alastria node, as explained in Section 3, allows the simple, concise and decent communication of the application with the smart contracts deployed in the Alastria blockchain. The application uses the dedicated API in order to fetch any music asset data from an external NoSQL type of database (MongoDB), when creating a new claim. Further, when users exploit the API, they are able to create claims only for the music assets included in the collections of the repertoire database they are allowed to access. The latter feature is also configured on-chain in  
Figure 4: The user hierarchy with relations to business actors.  
the context of the CMOs, specifically allowing their Members to only see certain collections from the external database.  
The Bloomen REST API provides RESTful services that are responsible for the efficient integration of the application layer with the blockchain. This REST API makes available to the application layer all required blockchain and off-chain functionalities, providing the Bloomen blockchain platform end-users a smooth UX experience.  
The technology stack and the architecture of the Bloomen platform is depicted in Figure 6. As seen in this, the backend is split in two parts; the off-chain part and the on-chain part.  
The off-chain part consists of the data storage layer controlled by a Node.js application, built with the Express.js web framework, which also exposes a RESTful API. MongoDB as an object storage, used mainly for storing the non-blockchain data, while the Apache Solr server is used as a full-text search engine. Everything in this part is hosted in Heroku PaaS on top of Amazon Web Services and, as a repository for binary files, the Amazon S3 cloud storage is being used.  
The on-chain part of the backend includes the blockchain infrastructure, which is based on a Quorum instance and is running inside the Alastria ecosystem. A set of smart contracts is installed on the blockchain, written in Solidity. The communication with the blockchain is implemented in javascript with the web3.js library.  
A facade layer is responsible for synchronizing the calls between the off-chain and on-chain parts of the backend. It also exposes a RESTful API to be consumed by any pilot application using the Bloomen platform, starting with the musical rights governance use case.  
Figure 5: Technical architectural view of all the components.  
Regarding security, a powerful authentication mechanism has been designed and implemented by using JSON Web Token (JWT) tokens on every call, letting all transactions be stateless. Following the RESTful principles, we do not store a session for the client applications. Instead, we exchange on every request a server-signed JWT token, which is normally preserved in the browser's local storage and is passed inside the authorisation header of the HTTP request. With the JWT token, the server side can authenticate the sender of a request and can ensure that the request is valid and authorized.  
The innovation of conflicting copyright claim detection through the developed, deployed and maintained smart contracts is the pinnacle of the paper; a description of the innovation reasoning and analysis follows.