commit d01822de433ba13376cdf60ef9e18f0df34291bd
parent 43e6e441bf812f78239141fb847b4fdfa1ba2a68
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Wed, 5 Jun 2024 19:19:06 +0200
docs: enhance
Diffstat:
14 files changed, 5 insertions(+), 94 deletions(-)
diff --git a/docs/content/implementation/a-c2ec.tex b/docs/content/implementation/a-c2ec.tex
@@ -9,7 +9,7 @@ The diagram in \autoref{fig-diagram-c2ec-apis-sequence} shows the perspective of
The implementation of the terminals API can be found in \autoref{sec-implementation-terminal-api}, the bank integration API is documented in \autoref{sec-implementation-bank-integration-api} and the wire gateway API implementation is documented in \autoref{sec-implementation-wire-gateway-api}
-\begin{figure}[h]
+\begin{figure}[H]
\centering
\includegraphics[width=0.7\textwidth]{pictures/diagrams/c2ec_apis.png}
\caption{C2EC and its interactions with various components}
diff --git a/docs/content/implementation/a-providers.tex b/docs/content/implementation/a-providers.tex
@@ -50,4 +50,4 @@ Additionally to the Wallee Client a Simulation Client was implemented which can
\subsubsection{Adding a new provider}
-Adding a new provider requires the implementation of the client- and transaction-interfaces as described in \autoref{sec-provider-client-interface} and \autoref{sec-provider-transaction-interface}. The \texttt{SetupClient} function of the client interface must make sure to register itself to the global map of registered providers (accessible through \texttt{PROVIDER\_CLIENTS}). Additionally, to the newly added provider implementation, the provider must also be registered in the database (\autoref{sec-implementation-cli} describes how this could work). When the client adds itself to the registered providers clients, the application will load the provider client at startup of C2EC. If C2EC fails to find the specified provider in the database, it won't start. This behaviour makes sure, that only needed providers are running and that if a new provider was added, it is effectively registered and configured correctly (the setup function of the provider interface is responsible to check the provider specific configuration and do readiness or liveness checks if needed). If the new added provider requires a new payto target type, adding a new entry to GANA in order to prevent conflicts in the future might be a good idea.
+Adding a new provider requires the implementation of the client- and transaction-interfaces as described in \autoref{sec-provider-client-interface} and \autoref{sec-provider-transaction-interface}. The \texttt{SetupClient} function of the client interface must make sure to register itself to the global map of registered providers (accessible through \texttt{PROVIDER\_CLIENTS}). Additionally, to the newly added provider implementation, the provider must also be registered in the database (\autoref{sec-implementation-cli} describes how this could work). When the client adds itself to the registered providers clients, the application will load the provider client at startup of C2EC. If C2EC fails to find the specified provider in the database, it won't start. This behaviour makes sure, that only needed providers are running and that if a new provider was added, it is effectively registered and configured correctly (the setup function of the provider interface is responsible to check the provider specific configuration and do readiness or liveness checks if needed). If the new added provider requires a new payto target type, adding a new entry to the GANA in order to prevent conflicts in the future might be a good idea.
diff --git a/docs/content/implementation/f-deployment.tex b/docs/content/implementation/f-deployment.tex
@@ -52,7 +52,7 @@ The POS terminal app must be deployed by the Wallee support. The Android package
\subsubsection{Making C2EC Accessible Via Internet}
-To make the C2EC instance available a web-server must be configured to receive requests and hand them to the C2EC instance. The exact configuration will not be covered within this thesis. The test installation uses a NGINX reverse proxy \cite{nginx-reverse-proxy} to allow the access over the internet. A rudimentary configuration is enough to allow the access. It helps to set big timeouts since a lot of long-polling is done. To not undermine this, NGINX should not terminate the connection before the long-poll time exceeds. Setting big values for timeouts will be a good practice for C2EC. On the other hand clients should not run long running requests against C2EC but instead leverage retries to extend the time they wait for a response. A value between 30 and 60 seconds might be a good choice for long-polling requests.
+To make the C2EC instance available a web-server must be configured to receive requests and hand them to the C2EC instance. The exact configuration will not be covered within this thesis. The test installation uses a NGINX reverse proxy \cite{nginx-reverse-proxy} to allow the access over the internet. A rudimentary configuration is enough to allow the access. It helps to set big timeouts since a lot of long-polling is done. To not undermine this, NGINX should not terminate the connection before the long-poll time exceeds. Setting big values for timeouts will be a good practice for C2EC. On the other hand clients should not run long running requests (more than a minute or two) against C2EC and instead leverage retries to extend the time they wait for a response. A value between 30 and 60 seconds might be a good choice for long-polling requests (These values are also used by the wallet and the wire watch process of the Exchange). Using too long values for long-pollings can result in less robust systems due to timeout problems.
\subsection{Migration And Releases}
\label{sec-implementation-deployment-migration}
diff --git a/docs/pictures/diagrams/c2ec.png b/docs/pictures/diagrams/c2ec.png
Binary files differ.
diff --git a/docs/pictures/diagrams/component.png b/docs/pictures/diagrams/component.png
Binary files differ.
diff --git a/docs/pictures/diagrams/db_nonce2ecash_erd.png b/docs/pictures/diagrams/db_nonce2ecash_erd.png
Binary files differ.
diff --git a/docs/pictures/diagrams/provider_registration_sequence.png b/docs/pictures/diagrams/provider_registration_sequence.png
Binary files differ.
diff --git a/docs/pictures/diagrams/wallee_app_class_diagram.png b/docs/pictures/diagrams/wallee_app_class_diagram.png
Binary files differ.
diff --git a/docs/pictures/diagrams/wallee_app_sequence.png b/docs/pictures/diagrams/wallee_app_sequence.png
Binary files differ.
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
Binary files differ.
diff --git a/specs/c2ec.plantuml b/specs/c2ec.plantuml
@@ -11,8 +11,9 @@ actor TerminalOwner as "Terminal Owner"
Terminal -> Terminal: configures Exchanges
User -> TerminalOwner: "Hi, I want to withdraw 20 CHF using Taler with my Credit Card"
TerminalOwner -> Terminal: start Taler Withdrawal Application and enters amount
-Terminal -> Terminal: Generate WOPID
Terminal -> C2EC: (0) Setup Withdrawal
+C2EC -> C2EC: Generate WOPID
+C2EC -> Terminal: Withdrawal setup response (WOPID)
Terminal -> C2EC: Start long polling (WOPID)
activate C2EC
Terminal -> Terminal: Create QR code (WOPID, Exchange, Amount)
diff --git a/specs/component.plantuml b/specs/component.plantuml
@@ -1,28 +0,0 @@
-top to bottom direction
-skinparam packageStyle rect
-
-@startuml
-package "Taler" {
- [Taler Wallet] as Wallet
- [Exchange] as Exchange
-}
-
-package "Terminal System" {
- [Terminal] as Terminal
- [Terminal Operator Backend] as Backend
-}
-
-[Credit Card] as CC
-
-Wallet -> Terminal: (1) Scan QR Code (Nonce)
-Wallet -> Exchange: (2) Nonce to Wallet Public Key Hash
-Terminal <- Exchange: (3) Ready
-
-CC -> Terminal: (4) Present CreditCard
-Terminal -> Backend: (5) Payment
-Backend -> Terminal: (6) Response
-Exchange -> Backend: (7) Verify Transaction
-
-Wallet -> Exchange: (8) Withdraw
-
-@enduml
diff --git a/specs/overview.plantuml b/specs/overview.plantuml
@@ -1,40 +0,0 @@
-@startuml
-
-actor Customer
-actor "Terminal Owner" as TerminalOwner
-
-package "EBICS System" {
- [EBICS] as EBICS
-}
-
-package "Taler Exchange" {
- [Bank Integration API] as BankIntegrationAPI
- [Wirewatch Gateway] as WirewatchGateway
- [nonce2ecash] as Nonce2Ecash
- [Wallet] as Wallet
- database "Exchange-DB" as ExDB
-}
-
-package "Wallee System" {
- [Wallee Terminal] as WalleeTerminal
- [Wallee Backend] as WalleeBackend
-}
-
-Customer --> Wallet
-TerminalOwner --> WalleeTerminal
-
-Nonce2Ecash --> ExDB
-WirewatchGateway --> ExDB
-BankIntegrationAPI --> ExDB
-Nonce2Ecash --> WirewatchGateway
-Nonce2Ecash --> BankIntegrationAPI
-Wallet --> WalleeTerminal
-Wallet --> Nonce2Ecash
-Wallet --> BankIntegrationAPI
-WirewatchGateway --> EBICS
-WalleeBackend --> EBICS
-WalleeTerminal --> WalleeBackend
-WalleeTerminal --> Nonce2Ecash
-Nonce2Ecash --> WalleeBackend
-
-@enduml
diff --git a/specs/wallee_app_sequence.plantuml b/specs/wallee_app_sequence.plantuml
@@ -1,22 +0,0 @@
-@startuml
-participant User
-participant Wallet
-participant Terminal
-participant Exchange
-participant TerminalBackend as "Terminal-Backend"
-participant Merchant as "Merchant (Terminal Owner)"
-
-activate Terminal
-Terminal -> Terminal: load configuration
-Wallet -> Exchange: Establish nonce2ecash mapping
-Wallet -> Terminal: Generate and show QR code
-Merchant -> Terminal: Enter withdrawal amount
-Terminal -> User: Show withdrawal summary and ToS\n(including computed fees)
-User -> Terminal: Accept fees & ToS
-Terminal -> User: Prompt to show Credit Card
-User -> Terminal: Show Credit Card
-Terminal -> TerminalBackend: process payment
-TerminalBackend -> Terminal: response
-Terminal -> User: Show transaction result
-deactivate Terminal
-@enduml
