Beyond Traditional Web Technologies for Locally Web-Services
Migration
Clay Palmeira da Silva
1 a
and Nizar Messai
2 b
1
University of Huddersfield, U.K.
2
Universit
´
e de Tours, France
Keywords:
The CUBE, Web Services, Multiple-Devices, User-Side, Service Synchronization.
Abstract:
COVID-19 raised our dependency on computers and mobile devices to perform daily tasks. Thus, we saw
a user face the challenges of managing multiple services/device environments. Therefore, this multiple ser-
vices/devices scenario becomes significant while we still face the lack of interoperability between operating
systems, services, and applications on devices. Additionally, big tech companies are fighting to pursue new
web technologies for their services. Additionally, they require more resources from devices to keep running.
Beyond that, we had to learn and adapt to a new set of server-side services for web meetings, such as Microsoft
Teams, Zoom, Google Meet, and Webex. However, we did not see any propositions on the user side for the
same web services that could continuously and undisruptive provides a similar user experience of web-service
migration in a multiple-devices scenario regardless of the operating system. Therefore, this paper focuses on
web services based on REST, RESTful, or GraphQL to analyze their performance using the System Usability
Scale. Additionally, we focus on a real-life experiment on multiple-device environments for synchronizing
web services’ user instances without continuously depending on a cloud-based system. We presented results
from 35 users, where we measured various metrics over the previously mentioned web services through three
different devices. Moreover, we revisited The CUBE architecture, enhancing features that allow us to obtain
new results. The results demonstrate that when the users used the CUBE, they had a better QoS experience,
low latency, and better response time. Moreover, the CUBE provides computational performance up to ≈69%
faster than the traditional cloud-based synchronization procedure.
1 INTRODUCTION
The year 2020 brings up upon us the complete neces-
sity of adopting new technologies, and this behavior
has become our new reality. We saw this new tech-
nological behavior in computer science users, usually
familiar with these technologies, and also for those
who do not dispose of previous training or adapta-
tion, which we will call here non-experienced users.
Moreover, the last couple of years proves that an en-
tire generation has become more dependent on web
services. In this context, a concept gained strength,
the Everything-as-a-Service (XaaS) provides us with
a broad set of services that make our days more com-
fortable. However, conscious or not, we increased our
dependency on cloud-based systems to manage these
web services, demonstrating how dependent we have
a
https://orcid.org/0000-0003-0438-581X
b
https://orcid.org/0000-0002-3784-101X
become.
In addition to the features of the cloud-based sys-
tems, we are living a reality where we have more pow-
erful mobile devices than ever before (Suckling and
Lee, 2017). However, we do not entirely explore these
devices’ capacities regarding processing, storage, and
security measures to use web services locally. More-
over, for most people, dealing with an environment
that requires managing multiple services or devices is
challenging.
Additionally, It is also necessary to deal with the
lack of interoperability between operating systems,
services, and applications. Moreover, we live in
a time of connectivity dependency (da Silva et al.,
2020). That means we are sometimes unaware of our
connection dependency on network systems or social
media. Thus, if we consider the user-side approach,
it is far more complicated to migrate a given web ser-
vice from one device to another without a cloud-based
system to ensure the conditions to keep the service
620
Palmeira da Silva, C. and Messai, N.
Beyond Traditional Web Technologies for Locally Web-Services Migration.
DOI: 10.5220/0012133100003538
In Proceedings of the 18th International Conference on Software Technologies (ICSOFT 2023), pages 620-628
ISBN: 978-989-758-665-1; ISSN: 2184-2833
Copyright
c
 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

running.
On the server side, to keep up with the neces-
sity of adapting web services regarding the scenario
of COVID-19, companies such as Google, Twitter,
Facebook, and Amazon already use REST and REST-
ful on their platforms and adopted new technologies
such as gRPC or GrapQL. However, the redevelop-
ment of services to the new paradigm is costly (Kus
et al., 2020). Furthermore, we faced the rise of mis-
cellaneous services with the same purposes, such as
Zoom, Livestorm, Google meets, Zoho Meetings, Mi-
crosoft teams, and Amazon chime, among others.
In such a services conflict scenario, to give an ex-
ample, suppose a user starts to use a given service,
a chat on Facebook or LinkedIn on a given device.
For any particular reason, it is necessary to change
the device. The new device needs a cloud-based sys-
tem to ensure the service can resume continuing the
task. However, despite the cloud-based system, it is
not guaranteed that the service will resume the user
instance on the new device. We may have a service
rupture due to interoperability issues in this case.
An alternative to server-side or cloud-based sys-
tem approaches can rely on client-side manage-
ment of multiple device service synchronization.
In (da Silva et al., 2018a), the authors proposed The
CUBE, a system-model architecture that addresses
the challenge of web services at the user side for
a multiple-devices and operating systems environ-
ment. The CUBE fully complies with Liquid Soft-
ware principles described in 1996 by (Hartman et al.,
1996). Most recently described in 2016 by (Gal-
lidabino et al., 2016) to allow for user-side ser-
vices synchronization and migration over multiple-
devices (da Silva et al., 2020).
In the work of Palmeira et al. (da Silva et al.,
2020), the authors presented a study of the CUBE’s
formal aspects, describing its technical improvements
with a feasibility test on tight-coupling web service
interaction from YouTube, providing some results
from a set of 10 users. However, the authors did not
provide further details regarding some aspects of their
architecture.
This paper focused on services based on REST,
RESTful, and GraphQL, such as Facebook, Google
Maps, Linked In, and Twitter, to analyze their perfor-
mance, considering a better user experience. More-
over, revisiting the CUBE, we also discuss how it
works this user-instance approach inside The CUBE
architecture (da Silva et al., 2018a). However, we fo-
cus only on the Pool Area {P
a
}, where the relation
{d
n
↔ s
n
} between devices {d
1
,d
2
,d
3
} and services
{s
1
,s
2
,s
3
,s
4
} occurs. Using the System Usability
Scale (SUS) for user experience, we presented results
from 35 users, where we measured various metrics
over the previously mentioned web services through
three different devices.
The remainder of this paper presents the follow-
ing structure: Section 2 brings our motivations and
contributions. Section 3 brings our perspective in
revisiting the CUBE architecture with the proposed
improvements. In the following, Section 4 presents
service integration and technical challenges, and Sec-
tion 5 presents the evaluation with commented results.
Section 6 discusses the related works from REST and
GraphQL perspectives. Finally, section 7 gives con-
cluding remarks highlighting our future research di-
rections.
2 MOTIVATIONS AND
CONTRIBUTIONS
Nowadays, web services are the central use of mo-
bile devices. Therefore, we are facing a real prob-
lem within a multiple-devices/operating systems en-
vironment. Moreover, we are thinking about services
running over multiple devices/platforms and how this
challenge has inspired researchers and industries. Be-
sides, we also have noted that all proposed solutions
rely on the server or cloud-based systems to synchro-
nize services data and state (da Silva et al., 2020).
Today, with all available technology and depend-
ing on the cloud-based system to make synchroniza-
tion, we can reproduce the scenario proposed in Fig-
ure 1, which is a migration of a given service across
a multiple-devices environment. However, to achieve
this scenario, all devices must have an internet con-
nection supported by a cloud-based system with an
account of the user on each platform to ensure the ser-
vice.
Figure 1: Data/State synchronization is managed by the
cloud-based system.
From a resource perspective, some devices are too
small or too big for a given service, e.g., a keyboard
on a smartphone needs to be bigger to write an email
for some users, requiring a device with an external
Beyond Traditional Web Technologies for Locally Web-Services Migration
621

Figure 2: Use case model describes our motivation scenario.
keyboard or a bigger screen. In this case, the user
should choose a more suitable ”device candidate” to
reproduce such a service. In this context, the CUBE
architecture (da Silva et al., 2018a) deals with these
challenges (da Silva et al., 2020). We want to ensure
one specific functionality, the user-instance migration
at the user side of a given service towards multiple
devices.
However, this user-instance migration on the user
side is challenging since we know that most web ser-
vices use APIs to enable all types of different dis-
tributed applications. All in cloud-oriented frame-
works, such as Google Cloud Platform. In this case,
REST-based approaches present some issues for inter-
face design, such as over-and-under fetching, as was
described by Dominik Kus et al. (Kus et al., 2020).
These shortcomings triggered the quest for new API-
related technologies, such as GraphQL. Despite the
flexibility of GraphQL, it presents some challenges
as a lack for integration capabilities (St
¨
unkel et al.,
2020).
The migration of a REST-based interface to
GraphQL or keeping interfaces in both styles is
costly (Kus et al., 2020; St
¨
unkel et al., 2020; Brito
and Valente, 2020). Therefore, it is required to adopt
middlewares such as the OpenAPI-to-GraphQL in-
troduced by Wittern et al. (Wittern et al., 2018) to
create a corresponding schema between REST and
GraphQL. However, how can users, experimented or
not, easily handle the front end with these web ser-
vices without being concerned with such technolo-
gies? We want to go beyond REST or GraphQL-
based APIs and deal with their issues in a run-time
context that is not bound to such technologies.
We aim to present web-services migration in a
multiple-devices environment regardless of the oper-
ating system. We graphically present our proposition
in Figure 2, where the user makes a connection with
the cloud-based system only once. Then they can
switch between devices while moving without service
disruption.
We addressed the user-instance migration chal-
lenge using the user-centric principle to provide a
simple solution for the user choosing a device accord-
ing to a personal interest in a run-time environment.
In the CUBE, all state/data/certificate control goes lo-
cally. We noted that this transfer is not a copy of
the service or something like that. The CUBE op-
erates within different layers and system modules to
work less dependent on the cloud-based system. For
this purpose, we revisited the CUBE model (da Silva
et al., 2018b), (da Silva et al., 2018a), (da Silva et al.,
2020), adding new features described hereafter.
• We refined the relation between devices and ser-
vices {d
n
↔ s
n
} on the Pool Area {P
a
} to overlap
technological issues as REST-based or GraphQL-
based.
• We abstracted the CUBE architecture to an appli-
cation deployed as a callback procedure inside the
operating system.
• We removed the necessity to have the services ap-
plications inside the CUBE for further use by the
user.
3 REVISITING THE CUBE
MODEL
First, it is necessary to recall some definitions of the
CUBE architecture briefly. Our focus here is on the
”space” between devices and services where acts the
Pool Area {P
a
}.
3.1 CUBE Model Essentials
The CUBE requires some essential elements for its
construction. We will focus on the fifth element, the
”one service,” which we will define as {OS}. We
noted that the formal description of the ”one ser-
vice” or the process migration was not previously dis-
cussed.
The {OS} occurs when the end user U starts to
access a Service s
1
using a device d
1
. This relation is
expressed by d
1
←→
OSs
1
.
We assumed that the end user U has more than one
mobile device at disposal d
1
and d
2
. However, service
migration is not already available. Let us represent the
mobile devices and service for U as: D
u
= {d
1
,d
2
},
S
u
= {s
1
}, and d
1
←→
OSs
1
, d
2
←→
OSs
1
but, for now, there
is no communication between the devices d
1
and d
2
.
That means, the process migration {Mig →} is not
available yet, d
1
¬{Mig →}d
2
. In this case, service
migration on the user side is not possible.
ICSOFT 2023 - 18th International Conference on Software Technologies
622

We also recalled the description of the INNER
CUBE (da Silva et al., 2020), described as a tuple in
Definition 3.1:
Definition 3.1. I
c
:= {d
p
,D
u
\ {d
p
},R
d
} where:
• d
p
is the current device being used by the end user
U.
• D
u
\ {d
p
} is the set of discovered devices owned
by the user end U ready to use.
• R
d
is the research mechanism for devices.
Once the INNER CUBE is built, the set of discovered
devices can communicate with each other. Therefore,
the process migration {Mig →} is online, {d
1
Mig →
d
2
,Mig → d
3
,...,Mig → d
n
} is true.
Now, let us denote by ”↔” a connection be-
tween any device and any service: that is d ↔ s
means device d has established a connection to ser-
vice s (da Silva et al., 2020).
We also recalled the definiton of the OUTER
CUBE (Definition 3.1), denoted by O
c
, as the set
of Services S for which a connection has been estab-
lished with a device in the INNER CUBE, I
c
(da Silva
et al., 2020).
Definition 3.2. O
c
:= {s
i
∈ S such that ∃d
i
∈ D
u
and d
i
↔ s
i
}. where:
• s
i
is any current service being used by the user end
U.
• d
i
is any current device being used by the user end
U.
• D
u
is the set of discovered devices owned by the
user end U ready to use.
Now it is possible to focus on describing how the ele-
ments of the Pool Area acts. Therefore, in the follow-
ing subsection, we tackle the first contribution of this
paper.
3.2 Contributions
Since we have described the one service
←→
OS, we are
improving new concepts to the previous definition of
the Pool Area (da Silva et al., 2020). Therefore, by
Definition 3.2, we are redefining the Pool Area as P
a
,
as the set of relationships established between any de-
vice d
i
in I
c
and any Service s
i
in O
c
.
Definition 3.3.
P
a
= {d
i
←→
OSS
i
such that d
i
∈ I
c
and s
i
∈ O
c
}.
where:
1.
←→
OS that establishes the connection between device
and service, is revisited as:
2.
←→
OS
β
{d
1
Mig → d
2
} for connections between de-
vices and services with the CUBE.
3.
←→
OS
α
d
1
¬{Mig →}d
2
for connections between de-
vices and services without the CUBE.
Let us now describe how is expressed the complexity
of item 3 on the Definition 3.3 since there is no service
migration nor communication between devices. It is
expressed by
n
∑
i=1
d
i
m
∑
j=1
s
i
= (d
1
+ d
2
+ ... + d
n
).(S
1
+
S
2
+ ... + S
m
). On the other hand, item 2 of the same
definition 3.2 presents less complexity, expressed by
n
∑
i=1
d
i
= d
1
+ d
2
+ ... + d
n
.
3.3 Discussing the Model-Scenario
Representation
The following use-case, shown in Figure 3, uses dif-
ferent web services based on REST or GraphQL. We
provided a detailed perspective of these elements re-
garding the positioning of the CUBE in this new con-
text.
We revisited the scenario representation presented
in (da Silva et al., 2020) to discuss how our proposed
improvements to the CUBE architecture allow for a
better user experience. We consider this point a key
feature of our contribution.
Figure 3: Our second feasibility test scenario of the CUBE.
To start, we must assume three conditions:
1. The user-end chooses a connected mobile as their
first device;
2. Users decided to run any service from the set
(Facebook, Twitter, LinkedIn, or Google Maps);
3. The user launches a given service from a web
browser or a native application
Adding new devices to the CUBE is still the same
as before. The user manually selects the devices
to the INNER CUBE (I
c
) (Definition 3.1). Then,
the synchronization process creates the CUBE ses-
sion. We note that these are the only similarities
between the underlying processes for the work pre-
sented in (da Silva et al., 2020).
The runtime instance of the CUBE runs as a call-
back inside the operating system. Thus, using device
d
p
, the user requests a service s
i
∈ S, e.g., start a chat
from Facebook or LinkedIn.
Beyond Traditional Web Technologies for Locally Web-Services Migration
623

Once the user starts the service on the (d
1
), she/he
can migrate the service instance to another device (d
2
or d
3
) using the button present on the browser or in-
side the native app. Since the process migration is
available {Mig →}, the user can retrieve the exact
moment of their instance without service disruption.
Thus, callback procedures will automatically up-
date the CUBE elements, the INNER CUBE (I
c
), Pool
Area (P
a
), and OUTER CUBE (O
c
). Therefore, al-
lowing the user to freely handle the migration of ser-
vices towards any device that belongs to them.
4 SERVICE INTEGRATION AND
TECHNICAL CHALLENGES
The results we presented in (da Silva et al., 2018b;
da Silva et al., 2020) encouraged us to go further and
tackle the challenges we found. Thus, we decided to
explore the boundaries and limitations of the REST-
based and GraphQL-based approaches to enhance our
proposal for a scenario where the technology behind
a given web service cannot interfere with the end-user
experience.
For this purpose, it was necessary to change the
underlying code and project the CUBE as a reposi-
tory. Thus, we comply with our second contribution
to this paper. To recall, we proposed abstracting the
CUBE architecture to an application and deploying it
as a callback inside the operating system. We pre-
sented in Figure 4 the context of how the user end can
directly interact with different web services easily and
efficiently through the CUBE.
Figure 4: The representation of the second feature of this
paper shows how the user end interacts with web services
through the CUBE.
The improvement mentioned in the previous sec-
tion regarding the CUBE in the run-time environment
made us realize that the logical dock, once used to de-
ploy the services presented in (LiquidMail (da Silva
et al., 2018b) and LiquidTube (da Silva et al., 2020))
become deprecated. However, we retain all of the
functionalities already mentioned in the author’s pre-
vious works. Since we no longer need the logical
dock to deploy services, we realized that it makes
the CUBE more efficient for managing services, es-
pecially for the non-experienced user.
We reached some successful migrations regard-
ing the meeting services, such as Microsoft Teams.
We successfully migrated an ongoing meeting to an-
other device in the same scenario. Issues regarding
protocols TCP and UDP associated with WebRTC
maybe jeopardize the simulation. For now, we cannot
precisely describe the unstable error that we found.
Therefore, since we could not consistently reproduce
such migration in our tests, we preferred, for now, to
see it as a work in progress.
5 EVALUATION
For the evaluation, we followed the same as the au-
thors mentioned in (da Silva et al., 2020)). We sent
the test through the CUBE. The end user randomly
chose the user instance without a third party synchro-
nizing it. In this feasibility test, we used three differ-
ent devices. Device one (d
1
), a desktop HP Pentium
Dual-Core 3GHz, 8GB Ram, and a Windows 7 64bits
Professional. The device two (d
2
), a Tablet Sam-
sung A6 Chipset Exynos 7870 octa-core 1.6GHz, Wi-
Fi 802.11 a/b/g/n, and Wi-Fi Direct, Bluetooth v4.2
LE-A2DP with Android 8.0 Oreo. The device three
(d
3
), an iPad 32GB, Chipset 1Ghz Single-Core ARM
Cortex-A8, Wi-Fi 802.11 a/b/g/n (2.4Ghz), Bluetooth
2.1-A2DP with iOS 4.0.
With a set of thirty-five persons with no prior
training with the CUBE, the test consists of starting
any service from the set (Facebook, Twitter, Linked
In, Google Maps or Microsoft Teams) on the device
one d
1
(Desktop Windows). Then, migrate by click-
ing on the extension icon in the browser on d
1
to mi-
grate the user-instance to d
2
(Tablet Android) with
the actual content (context/interface/data). In the se-
quence d
2
sends the content to d
3
(Tablet iOS). This
sequence can repeat towards any other device until re-
turning to the first device, d
1
(Desktop Windows). We
note that the user must migrate the service to three dif-
ferent devices. Figure 5 shows the steps on different
devices. The considered interactions are those only
between d
1
until d
3
.
Figure 5: The service’s content is fluently moved around a
different set of devices D owned by the user-end.
Regarding data integration challenges due to re-
quests from services with different bases (REST
or GraphQL), we evaluate each device group’s la-
tency by minimum, maximum, average, median,
ICSOFT 2023 - 18th International Conference on Software Technologies
624

and jitter as a metric inside the underlying la-
tency. Since we had online interactions, we pro-
vided a sample of the user-instance migration for
the mentioned services in the following link htt ps :
//www.youtube.com/watch?v = 9en1aue
8
qU .
5.1 Results
Here we decided to separate our analysis due to the
inconsistency found on Microsoft Teams. Therefore,
we have two sub-sections with the respective infor-
mation.
5.1.1 Social Media Services
Since we have considered enhancing the migration
process of the CUBE, it was necessary to measure the
end user sentiment about using the CUBE as the or-
chestrator of web services. Moreover, we needed ob-
jective metrics about how services required network
infrastructure with and without the CUBE was neces-
sary since this was also the scope of our contributions.
From the perspective of a SUS metric for user ex-
perience, we present a set of graphics in Figure 6,
each with a different metric. In (a) the analysis re-
garding usability. In (b), the perceived satisfaction
(PSSUQ) with three subconstructs. In (c), the usabil-
ity analysis from the SUMI model within three sub-
constructs. In (d), the QUIS model analyzes the in-
teraction satisfaction also within three subconstructs.
Finally, in (e), the website quality from WEBQUAL
is within three subconstructs.
Considering the latency with the following met-
rics: minimum, maximum, average, median, and
jitter, we achieved an enhancement an average on
the following results with the synchronization on the
client side (CliSi) over the server side (SerSi): 3,09ms
(CliSi) against 6,19ms (SerSi) represents 50% faster
for the minimum latency, 8,86ms (CliSi) against
28,83ms (SerSi) represents 69,26% faster for the
maximum latency, 5,74ms (CliSi) against 18,33ms
(SerSi) 68,68% faster on average, and 5,68ms (CliSi)
against 19,69ms (SerSi) represents 71,15% faster on
the median average. Figure 7 (a) shows the metrics
obtained with the synchronization by the Server-side.
On the other hand, (b) presents the synchronization
at the Client-side provided, which CUBE orchestrates
the migration.
Regarding this latency aspect over the devices, it
was possible to identify that client-side synchroniza-
tion allows for a lower average latency between de-
vices, which is the complete opposite on the server
side since there is a higher dependency on the net-
work infrastructure necessary to migrate the services.
(a)
(b)
(c)
(d)
(e)
Figure 6: We present the evaluation from a SUS perspective
in five different measurements.
The achieved abstraction of service migration
with both tight and loose-coupling services within
different server-side implementations, such as REST,
RESTful, or Graph-QL, allows our contribution to ex-
ploring user-instance orchestration in multiple device
scenarios without concerns regarding programming
languages or frameworks.
5.1.2 Online Meeting Services
As previously mentioned, we have managed some mi-
gration of online meetings using Microsoft Teams.
At some level, most of the users from the test set
achieved the migration, but with some disruptive fail-
Beyond Traditional Web Technologies for Locally Web-Services Migration
625

(a)
(b)
Figure 7: We presented the latency from network analysis
comparing server-side vs. user-side synchronization.
ures. We looked back at the improvements proposed
at the Pool Area to understand if was some modifica-
tion in our proposition. However, we realized the dis-
ruptive condition was previous to our modifications.
However, since we achieved such functionality, even
if it was not stable enough during the tests, it is fea-
sible for future research topics on service migration
orchestrated on the user side.
6 RELATED WORK
We present in this section the contributions regard-
ing the challenges of REST, RESTful, and migration
to GraphQL. Technically speaking, we managed to
avoid the challenges presented by the authors with the
abstraction of the CUBE architecture, as we proposed
in our contributions.
The work of Palmeira et al. (da Silva et al., 2018a;
da Silva et al., 2018b; da Silva et al., 2020) requires
some user manipulation, directly impacting the us-
ability. Moreover, they need a dock to anchor the
services (e.g., LiquidMail and LiquidTube). Thus,
we could abstract this docker constraint and make
the procedure more intuitive with buttons on browsers
and native apps. Additionally, we revisited the Pool
Area proposed by the authors to enhance their func-
tionality of service migration to help further develop-
ment requirements on our client-side approach.
The OpenAPI-to-GraphQL was introduced by
Wittern et al. (Wittern et al., 2018) as a language for
web applications at the server side, promoting a new
perspective for developers and applications that make
use of the REST-based platform. Their results demon-
strate a trend with challenges up ahead. Regarding
the challenges that address the migration or trans-
lation process from REST-based to GraphQL-based,
the study conducted in (Kus et al., 2020) presents a
link generator for increasing the utility of OpenAPI-
to-Graph translations by creating a wrapper based on
its documentation.
Challenges regarding migration from REST to
GraphQL are also presented by Brito and Va-
lente (Brito and Valente, 2020), where their results
demonstrate that GraphQL is more comfortable to im-
plement over REST, with measured performances be-
tween participants.
Another approach to enhancing GraphQL-based
solutions is introduced in (D
´
ıaz et al., 2020), where
authors propose an application GrapCoQL, which en-
hances the techniques presented in (Hartig and P
´
erez,
2018).
An exciting approach in (Luscher, 2016) deals
with GraphQL at the client side, proposing a solution
to inject a custom relay-local schema. However, since
we have higher network demand for the underlying
REST API, the author suggests moving the schema
from the client side to the server side to reduce la-
tency issues.
The work presented by St
¨
unkel et al. explains the
main differences and challenges between SOA sys-
tems with integration on the service level and Mi-
croservice architecture that encourages decoupling,
where data integration is a common issue. During
the running test phase, we noticed no data integra-
tion problems. Therefore, our achievement makes us
optimistic about future directions.
7 CONCLUSIONS
During the pandemic of the COVID-19, we saw
many web services become more familiar to a non-
experimented user. In this context, Social Media and
online meeting services have become a trend. How-
ever, most of the services proposed by different com-
panies are similar regarding online meetings. There-
fore, the user needs to learn or still does to use them.
We can add to this chaotic scenario the lack of
compatibility and interoperability of the most recent
technologies, such as REST, RESTful and GraphQL.
We realized that the transition would take a while
due to data integration and query complexities in both
senses. To tackle this from a more abstract perspec-
tive, we presented an enhancement of the CUBE ar-
chitecture to go beyond the technological limitations,
which impose constraints on developers, retailers, and
industry.
In this paper, we described some of the main chal-
lenges regarding the approaches to convert REST-
ICSOFT 2023 - 18th International Conference on Software Technologies
626

based to GraphQL-based schemas. They mainly con-
verge to solutions that require additional effort or con-
tent transfer to a server-side due to the high request
over the network infrastructure. Moreover, the ap-
proaches deal with migration that not involves the
non-experimented user or, even more, any optimal
synchronization on the client side.
We focus our approach on two main objectives.
First, propose an enhancement on the Pool Area of the
CUBE architecture, with a more clear mathematical
formalism to make it easy to develop and integrate so-
lutions on the already defined architecture. After that,
we focused on evaluating the user experience and net-
work latency, mainly on the non-experimented user.
We successfully migrated social media services in
a multiple devices environment with positive results
regarding the latency in a network system while or-
chestration runs on the user side. On average, the
client-side orchestration provided by the CUBE al-
lows for a faster service migration experience, with
68,68% faster over the server side. Moreover, it is
possible to notice on the client-side graphic that la-
tency is more balanced, opposite to the latency of
the server side, which demonstrated a higher variation
due to network infrastructures.
We partially achieved online meeting service mi-
gration in the same environment. Thus, we saw that
achievement not as a failure but as a positive achieve-
ment that required more investigation and perspec-
tives on the user side development. Therefore, we ad-
vocate synchronization on the client side as an alter-
native to the classic server-side synchronization. This
approach’s main advantages rely on having REST and
GraphQL running simultaneously without interoper-
ability or data integration issues, as we found in our
test with thirty-five users. Furthermore, infrastructure
failures could lead to fewer network requests without
service disruption. Consequently, we can assume a
reduction in energy consumption of network servers
infrastructure.
We also realized that The CUBE could be scal-
able, where a higher number of devices can be added
to its microsystem to perform service migration with-
out compromising performance. Moreover, since we
successfully added it to the operating system, its fea-
tures can be used for a more extensive set of devices
from different users. It will require some assessments
of the architecture to provide such a feature.
Finally, as future works, we are considering tack-
ling challenges raised during the migration on the on-
line meeting, such as those we performed in Teams.
The CUBE architecture worked with some limita-
tions. Thus, we considered starting to notate services
and devices to create an ontology-based notation to
propose to the non-experimented user a better migra-
tion to a given device of a given service. Addition-
ally, we can enhance user devices to provide some
services, particularly those using IA. Therefore, the
federated learning area raises a challenge when the
synchronization goes on the user side. Moreover,
scaling The CUBE over devices from different users
opens the possibility of applying The CUBE architec-
ture on Smart City applications spread over the FOG
and EDGE infrastructure.
REFERENCES
Brito, G. and Valente, M. T. (2020). REST vs graphql: A
controlled experiment. In 2020 IEEE International
Conference on Software Architecture, ICSA 2020, Sal-
vador, Brazil, March 16-20, 2020, pages 81–91, Sal-
vador, Brazil. IEEE.
da Silva, C. P., Messai, N., Sam, Y., and Devogele, T.
(2018a). Cube system: A rest and restful based plat-
form for liquid software approaches. In Majchrzak,
T. A., Traverso, P., Krempels, K.-H., and Monfort, V.,
editors, Web Information Systems and Technologies,
pages 115–131, Cham. Springer International Pub-
lishing.
da Silva, C. P., Messai, N., Sam, Y., and Devogele, T.
(2018b). Liquid mail - A client mail based on CUBE
model. In 38th IEEE International Conference on Dis-
tributed Computing Systems, ICDCS, Vienna, Austria,
July 2-6, pages 1539–1540, Vienna, Austria. Institute
of Electrical and Electronics Engineers (IEEE).
da Silva, C. P., Messai, N., Sam, Y., and Devogele, T.
(2020). User-side service synchronization in multi-
ple devices environment. In Bielikov
´
a, M., Mikkonen,
T., and Pautasso, C., editors, Web Engineering - 20th
International Conference, ICWE 2020, Helsinki, Fin-
land, June 9-12, 2020, Proceedings, volume 12128 of
Lecture Notes in Computer Science, pages 451–466,
Helsinki, Finland. Springer.
D
´
ıaz, T., Olmedo, F., and Tanter,
´
E. (2020). A mechanized
formalization of graphql. In Blanchette, J. and Hritcu,
C., editors, Proceedings of the 9th ACM SIGPLAN
International Conference on Certified Programs and
Proofs, CPP 2020, New Orleans, LA, USA, January
20-21, 2020, pages 201–214, New Orleans, LA, USA.
ACM.
Gallidabino, A., Pautasso, C., Ilvonen, V., Mikkonen,
T., Syst
¨
a, K., Voutilainen, J.-P., and Taivalsaari, A.
(2016). On the architecture of liquid software: Tech-
nology alternatives and design space. In 2016 13th
Working IEEE/IFIP Conference on Software Architec-
ture (WICSA), pages 122–127, Venice, Italy. IEEE.
Hartig, O. and P
´
erez, J. (2018). Semantics and complex-
ity of graphql. In Champin, P., Gandon, F. L., Lal-
mas, M., and Ipeirotis, P. G., editors, Proceedings of
the 2018 World Wide Web Conference on World Wide
Web, WWW 2018, Lyon, France, April 23-27, 2018,
pages 1155–1164, Lyon, France. ACM.
Beyond Traditional Web Technologies for Locally Web-Services Migration
627

Hartman, J., Manber, U., Peterson, L. L., and Proebsting,
T. (1996). Liquid software: A new paradigm for net-
worked systems. Technical report, University of Ari-
zona, Tucson, AZ, USA.
Kus, D., Koren, I., and Klamma, R. (2020). A link gen-
erator for increasing the utility of openapi-to-graphql
translations. CoRR, abs/2005.08708.
Luscher, S. (2016). Wrapping a rest api in graphql.
St
¨
unkel, P., von Bargen, O., Rutle, A., and Lamo, Y. (2020).
Graphql federation: A model-based approach. J. Ob-
ject Technol., 19(2):18:1–21.
Suckling, J. and Lee, J. (2017). Integrating environmen-
tal and social life cycle assessment: Asking the right
question. Journal for Industrial Ecology, 1.
Wittern, E., Cha, A., and Laredo, J. A. (2018). Generating
graphql-wrappers for rest(-like) apis. In Mikkonen,
T., Klamma, R., and Hern
´
andez, J., editors, Web Engi-
neering - 18th International Conference, ICWE 2018,
C
´
aceres, Spain, June 5-8, 2018, Proceedings, volume
10845 of Lecture Notes in Computer Science, pages
65–83, C
´
arceres, Spain. Springer.
ICSOFT 2023 - 18th International Conference on Software Technologies
628