Updated DLT Gateway code. Related to Issue #165

# Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio, WebStorm and Rider

# Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839

# User-specific stuff

.idea/**/workspace.xml

.idea/**/tasks.xml

.idea/**/usage.statistics.xml

.idea/**/dictionaries

.idea/**/shelf

# AWS User-specific

.idea/**/aws.xml

# Generated files

.idea/**/contentModel.xml

# Sensitive or high-churn files

.idea/**/dataSources/

.idea/**/dataSources.ids

.idea/**/dataSources.local.xml

.idea/**/sqlDataSources.xml

.idea/**/dynamic.xml

.idea/**/uiDesigner.xml

.idea/**/dbnavigator.xml

# Gradle

.idea/**/gradle.xml

.idea/**/libraries

# Gradle and Maven with auto-import

# When using Gradle or Maven with auto-import, you should exclude module files,

# since they will be recreated, and may cause churn.  Uncomment if using

# auto-import.

# .idea/artifacts

# .idea/compiler.xml

# .idea/jarRepositories.xml

# .idea/modules.xml

# .idea/*.iml

# .idea/modules

# *.iml

# *.ipr

# CMake

cmake-build-*/

# Mongo Explorer plugin

.idea/**/mongoSettings.xml

# File-based project format

*.iws

# IntelliJ

out/

# mpeltonen/sbt-idea plugin

.idea_modules/

# JIRA plugin

atlassian-ide-plugin.xml

# Cursive Clojure plugin

.idea/replstate.xml

# Crashlytics plugin (for Android Studio and IntelliJ)

com_crashlytics_export_strings.xml

crashlytics.properties

crashlytics-build.properties

fabric.properties

# Editor-based Rest Client

.idea/httpRequests

# Android studio 3.1+ serialized cache file

.idea/caches/build_file_checksums.ser

# From https://github.com/github/gitignore/blob/master/Gradle.gitignore

/.gradle/

/build/

# Ignore Gradle GUI config

gradle-app.setting

# Avoid ignoring Gradle wrapper jar file (.jar files are usually ignored)

!gradle-wrapper.jar

# Cache of project

.gradletasknamecache

local.properties

wallet*/

 No newline at end of file

# Copyright 2022-2024 ETSI OSG/SDG TeraFlowSDN (TFS) (https://tfs.etsi.org/)

#

# Licensed under the Apache License, Version 2.0 (the "License");

# you may not use this file except in compliance with the License.

# You may obtain a copy of the License at

#

#      http://www.apache.org/licenses/LICENSE-2.0

#

# Unless required by applicable law or agreed to in writing, software

# distributed under the License is distributed on an "AS IS" BASIS,

# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

# See the License for the specific language governing permissions and

# limitations under the License.

FROM zenika/kotlin:1.4-jdk12

# Make working directory move to it and copy DLT Gateway code

RUN mkdir -p /var/teraflow/dlt/gateway

WORKDIR /var/teraflow/dlt/gateway

COPY src/dlt/gateway/. ./

# Make directory for proto files and copy them

RUN mkdir proto

COPY proto/*.proto ./proto/

# Build DLT Gateway

RUN ./gradlew build

EXPOSE 50051

# Create entrypoint.sh script

RUN echo "#!/bin/sh" > /entrypoint.sh

RUN echo "echo 195.37.154.24 peer0.org1.example.com >> /etc/hosts" >> /entrypoint.sh

RUN echo "echo 195.37.154.24 peer0.org2.example.com >> /etc/hosts" >> /entrypoint.sh

RUN echo "echo 195.37.154.24 orderer0.example.com   >> /etc/hosts" >> /entrypoint.sh

RUN echo "cd /var/teraflow/dlt/gateway" >> /entrypoint.sh

RUN echo "./gradlew runServer" >> /entrypoint.sh

RUN chmod +x /entrypoint.sh

# Gateway entry point

ENTRYPOINT ["sh", "/entrypoint.sh"]

```

     NEC Laboratories Europe GmbH

     PROPRIETARY INFORMATION

 The software and its source code contain valuable trade secrets and

 shall be maintained in confidence and treated as confidential

 information. The software may only be used for evaluation and/or

 testing purposes, unless otherwise explicitly stated in a written

 agreement with NEC Laboratories Europe GmbH.

 Any unauthorized publication, transfer to third parties or

 duplication of the object or source code - either totally or in

 part - is strictly prohibited.

          Copyright (c) 2022 NEC Laboratories Europe GmbH

          All Rights Reserved.

 Authors: Konstantin Munichev <konstantin.munichev@neclab.eu>

 NEC Laboratories Europe GmbH DISCLAIMS ALL WARRANTIES, EITHER

 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES

 OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND THE

 WARRANTY AGAINST LATENT DEFECTS, WITH RESPECT TO THE PROGRAM AND

 THE ACCOMPANYING DOCUMENTATION.

 NO LIABILITIES FOR CONSEQUENTIAL DAMAGES: IN NO EVENT SHALL NEC

 Laboratories Europe GmbH or ANY OF ITS SUBSIDIARIES BE LIABLE FOR

 ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR

 LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF

 INFORMATION, OR OTHER PECUNIARY LOSS AND INDIRECT, CONSEQUENTIAL,

 INCIDENTAL, ECONOMIC OR PUNITIVE DAMAGES) ARISING OUT OF THE USE OF

 OR INABILITY TO USE THIS PROGRAM, EVEN IF NEC Laboratories Europe

 GmbH HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

 THIS HEADER MAY NOT BE EXTRACTED OR MODIFIED IN ANY WAY.

 ```

# DLT module guide

## General information

The DLT module is used to provide access to the underlying Fabric deployment. It allows clients

to add, retrieve, modify and delete blockchain-backed data, essentially working as a key-value

database. External clients should use gRPC API to communicate with this service, its detailed

description available below.

## Code structure

The whole DLT module consists of several packages:

- fabric package

- http package

- proto package

- client example

### Fabric package

The most important class in this package is `FabricConnector`. First, it establishes connection

with the underlying Fabric network using Java Gateway SDK. After that, it could be used as a

CRUD interface.

Other files contain auxiliary code for `FabricConnector` which allows it to register/enroll

users and to obtain smart contract instances.

### Grpc package

Contains server side gRPC handler. It accepts requests from the outside and performs the

requested operation. For the more detailed description see Proto package description right below.

### Proto package

The proto package contains `dlt.proto` file which defines gRPC service `DltService` API and messages

it uses. There are 3 main functions: `RecordToDlt` which allows to create/modify/delete data,

`GetFromDlt` which returns already written data and `SubscribeToDlt` which allows clients subscribe

for future create/modify/delete events with provided filters.

Other proto files don't play any significant role and could be safely ignored by end users.

### Client example

This code is not necessary to the service, but it could be used to test the service. It contains

a sample gRPC client which connects the service and perform all the CRUD operations. 

# Fabric deployment notes

## General notes

Current Fabric deployment uses Fabric test network with some additional helping scripts on top of it.

To start the network just run the `raft.sh` from `blockchain/scripts` directory. Use `stop.sh`

when you need to stop the network.

## Server start preparations

To run the server it's necessary to copy certificate file

`fabric-samples/test-network/organizations/peerOrganizations/org1.example.com/ca/ca.org1.example.com-cert.pem`

to the config folder (replacing the existing one). Also, it's necessary to copy `scripts/connection-org1.json`

file (again, replacing the old one). After copying, it must be edited. First, all `localhost` entrances

should be replaced with `teraflow.nlehd.de`. Second, `channel` section at the end of the file should be removed.

This should be done after every restart of the Fabric network.

## Fabric configuration

Even though a test network is easy to deploy and use it's better to perform a custom configuration

for a production deployment. In practice every participating organization will likely prefer to have

its own Peer/Orderer/CA instances to prevent possible dependency on any other participants. This leads

not only to a better privacy/availability/security in general but also to the more complicated

deployment process as a side effect. Here we provide a very brief description of the most important points.

### Organizations

Organization represents a network participant, which can be an individual, a large corporation or any other

entity. Each organization has its own CAs, orderers and peers. The recommendation here is to create an

organization entity for every independent participant and then decide how many CAs/peers/orderers does

every organization need and which channels should it has access to based on the exact project's goals. 

### Channels

Each channel represents an independent ledger with its own genesis block. Each transaction is executed

on a specific channel, and it's possible to define which organization has access to a given channel.

As a result channels are a pretty powerful privacy mechanism which allows to limit access to the private

data between organization.

### Certificate authorities, peers and orderers

Certificate authorities (CA) are used to generate crypto materials for each organization. Two types of CA

exist: one is used to generate the certificates of the admin, the MSP and certificates of non-admin users.

Another type of CA is used to generate TLS certificates. As a result it's preferable to have at least two

CAs for every organization.

Peers are entities which host ledgers and smart contracts. They communicate with applications and orderers,

receiving chaincode invocations (proposals), invoking chaincode, updating ledger when necessary and

returning result of execution. Peers can handle one or many ledgers, depending on the configuration. It's

very use case specific how many peers are necessary to the exact deployment.

Orderers are used to execute a consensus in a distributing network making sure that every channel participant

has the same blocks with the same data. The default consensus algorithm is Raft which provides only a crash

fault tolerance.

### Conclusion

As you can see, configuration procedure for Fabric is pretty tricky and includes quite a lot of entities.

In real world it will very likely involve participants from multiple organizations each of them performing

its own part of configuration.

As a further reading it's recommended to start with the

[official deployment guide](https://hyperledger-fabric.readthedocs.io/en/release-2.2/deployment_guide_overview.html).

It contains a high level overview of a deployment process as well as links to the detailed descriptions to

CA/Peer/Orderer configuration descriptions.

 No newline at end of file

# Use an official Node.js runtime as a parent image

FROM node:20

# Set the working directory in the container

WORKDIR /usr/dltApp

# Copy package.json and package-lock.json

COPY dltApp/package*.json ./

# Copy tsconfig.json

COPY dltApp/tsconfig*.json ./

# Copy the proto folder

COPY dltApp/proto/ ./proto

# Copy the src folder

COPY dltApp/src/ ./src

# Install dependencies

RUN npm install

# Expose the port that the gRPC service runs on

EXPOSE 50051

# Command to run the service

CMD ["node", "src/dltGateway.js"]

 No newline at end of file

apiVersion: v1

kind: ConfigMap

metadata:

  name: dlt-config

  namespace: dlt

#NEED to find a better way to setup ENV variables for Kubernetes services

##Modify the PEER_ENDPOINT IP according to your deployment

data:

  CHANNEL_NAME: "channel1"

  CHAINCODE_NAME: "adrenalineDLT"

  MSP_ID: "Org1MSP"

  PEER_ENDPOINT: "PEER_IP:PORT" #USE THE IP address and Ports of your Fabric deployment peers.

  PEER_HOST_ALIAS: "peer0.org1.adrenaline.com"

  CRYPTO_PATH: "/test-network/organizations/peerOrganizations/org1.adrenaline.com"

  KEY_DIRECTORY_PATH: "/test-network/organizations/peerOrganizations/org1.adrenaline.com/users/User1@org1.adrenaline.com/msp/keystore"

  CERT_DIRECTORY_PATH: "/test-network/organizations/peerOrganizations/org1.adrenaline.com/users/User1@org1.adrenaline.com/msp/signcerts"

  TLS_CERT_PATH: "/test-network/organizations/peerOrganizations/org1.adrenaline.com/peers/peer0.org1.adrenaline.com/tls/ca.crt"