DOCSLIB.ORG

Integrating Third-Party Services Using Brokers in the Serious Games’ Domain

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Integrating Third-Party Services Using Brokers in the Serious Games’ Domain 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].
Load more

Recommended publications
  • Enterprise Integration Patterns N About Apache Camel N Essential Patterns Enterprise Integration Patterns N Conclusions and More
    Brought to you by... #47 CONTENTS INCLUDE: n About Enterprise Integration Patterns n About Apache Camel n Essential Patterns Enterprise Integration Patterns n Conclusions and more... with Apache Camel Visit refcardz.com By Claus Ibsen ABOUT ENTERPRISE INTEGRATION PaTTERNS Problem A single event often triggers a sequence of processing steps Solution Use Pipes and Filters to divide a larger processing steps (filters) that are connected by channels (pipes) Integration is a hard problem. To help deal with the complexity Camel Camel supports Pipes and Filters using the pipeline node. of integration problems the Enterprise Integration Patterns Java DSL from(“jms:queue:order:in”).pipeline(“direct:transformOrd (EIP) have become the standard way to describe, document er”, “direct:validateOrder”, “jms:queue:order:process”); and implement complex integration problems. Hohpe & Where jms represents the JMS component used for consuming JMS messages Woolf’s book the Enterprise Integration Patterns has become on the JMS broker. Direct is used for combining endpoints in a synchronous fashion, allow you to divide routes into sub routes and/or reuse common routes. the bible in the integration space – essential reading for any Tip: Pipeline is the default mode of operation when you specify multiple integration professional. outputs, so it can be omitted and replaced with the more common node: from(“jms:queue:order:in”).to(“direct:transformOrder”, “direct:validateOrder”, “jms:queue:order:process”); Apache Camel is an open source project for implementing TIP: You can also separate each step as individual to nodes: the EIP easily in a few lines of Java code or Spring XML from(“jms:queue:order:in”) configuration.
    [Show full text]
  • Analysis of Notification Methods with Respect to Mobile System Characteristics
    Proceedings of the Federated Conference on DOI: 10.15439/2015F6 Computer Science and Information Systems pp. 1183–1189 ACSIS, Vol. 5 Analysis of notification methods with respect to mobile system characteristics Piotr Nawrocki ∗, Mikołaj Jakubowski † and Tomasz Godzik ‡ ∗AGH University of Science and Technology, al. A. Mickiewicza 30, 30-059 Krakow, Poland e-mail:[email protected] †e-mail:[email protected] ‡e-mail:[email protected] Abstract—Recently, there has been an increasing need for most promise and therefore the purpose is to discern their secure, efficient and simple notification methods for mobile usefulness in the best way possible. systems. Such systems are meant to provide users with precise In addition to the protocols and methods above, we inves- tools best suited for work or leisure environments and a lot of effort has been put into creating a multitude of mobile tigated other solutions, such as the Apple push notification applications. However, not much research has been put at the or Line application which, for various reasons, were not same time into determining which of the available protocols considered further. The Apple push notification technology is a are best suited for individual tasks. Here a number of basic good solution, but it is proprietary, i.e. limited to Apple devices notification methods are presented and tests are performed for and that is why we decided to test more universal solutions the most promising ones. An attempt is made to determine which methods have the best throughput, latency, security and other first. There are also solutions (applications) that use their own characteristics.
    [Show full text]
  • Unravel Data Systems Version 4.5
    UNRAVEL DATA SYSTEMS VERSION 4.5 Component name Component version name License names jQuery 1.8.2 MIT License Apache Tomcat 5.5.23 Apache License 2.0 Tachyon Project POM 0.8.2 Apache License 2.0 Apache Directory LDAP API Model 1.0.0-M20 Apache License 2.0 apache/incubator-heron 0.16.5.1 Apache License 2.0 Maven Plugin API 3.0.4 Apache License 2.0 ApacheDS Authentication Interceptor 2.0.0-M15 Apache License 2.0 Apache Directory LDAP API Extras ACI 1.0.0-M20 Apache License 2.0 Apache HttpComponents Core 4.3.3 Apache License 2.0 Spark Project Tags 2.0.0-preview Apache License 2.0 Curator Testing 3.3.0 Apache License 2.0 Apache HttpComponents Core 4.4.5 Apache License 2.0 Apache Commons Daemon 1.0.15 Apache License 2.0 classworlds 2.4 Apache License 2.0 abego TreeLayout Core 1.0.1 BSD 3-clause "New" or "Revised" License jackson-core 2.8.6 Apache License 2.0 Lucene Join 6.6.1 Apache License 2.0 Apache Commons CLI 1.3-cloudera-pre-r1439998 Apache License 2.0 hive-apache 0.5 Apache License 2.0 scala-parser-combinators 1.0.4 BSD 3-clause "New" or "Revised" License com.springsource.javax.xml.bind 2.1.7 Common Development and Distribution License 1.0 SnakeYAML 1.15 Apache License 2.0 JUnit 4.12 Common Public License 1.0 ApacheDS Protocol Kerberos 2.0.0-M12 Apache License 2.0 Apache Groovy 2.4.6 Apache License 2.0 JGraphT - Core 1.2.0 (GNU Lesser General Public License v2.1 or later AND Eclipse Public License 1.0) chill-java 0.5.0 Apache License 2.0 Apache Commons Logging 1.2 Apache License 2.0 OpenCensus 0.12.3 Apache License 2.0 ApacheDS Protocol
    [Show full text]
  • Talend Open Studio for Big Data Release Notes
    Talend Open Studio for Big Data Release Notes 6.0.0 Talend Open Studio for Big Data Adapted for v6.0.0. Supersedes previous releases. Publication date July 2, 2015 Copyleft This documentation is provided under the terms of the Creative Commons Public License (CCPL). For more information about what you can and cannot do with this documentation in accordance with the CCPL, please read: http://creativecommons.org/licenses/by-nc-sa/2.0/ Notices Talend is a trademark of Talend, Inc. All brands, product names, company names, trademarks and service marks are the properties of their respective owners. License Agreement The software described in this documentation is licensed under the Apache License, Version 2.0 (the "License"); you may not use this software except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0.html. Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. This product includes software developed at AOP Alliance (Java/J2EE AOP standards), ASM, Amazon, AntlR, Apache ActiveMQ, Apache Ant, Apache Avro, Apache Axiom, Apache Axis, Apache Axis 2, Apache Batik, Apache CXF, Apache Cassandra, Apache Chemistry, Apache Common Http Client, Apache Common Http Core, Apache Commons, Apache Commons Bcel, Apache Commons JxPath, Apache
    [Show full text]
  • AMQP and Rabbitmq Message Queuing As an Integration Mechanism
    2/19/2018 MQTT A protocol for communicating with your things David Brinnen and Brett Cameron SESAM Seminar, March 2018 Abstract The Internet of Things refers to the ever-growing network of physical devices that have IP connectivity, allowing them to connect to the internet, and the communication that occurs between these devices and other internet-enabled devices and systems. In this talk, Brett and David will introduce the Internet of Things and will discuss some of the key technologies associated with the creation of Internet of Things solutions and services within the manufacturing domain. Particular attention will be given to MQTT, which is gaining acceptance as the preferred protocol for use by the Internet of Things applications. Currently available implementations of MQTT will be briefly reviewed and case studies illustrating the application of the protocol will be presented. Some examples of how MQTT might be used to implement secure, fault-tolerant, and scalable Internet of Things solutions will be discussed, and the application and use of MQTT in Next Generation SCADA systems that need to monitor and control devices at scale in a connected world will be will be discussed and demonstrated. 2 2/19/2018 About David Since completing his Masters studies in Embedded Software at the Swedish Royal Institute of Technology 2015 (KTH), David has been working as a software engineer across a range of projects, including the implementation of control logical and the commissioning of Energy Machines integrated energy systems and air handling units (https://www.energymachines.com/), and the development of a next-generation SADA platform (ControlMachines™) and simulation software to control, monitor, and model Energy Machines deployments.
    [Show full text]
  • Talend ESB System Management Integration User Guide
    Talend ESB System Management Integration User Guide 6.0.1 Publication date: September 10, 2015 Copyright © 2011-2015 Talend Inc. All rights reserved. Copyleft This documentation is provided under the terms of the Creative Commons Public License (CCPL). For more information about what you can and cannot do with this documentation in accordance with the CCPL, please read: http://creativecommons.org/licenses/by-nc-sa/2.0/ This document may include documentation produced at The Apache Software Foundation which is licensed under The Apache License 2.0. Notices Talend and Talend ESB are trademarks of Talend, Inc. Apache CXF, CXF, Apache Karaf, Karaf, Apache Camel, Camel, Apache Maven, Maven, Apache Archiva, Archiva, Apache Syncope, Syncope, Apache ActiveMQ, ActiveMQ, Apache Log4j, Log4j, Apache Felix, Felix, Apache ServiceMix, ServiceMix, Apache Ant, Ant, Apache Derby, Derby, Apache Tomcat, Tomcat, Apache ZooKeeper, ZooKeeper, Apache Jackrabbit, Jackrabbit, Apache Santuario, Santuario, Apache DS, DS, Apache Avro, Avro, Apache Abdera, Abdera, Apache Chemistry, Chemistry, Apache CouchDB, CouchDB, Apache Kafka, Kafka, Apache Lucene, Lucene, Apache MINA, MINA, Apache Velocity, Velocity, Apache FOP, FOP, Apache HBase, HBase, Apache Hadoop, Hadoop, Apache Shiro, Shiro, Apache Axiom, Axiom, Apache Neethi, Neethi, Apache WSS4J, WSS4J are trademarks of The Apache Foundation. Eclipse Equinox is a trademark of the Eclipse Foundation, Inc. SoapUI is a trademark of SmartBear Software. Hyperic is a trademark of VMware, Inc. Nagios is a trademark of Nagios Enterprises, LLC. All other brands, product names, company names, trademarks and service marks are the properties of their respective owners. Table of Contents 1. Introduction .............................................................................................................. 1 2. Hyperic HQ Integration .............................................................................................. 3 2.1.
    [Show full text]
  • Release Notes Date Published: 2021-03-25 Date Modified
    Cloudera Runtime 7.2.8 Release Notes Date published: 2021-03-25 Date modified: https://docs.cloudera.com/ Legal Notice © Cloudera Inc. 2021. All rights reserved. The documentation is and contains Cloudera proprietary information protected by copyright and other intellectual property rights. No license under copyright or any other intellectual property right is granted herein. Copyright information for Cloudera software may be found within the documentation accompanying each component in a particular release. Cloudera software includes software from various open source or other third party projects, and may be released under the Apache Software License 2.0 (“ASLv2”), the Affero General Public License version 3 (AGPLv3), or other license terms. Other software included may be released under the terms of alternative open source licenses. Please review the license and notice files accompanying the software for additional licensing information. Please visit the Cloudera software product page for more information on Cloudera software. For more information on Cloudera support services, please visit either the Support or Sales page. Feel free to contact us directly to discuss your specific needs. Cloudera reserves the right to change any products at any time, and without notice. Cloudera assumes no responsibility nor liability arising from the use of products, except as expressly agreed to in writing by Cloudera. Cloudera, Cloudera Altus, HUE, Impala, Cloudera Impala, and other Cloudera marks are registered or unregistered trademarks in the United States and other countries. All other trademarks are the property of their respective owners. Disclaimer: EXCEPT AS EXPRESSLY PROVIDED IN A WRITTEN AGREEMENT WITH CLOUDERA, CLOUDERA DOES NOT MAKE NOR GIVE ANY REPRESENTATION, WARRANTY, NOR COVENANT OF ANY KIND, WHETHER EXPRESS OR IMPLIED, IN CONNECTION WITH CLOUDERA TECHNOLOGY OR RELATED SUPPORT PROVIDED IN CONNECTION THEREWITH.
    [Show full text]
  • Location Independent Inter-Process Communication As Software Buses
    Location independent inter-process communication as software buses Erik Samuelsson Erik Samuelsson VT 2016 Bachelor Thesis, 15 credits Supervisor: Cristian Klein, Ewnetu Bayuh Lakew Extern Supervisor: Clas H¨ogvall, Rickard Sj¨ostr¨om, Johan Forsman Examiner: Jerry Eriksson Bachelor’s Programme in Computing Science, 180 credits Abstract Telecommunication networks will transform and gradually migrate into virtualized cloud environments as a result of the potential for higher profitability through reduced costs and increased revenues. The purpose of this thesis is to investigate architectural mecha- nisms for location-independent communication between software components in a virtualized base station. Systems that provide such mechanisms are typically referred to as middleware and de- ployed as Platform-as-a-Service (PaaS). The overall goal is to achieve desired characteristics in cloud deployment regarding on- demand self-service, rapid elasticity of capacity while upholding services and high availability. Four communication protocols are examined and evaluated based on a set of functional and non- functional requirements that are especially relevant for a virtu- alized base station. In comparison with the Advanced Message Queuing Protocol (AMQP), Message Queuing Telemetry Trans- port (MQTT) and the eXtensible Messaging and Presence Pro- tocol (XMPP), the Data Distribution Service (DDS) standard is found to have excellent performance characteristics. Its complex- ity might have implications for the development and deployment though, that will increase the time it takes to reap the benefits from its advantages. Acknowledgements I wish to sincerely thank my supervisors at Tieto, Clas H¨ogvall, Rickard Sj¨ostr¨om and Johan Forsman for introducing an interesting and challenging thesis idea and for entrusting me with the task.
    [Show full text]
  • Storage and Ingestion Systems in Support of Stream Processing
    Storage and Ingestion Systems in Support of Stream Processing: A Survey Ovidiu-Cristian Marcu, Alexandru Costan, Gabriel Antoniu, María Pérez-Hernández, Radu Tudoran, Stefano Bortoli, Bogdan Nicolae To cite this version: Ovidiu-Cristian Marcu, Alexandru Costan, Gabriel Antoniu, María Pérez-Hernández, Radu Tudoran, et al.. Storage and Ingestion Systems in Support of Stream Processing: A Survey. [Technical Report] RT-0501, INRIA Rennes - Bretagne Atlantique and University of Rennes 1, France. 2018, pp.1-33. hal-01939280v2 HAL Id: hal-01939280 https://hal.inria.fr/hal-01939280v2 Submitted on 14 Dec 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Storage and Ingestion Systems in Support of Stream Processing: A Survey Ovidiu-Cristian Marcu, Alexandru Costan, Gabriel Antoniu, María S. Pérez-Hernández, Radu Tudoran, Stefano Bortoli, Bogdan Nicolae TECHNICAL REPORT N° 0501 November 2018 Project-Team KerData ISSN 0249-0803 ISRN INRIA/RT--0501--FR+ENG Storage and Ingestion Systems in Support of Stream Processing: A Survey Ovidiu-Cristian Marcu∗, Alexandru
    [Show full text]
  • Industry Paper: Kafka Versus Rabbitmq a Comparative Study of Two Industry Reference Publish/Subscribe Implementations
    Industry Paper: Kafka versus RabbitMQ A comparative study of two industry reference publish/subscribe implementations Philippe Dobbelaere Kyumars Sheykh Esmaili Nokia Bell Labs Nokia Bell Labs Antwerp, Belgium Antwerp, Belgium ABSTRACT 1 INTRODUCTION Publish/subscribe is a distributed interaction paradigm well adapted e Internet has considerably changed the scale of distributed sys- to the deployment of scalable and loosely coupled systems. tems. Distributed systems now involve thousands of entities po- Apache Kaa and RabbitMQ are two popular open-source and tentially distributed all over the world whose location and behav- commercially-supported pub/sub systems that have been around for ior may greatly vary throughout the lifetime of the system. ese almost a decade and have seen wide adoption. Given the popularity constraints underline the need for more exible communication of these two systems and the fact that both are branded as pub/sub models and systems that reect the dynamic and decoupled na- systems, two frequently asked questions in the relevant online ture of the applications. Individual point-to-point and synchronous forums are: how do they compare against each other and which communications lead to rigid and static applications, and make the one to use? development of dynamic large-scale applications cumbersome [14]. In this paper, we frame the arguments in a holistic approach by To reduce the burden of application designers, the glue between establishing a common comparison framework based on the core the dierent entities in such large-scale seings should rather be functionalities of pub/sub systems. Using this framework, we then provided by a dedicated middleware infrastructure, based on an ad- venture into a qualitative and quantitative (i.e.
    [Show full text]
  • Java Message Service Based Performance Comparison of Apache Activemq and Apache Apollo Brokers
    Available online at sjuoz.uoz.edu.krd Vol. 5, No. 4, pp. 307 –312, Dec.-2017 p-ISSN: 2410-7549 e-ISSN: 2414•6943 journals.uoz.edu.krd JAVA MESSAGE SERVICE BASED PERFORMANCE COMPARISON OF APACHE ACTIVEMQ AND APACHE APOLLO BROKERS Qusay I. Sarhan a ,* and Idrees S. Gawdan b a Dept. of Computer Science, College of Science, University of Duhok, Kurdistan Region, Iraq – ([email protected]). b Dept. of Refrigeration & Air-Conditioning, Technical College of Engineering, Duhok Polytechnic University, Duhok, Kurdistan Region-Iraq – ([email protected]) Received: Aug. 2017 / Accepted: Dec., 2017 / Published: Dec., 2017 https://doi.org/10.25271/2017.5.4.376 ABSTRACT: Software integration is a crucial aspect of collaborative software applications and systems. It enables a number of different software applications, created by different developers, using different programming languages, and even located at different places to work with each other collaboratively to achieve common goals. Nowadays, a number of techniques are available to enable software integration. Messaging is the most prominent technique in this respect. In this paper, two leading open-source messaging brokers, Apache ActiveMQ and Apache Apollo, have been experimentally compared with each other with regard to their messaging capabilities (message sending and receiving throughputs). Both brokers support exchanging messages between heterogeneous and distributed software applications using several messaging mechanisms including Java Message Service (henceforth JMS). A number of experimental test scenarios have been conducted to obtain the comparison results that indicate the one-to-one JMS messaging performance of each broker. Overall performance evaluation and analysis showed that Apache Apollo outperformed Apache ActiveMQ in all test scenarios regarding message sending throughputs.
    [Show full text]
  • A Survey of Distributed Message Broker Queues
    A Survey of Distributed Message Broker Queues Vineet John Xia Liu University of Waterloo University of Waterloo [email protected] [email protected] ABSTRACT This paper surveys the message brokers that are in vogue today for distributed communication. Their primary goal is to facilitate the construction of decentralized topolo- gies without single points of failure, enabling fault tol- erance and high availability. These characteristics make them optimal for usage within distributed architectures. However, there are multiple protocols built to achieve this, and it would be beneficial to have a empirical comparison between their features and performance to determine their real-world applicability. Figure 1: Kafka Architecture This paper focuses on two popular protocols (Kafka and AMQP) and explores the divergence in their fea- RQ0 What are the message broker implementations tures as well as their performance under varied testing commonly in use today? workloads. RQ1 What are the common requirements for the im- plementation of message queues? KEYWORDS RQ2 What are the divergent functionalities in the distributed message broker, message queue, kafka, amqp, current message queue offerings? rabbitmq RQ3 How do each of the implementations offer relia- bility, partitioning and fault tolerance? 1 INTRODUCTION 3 KAFKA Kafka was developed at LinkedIn and primarily used Distributed Message Brokers are typically used to decou- for log processing. This worked well for Kafka’s user en- ple separate stages of a software architecture. They per- gagement metrics collection use-case. The fundamental mit communication between these stages asynchronously, features behind Kafka are performance over reliability by using the publish-subscribe paradigm.[1]. These mes- and it offers high throughput, low latency message queu- sage brokers are also finding new applications in the ing.
    [Show full text]