wiki.ziemers.de

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
===== Software Architecture =====

==== Table of content ====

	- [[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]]

==== Overview ====

//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.

> Bot <=> Gateway <=> Registry <=> Service

Following diagram shows that in more detail:

<uml>
abstract class Bot
class TelegramBot
class TwitterBot 

Bot <|-- TelegramBot
Bot <|-- TwitterBot

class Gateway
class MetaMetaPersistence
class MetaPersistence

package nlp {

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"
}

Gateway -- nlp

Bot "1..*" -- Gateway

Gateway -- MetaMetaPersistence

class Registry

Gateway "1" -- "1" Registry
Registry -- MetaPersistence

abstract class Service

class MensaService
Service <|-- MensaService
Service <|-- WetterService

Registry "1" -- "*" Service
</uml>

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.

Following sequence diagram further illustrates that:

<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>

=== Bot ===

This is an abstraction for the available chatbots, e.g. a //Bot// for //Telegram// and another //Bot// for //WhatsApp//.

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:

<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.ziemers.de

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Seiten-Werkzeuge
