wiki.ziemers.de

ziemer's informatik Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen:
wiki:software:beuthbot:software-architecture

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste Überarbeitung 		Vorhergehende Überarbeitung
wiki:software:beuthbot:software-architecture [10.12.2019 16:40]
Christopher Lehmann angelegt 		wiki:software:beuthbot:software-architecture [23.01.2020 15:30] (aktuell)
Timo Bruns [Software Architecture]
Zeile 1: Zeile 1:
-# Software Architecture+===== Software Architecture =====
  
-## Table of Contents+==== Table of content ====
  
-<!-- TOC depthFrom:2 depthTo:6 withLinks:1 updateOnSave:1 orderedList:0 -->+ - [[wiki:software:beuthbot:software-architecture#table of content|Table of content]] 
 + - [[wiki:software:beuthbot:software-architecture#overview|Overview]] 
 + - [[wiki:software:beuthbot:software-architecture#basic structure|Basic Structure]] 
 + - [[wiki:software:beuthbot:software-architecture#bot|Bot]] 
 + - [[wiki:software:beuthbot:software-architecture#gateway|Gateway]] 
 + - [[wiki:software:beuthbot:software-architecture#registry|Registry]] 
 + - [[wiki:software:beuthbot:software-architecture#service|Service]] 
 + - [[wiki:software:beuthbot:software-architecture#api|API]]
  
-- [Table of Contents](#table-of-contents) +==== Overview ====
-- [Overview](#overview) +
-- [Basic Structure](#basic-structure) +
- - [Bot](#bot) +
- - [Gateway](#gateway) +
- - [Registry](#registry) +
- - [Service](#service) +
-- [API](#api)+
  
-<!-- /TOC -->+//BeuthBot// consists of many interwoven //Microservices//. Evey Microservice uses our basic API to communicate with other Microservices. This approach enables us to change parts of the system easily at any time or to introduce new Microservices, all they need to do is to implement our API.
  
-## Overview +==== Basic Structure ====
- +
-_BeuthBot_ consists of many interwoven _Microservices_. Evey Microservice uses our basic API to communicate with other Microservices. This approach enables us to change parts of the system easily at any time or to introduce new Microservices, all they need to do is to implement our API. +
- +
-## Basic Structure+
  
 Our application is basically composed of the following four components. Our application is basically composed of the following four components.
Zeile 26: Zeile 22:
 > Bot <=> Gateway <=> Registry <=> Service > Bot <=> Gateway <=> Registry <=> Service
  
-Following diagram shows that in more detail.+Following diagram shows that in more detail:
  
-![structure](../assets/structure-without-notes.png)+<uml> 
 +abstract class Bot 
 +class TelegramBot 
 +class TwitterBot 
  
-A user can write the _Bot_ to request informations, the meaning of the message is extracted and a fitting _Microservice_ is choosen to retrieve the necessary data. A response is build from that data and distributed back up to the bot which answers the users request.+Bot <|-- TelegramBot 
 +Bot <|-- TwitterBot
  
-following sequence diagram further illustrates that.+class Gateway 
 +class MetaMetaPersistence 
 +class MetaPersistence
  
-![flow](../assets/flow.png)+package nlp {
  
-### Bot+class "rasa-ai" 
 +class "drools" 
 +class "Google Cloud Speech API" 
 +class "Google Cloud Natural Language" 
 +class "Microsoft Azure Spracherkennungs-API" 
 +class "Microsoft Azure Textanalyse-API" 
 +"Google Cloud Speech API" -> "Google Cloud Natural Language" 
 +"Microsoft Azure Spracherkennungs-API" -> "Microsoft Azure Textanalyse-API" 
 +}
  
-This is an abstraction for the available chatbots, e.g. a _Bot_ for _Telegram_ and another _Bot_ for _WhatsApp_.+Gateway -- nlp
  
-The user interacts with this _Microservice_, here she can request information and gets answers from _BeuthBot_.+Bot "1..*" -- Gateway
  
-### Gateway+Gateway -- MetaMetaPersistence
  
-The _Gateway_ is the centerpiece of _BeuthBot_ one could say.+class Registry
  
-The _Bot_ notifies the _Gateway_ with the message it got from the user.+Gateway "1" -- "1" Registry 
 +Registry -- MetaPersistence
  
-The _Gateway_ then uses NLP (Natural Language Processing) _Microservices_ to get the meaning and intention of the user. Here we try to extract what the user wants from _BeuthBot_, to notify the right service and present a fitting answer to our user.+abstract class Service
  
-### Registry+class MensaService 
 +Service <|-- MensaService 
 +Service <|-- WetterService
  
-After obtaining the intention of our user, the _Gateway_ notifies the _Registry_, to get the information the user requested.+Registry "1" -- "*" Service 
 +</uml>
  
-The Registry distributes the request to the correct _Service_, that takes care of retrieving the right informations.+A user can write the //Bot// to request informations, the meaning of the message is extracted and a fitting //Microservice// is choosen to retrieve the necessary data. A response is build from that data and distributed back up to the bot which answers the users request.
  
-### Service+Following sequence diagram further illustrates that:
  
-_Service_ is an abstraction for the implemented _Microservices_ that retrieve the necessary data we need to answer users requests. E.g. the _MensaService_ is a _Microservice_ that can give informations about the current menu, filtered by a number of parameters, e.g. a vegan user.+<uml> 
 +Bot -> Gateway : request 
 +Gateway -> nlp : request 
 +Gateway <- nlp : request<message> 
 +Gateway -> Registry : request<message> 
 +Registry -> Service : request<message> 
 +Service -> Registry : response 
 +Registry -> Gateway : response 
 +Gateway -> nlp : response (text) 
 +nlp->Gateway : response (audio) 
 +Gateway -> Bot : response (text|audio) 
 +</uml>
  
-## API+=== Bot ===
  
-Because of the complexity of the single _Microservices_, every single _Microservice_ implements its own, distinct, API.+This is an abstraction for the available chatbots, e.g. a //Bot// for //Telegram// and another //Bot// for //WhatsApp//.
  
-But to answer a users request we use a unified, comprehensive API. Its basic idea is to pass a _Response_-Object trough the individual _Microservices_, which consists of the initial request, an answer as a response to the users request and informations about the user.+The user interacts with this //Microservice//, here she can request information and gets answers from //BeuthBot//. 
 + 
 +=== Gateway === 
 + 
 +The //Gateway// is the centerpiece of //BeuthBot// one could say. 
 + 
 +The //Bot// notifies the //Gateway// with the message it got from the user. 
 + 
 +The //Gateway// then uses NLP (Natural Language Processing) //Microservices// to get the meaning and intention of the user. Here we try to extract what the user wants from //BeuthBot//, to notify the right service and present a fitting answer to our user. 
 + 
 +=== Registry === 
 + 
 +After obtaining the intention of our user, the //Gateway// notifies the //Registry//, to get the information the user requested. 
 + 
 +The Registry distributes the request to the correct //Service//, that takes care of retrieving the right informations. 
 + 
 +=== Service === 
 + 
 +//Service// is an abstraction for the implemented //Microservices// that retrieve the necessary data we need to answer users requests. E.g. the //MensaService// is a //Microservice// that can give informations about the current menu, filtered by a number of parameters, e.g. a vegan user. 
 + 
 +==== API ==== 
 + 
 +Because of the complexity of the single //Microservices//, every single //Microservice// implements its own, distinct, API. 
 + 
 +But to answer a users request we use a unified, comprehensive API. Its basic idea is to pass a //Response//-Object trough the individual //Microservices//, which consists of the initial request, an answer as a response to the users request and informations about the user.
  
 Following class diagram further illustrates that: Following class diagram further illustrates that:
  
-![flow](../assets/response-request-api.png)+<uml> 
 +class Request { 
 +platform 
 +userId 
 +message: Message 
 +history: Trace 
 +metadata: KeyValueStore 
 +answer(): Response 
 +} 
 + 
 + 
 + 
 +class Message { 
 +id: unique 
 +evaluated: Meaning 
 +evaluate() 
 +} 
 + 
 +Request *-- Message 
 + 
 +Response -- Request 
 + 
 + 
 +class Response { 
 +request: Request 
 +answer 
 +history: Trace 
 +} 
 + 
 +class TextMessage { 
 +content 
 +} 
 + 
 +class AudioMessage { 
 +url 
 +}
  
 +Message <|-- AudioMessage
 +Message <|-- TextMessage
 +</uml>
 +<WRAP pagebreak></WRAP>
wiki/software/beuthbot/software-architecture.1575992430.txt.gz · Zuletzt geändert: 10.12.2019 16:40 von Christopher Lehmann

Seiten-Werkzeuge