TEM Journal. Volume 7, Issue 4, Pages 842-848, ISSN 2217-8309, DOI: 10.18421/TEM74-23, November 2018. Integrating Third-party Services Using Brokers in the Serious Games’ Domain Stefan Dimitrov Stavrev 1, Todorka Zhivkova Terzieva 1, Angel Atanasov Golev 1 1 Faculty of mathematics and informatics, Plovdiv University “Paisii Hilendarski”, 24 Tsar Asen, 4000 Plovdiv, Bulgaria Abstract – In this paper we demonstrate how to brokers are linearly scalable, able to work in nodes integrate 3rd party services in serious games. We use and even in the cloud [13]. However, their message queue broker and micro-services in a application in the video games industry and in the publish/subscribe manner in order to use real-time 3rd serious games domain in particular has remained party data into a serious game’s logic. First, we discuss somewhat limited. Multi-player servers still rely on the benefits of service oriented architecture. Then, we analyse and compare different message queues brokers the request/response paradigm. Services and service in terms of data latency, throughput, fail-tolerance and oriented architecture [2], on the other hand, is an scalability for the purpose of serious games. As a emerging trend in the field of serious games sequence, we apply those best practices from other development. domains in the field of Serious Games (SGs). Finally, we summarize the presented ideas and comparisons 2. Previous work and draw conclusions. Recent research in the field of Serious Games is Keywords – Serious games, Message oriented middleware, systems integration, message queue. conducted on architecture that is oriented entirely towards services [4,3]. Service-Oriented Architecture (SOA) is a set of practices for architectural design of 1. Introduction software that exploits services as loosely coupled Message queues (MQ) have been around since the components orchestrated to deliver various 80’s. They have the benefit of handling and functionalities. The SOA paradigm is not well exchanging large amounts of data between different established in the SG domain, yet. The components systems. They have already been successfully provide independent services to other components of applied in various domains – handling transactions in the serious game or application. The key principles in bank institutions and stock exchange, handling real- this particular design are modularization and re-use time messages for social networks like Facebook and of functionalities. That concept in not new in the LinkedIn. Message queues are used in operating field of computer science but is relatively rarely systems to route mouse and keyboard input. MQ applied, yet, in the field of games and serious games in particular [10,11]. Additional benefit of using services is the lack of compile-time dependencies. DOI: 10.18421/TEM74-23 Moreover, it is entirely possible to have the core https://dx.doi.org/10.18421/TEM74-23 gaming as a service in a centralized server. But the biggest advantage remains the re-use of components Corresponding author: Stefan Dimitrov Stavrev, [7] - shared user profiles, knowledge databases on Faculty of mathematics and informatics, Plovdiv learning topics, natural language processing dialog University “Paisii Hilendarski”, Plovdiv, Bulgaria services, exchanging scores between different game Email: [email protected] instances. Of course, the SOA approach is not Received: 28 July 2018. without shortcomings. Some of the challenges are Accepted: 22 October 2018. that the quality assurance and testing module Published: 26 November 2018. integration tend to be more difficult when developing SOA applications. In addition, sometimes the lack of © 2018 Stefan Dimitrov Stavrev, Todorka documentation on the usage of interfaces makes Zhivkova Terzieva, Angel Atanasov Golev; published by integration with a certain service difficult. UIKTEN. This work is licensed under the Creative Furthermore, extra attention to services description Commons Attribution-NonCommercial-NoDerivs 3.0 needs to be kept in mind. Another limitation of the License. SOA approach is that the game needs to be The article is published with Open Access at constantly online, i.e. connected to a certain service www.temjournal.com or services. That last restriction makes the 842 TEM Journal – Volume 7 / Number 4 / 2018 TEM Journal. Volume 7, Issue 4, Pages 842-848, ISSN 2217-8309, DOI: 10.18421/TEM74-23, November 2018. architecture less flexible. Finally, there is the context, there are several broker metrics that are additional performance cost due to network calls. important for us: Some of those shortcomings can be avoided by Throughput of messages getting service data in a publish/subscribe manner instead of direct request/reply [13]. The Low-latency publish/subscribe methodology is a well know Number of protocols supported out of the programming paradigm in the field of computer box science - it allows loose coupling between system Number of features supported out of the box components [1]. It has been successfully applied in Fault-tolerance and data recovery various domains where complex subsystems, Scalability possibly written in different programming languages, A very good collection and description of different need to exchange information [5]. An additional messaging systems is put on [21]. However, since benefit is that the constant internet connection there are too many brokers available and each of problem in no longer a requirement by using a them is created for a different purpose, we are not message queue in between the game and the 3rd going to compare them directly. Instead, we will party service. investigate 3 of the most popular, general purpose Message queues are middleware systems that brokers. The 4-tier architecture that we propose later enable developers to have fault-tolerant, distributed, in this paper allows for changing the broker at any decoupled, service oriented architecture. But why not time with little configuration. use traditional request/response pattern for serious games? First, let us take a closer look at the problem 3.1. ActiveMQ we are presented with. The typical requirements are that SGs should be light, decoupled, possibly run on The first broker we will investigate is Apache low-end hardware, be easily scalable and make use ActiveMQ [22]. It is written in JAVA and is based of 3rd party services [10, 11]. Using a traditional on JMS [14]. It is open source, under the Apache 2.0 request/response pattern (REST, for instance) from license. Because the broker is JMS-based, it supports inside the game logic will put additional demand on 2 types of messaging: topic based and queue based. the hardware resources which we want to avoid. The The queue based messaging is point-to-point: a constant requesting whether there is new data sender (or also known as publisher) sends a message available from the 3rd party server is a cumbersome to a queue and the message is received by exactly operation. An event-driven server architecture (with one receiver. The other type of messaging is web-sockets, for instance) can potentially solve the publish/subscribe: a publisher sends a message to a constant data polling demand but still the game logic topic and all subscribers to that topic are going to will be tightly coupled with the 3rd party services. receive it. ActiveMQ supports several wire level That in turn sacrifices application scalability. On the protocols: OpenWire, STOMP, MQTT, REST other hand, real-time data is highly dynamic by (HTTP GET/POST), AMQP [6]. ActiveMQ supports nature. In the event of a network failure, 3rd party 3 types of message persistence: AMQ message store data will be lost. Another advantage of using MQs (fast read-write), non-journaled JDBC [15] (reliable over traditional direct messaging is their but not fast) and journaled JDBC (reliable and faster asynchronous nature, which allows us to put a than JDBC). Last but not the least, ActiveMQ offers message on the queue without processing it a nice web-console to monitor and manage the broker immediately. traffic in real-time. 3. Previous work 3.2. Kafka Adding a MQ broker in between the game logic and the 3rd party service solves some of the The next on the list is Apache Kafka. It is a broker integration problems with SOA. However, there is a written in SCALA. Kafka is a persistent, distributed, number of messaging brokers available; most of replicated publish/subscribe messaging system [23]. them are open-source, others are proprietary. When It typically consists of a cluster of brokers. The it comes to choosing the right one we must keep in brokers are stateless, i.e. consumers maintain their mind that there is no silver bullet – no one single own state (with the help of ZooKeeper [27] by solution can fit all requirements [16]. That is why default). Kafka has only topics, which can be tuned we will briefly compare the most widely-used to act as queues if needed. For message transport, brokers and pick one to be used with our SGs Kafka uses its own binary protocol over TCP. Clients architecture – DiAS [12]. In addition, we must keep can interface with the broker via web sockets. in mind the individual broker’s design intent. In that Apache Kafka has fewer features out of the box – it is built for performance and high throughput. Kafka TEM Journal – Volume 7 / Number 4 / 2018. 843 TEM Journal. Volume 7, Issue 4, Pages 842-848, ISSN 2217-8309, DOI: 10.18421/TEM74-23, November 2018. is created with horizontal scaling in mind. footprint and it makes it ideal for today’s “Internet of Unfortunately, Apache Kafka ships with built-in Things” style applications. MQTT offers three support for JAVA clients only. qualities of service (QoS): 3.3. RabbitMQ At most once / unreliable - QoS level 0 At least once, to ensure it is sent a minimum The last broker to consider in our list is RabbitMQ of one time (but might be sent more than one [25].