![](bg9.png)
When a meeting has been agreed between agents
or in the worst case, by the users themselves, the
Register Meeting Service store in the database the
new agreed meeting and send PUSH notifications for
confirming the new event to the participants. This
Service is invocated for the agent through the
Environment Artifact when the negotiation has been
concluded.
A meeting request can include files like word
processing documents, spreadsheets or presentation
files, the File Service is the responsible for storing
and recovering that files when a new meeting is
registered or when some of the previous registered are
modified. Through the user interface a user can
request the attached documents, and they are sent to
this service.
The User Service permits authenticate a user,
store preferences of each one and maintains
information for linking users, devices and agents
through the framework.
3.2.3 PUSH Notification Service
In this framework, we assume that agents, its
environment artifacts, and microservices reside on
well-known servers. And given this assumption is
easy for user devices locating the microservices
servers and these find and communicate with agents
and artifacts.
However, when an agent needs to communicate
with the user devices, specifically with non-always
connected devices, like Web applications, Mobiles,
and Wearables, only the Microservices Layer is not
sufficient. For this reason, another component is
necessary, the PUSH Notification Service.
A PUSH Notification service is a kind of server
software that can feed notifications to devices and
web applications, even when not always connected.
For doing its job, when an App is installed on the
device, this is registered in the PUSH platform, and
an ID Token is assigned for it when is necessary to
contact the device, the platform could do it through a
resident mini-server installed on the device and the
appropriate ID Token.
This mini-client is installed as a service when the
App is installed on mobile and wearable devices and
is requested to the user to subscribe it when he enters
for the first time to a web application.
These notifications are not necessary in a context
of a Desktop Platform, given an Application could
always be connected to the server.
This layer is the most commonly used in
commercial applications on mobile, wearable and
web applications nowadays.
3.3 Agent Environment Layer
The Agent Environment Layer is a set of Java Classes
compatible with CArtAgo framework specification.
A BDI Agent like Jason Agents works with mental
attitudes like Beliefs, Desires and Intentions, Beliefs
and Plans in Jason. In other hand user interfaces on
devices maintains and understand multimodal
communication events and EMMA data which are
routed to Microservices for reach to the Agents.
The principal job of this layer is to create a virtual
environment for the agents and through it,
communicating with real-world environments.
It must receive events from agents and translate
them to requests for the appropriate microservice for
routing event and data to the user.
In another hand when a user requires for an action
from the agents, or respond to a previous information
questioning, the EMMA annotated data must be
translated to events and register or remove beliefs in
the mental state of the agents.
For doing its translate job an EMMA -
(Event/Beliefs) Encoder/Decoder is incorporated into
the artifact. For actions required from a user, the
translation is an event for trigger plan execution on
Agents. When data is proportionated from the user, a
Beliefs Update is necessary, for add or remove beliefs
of an agent. When the action is required by the agent,
event and beliefs are encoded into an EMMA
annotation and sent to the device through a PUSH
notification.
Given the middleware nature of these
components, they must understand two different
domains, the agent domain based on beliefs, plans
and goals, and the microservice domain, based on
API utilization through REST requests.
3.4 Intelligent Multiagent System
Layer
This layer is the one which encapsulates the
“Intelligent” behaviour of the framework. It
represents the Multiagent System, the reason for
design and construction of the overall architecture.
An Intelligent Multiagent System in our
framework is compositing of BDI Agents; this layer
is composed of Jason Agents that communicate
between them using Speech Acts. Each Agent has a
mental state, based on attitudes like Beliefs, Desires,
and Intentions.
In this framework, each user has assigned an
Agent who is listening for requests of actions like:
▪ Sending the oncoming meetings of a certain
period.
HAMT 2018 - Special Session on Human-centric Applications of Multi-agent Technologies
326