Page 97 - ITU Journal Future and evolving technologies Volume 2 (2021), Issue 5 – Internet of Everything

ITU Journal on Future and Evolving Technologies, Volume 2 (2021), Issue 5

endpoints have been de ined, where each route is asso‑
ciated with a FaaS function. When the gateway receives a
request, it identi ies the corresponding routing con igura‑
tion by calling the relevant FaaS function. Fig. 3 shows the
gateway work low. When the user at a given time needs
to request information, they will forward a message to the
gateway. Herein, let us assume that the user is already au‑
thenticated; at the time of sending the request, a POST call
is made to the URL / API / createHook. This URL takes
care of creating the WebHook to use for communicating
(conversing) with the cloud functions. The WebHook con‑
sists of two basic parts: a token and an event. The token is
Fig. 1 – ChatBot‑enabled VU in the Lysis architecture
generated during the creation of the WebHook and is used
to authenticate the communication, lasting for a prede‑
ined amount of time; if this cannot be authenticated the
call is stopped. The event, on the other hand, becomes the
topic. Whenever the endpoint receives signed data from
the chat service correctly, the gateway has to respond im‑
mediately with an HTTP status code; if everything went
smoothly, it generates a code 200 (OK), 201 (created) or
202 (accepted). However, if the data is not signed cor‑
rectly or even the signature is missing, it responds with
a 403 code (forbidden) and does not provide the broker
with the needed data. To protect transactions between
servers, it is convenient to use SSL / TLS.
This described architecture is integrated in the Lysis IoT
platform so that the outcome of the functions is taken by
the VU to perform the resulting tasks. The following are
the different needed functions: Message Handler; Action
Service; Save Conversation; Send Message; Failure Han‑
dler; and Save Logs. These are brie ly presented in the
following.

Fig. 2 – The propose chatbot architecture

understand what events are associated with these. In par‑
ticular, in the developed solution, we have adopted the
Dialog low service. The resulting event is then commu‑
nicated to the gateway (through the edge layer), which
takes care of sending it to the interface that then stores it
in an event queue waiting for the dispatcher to direct it to
the needed function. Indeed, there is a different function Fig. 3 – Process low for the whole system
for each event or group of events that is activated when a
given event is received. At this moment, a search is then 4.1 Message Handler
carried out to understand if there is already an active in‑
stance for this function; if not, a new instance of this func‑ If the gateway gives the green light, it stores the input in
tion is activated, the event status is temporarily saved and an event queue and then processes it as soon as possible.
then inally the function instance is destroyed once it is The various topics provided allow for calling the related
no longer needed. The functions to be implemented do functions. In the case of a request generated by the user,
not have to be all accessible via a gateway route; in fact, then the topic will be msg_ received which calls the Mes‑
it will be suf icient to make them accessible via a speci ic sage Handler function; this is the only function that can be
topic. In this way it is easier to manage the planned events called directly from the gateway interfaces. This function
also considering the interaction between the same func‑ processes the request and creates the output to be pro‑
tions. The gateway is an HTTP server in which routes and vided to the user. The construction of the output takes
place in various stages and on the basis of the user’s request.

© International Telecommunication Union, 2021 85