Message Queuing System Research Articles

Real-Time UAV Trash Monitoring System

This study proposes a marine trash detection system based on unmanned aerial vehicles (UAVs) and aims to replace manpower with UAVs to detect marine trash efficiently and provide information to government agencies regarding real-time trash pollution. Internet technology and computer–machine interaction were applied in this study, which involves the deployment of a marine trash detection system on a drone’s onboard computer for real-time calculations. Images of marine trash were provided to train a modified YOLO model (You Look Only Once networks). The UAV was shown to be able to fly along a predefined path and detect trash in coastal areas. The detection results were sent to a data streaming platform for data processing and analysis. The Kafka message queuing system and the Mongo database were used for data transmission and analysis. It was shown that a real-time drone map monitoring station can be built up at any place where mobile communication is accessible. While a UAV is automatically controlled by an onboard computer, it can also be controlled through a remote station. It was shown that the proposed system can perform data analysis and transmit heatmaps of coastal trash information to a remote site. From the heatmaps, government agencies can use trash categories and locations to take further action.

A Fair Comparison of Message Queuing Systems

The production and real-time usage of streaming data bring new challenges for data systems due to huge volume of streaming data and quick response request of applications. Message queuing systems that offer high throughput and low latency play an important role in today's big streaming data processing. There are several popular message queuing systems in production usage and also many in-lab message queuing systems in academia. These systems with different design philosopies have different characteristics. It is non-trivial for a non-expert to choose a suitable system to meet his specific requirement. With this premise, our primary contribution is to provide the community with a fair comparison among message queuing systems, using a standardized comparison metric and reproducible experimental environment. Five typical message queuing systems (including Kafka, RabbitMQ, RocketMQ, ActiveMQ and Pulsar) are evaluated qualitatively (in analysis) and quantitatively (in experimental results). This article also highlights the distinct features of each system and summarizes the best-suited use cases of each system. The fair comparison and the insight analysis provided in this article can help users choose the best-suited message queuing systems.

A Software Testing Service Supporting Long-Lived and Asynchronous Testing Jobs

Testing as a service (TaaS) provides features like easiness of use, high availability, low installation and maintenance cost, thus can aid programmers and white-box testers in improving software quality. Automatic test data generation being embedded in a TaaS must consume significant amount of time and computer resources while dealing with mid- or large-scale programs. However, allowing large volume of long-lived test sessions in a TaaS will incur adverse impact on the scalability of the TaaS and its hosting servers. To enable a TaaS supports time-consuming testing jobs and keeps its scalability simultaneously; a message queuing system could be adopted for holding un-processed test jobs temporarily. This article describes the corresponding design rationale, implementation details of a testing as a service with message queuing system and discusses its advantages.

Galaxy LIMS for next-generation sequencing

We have developed a laboratory information management system (LIMS) for a next-generation sequencing (NGS) laboratory within the existing Galaxy platform. The system provides lab technicians standard and customizable sample information forms, barcoded submission forms, tracking of input sample quality, multiplex-capable automatic flow cell design and automatically generated sample sheets to aid physical flow cell preparation. In addition, the platform provides the researcher with a user-friendly interface to create a request, submit accompanying samples, upload sample quality measurements and access to the sequencing results. As the LIMS is within the Galaxy platform, the researcher has access to all Galaxy analysis tools and workflows. The system reports requests and associated information to a message queuing system, such that information can be posted and stored in external systems, such as a wiki. Through an API, raw sequencing results can be automatically pre-processed and uploaded to the appropriate request folder. Developed for the Illumina HiSeq 2000 instrument, many features are directly applicable to other instruments. The code and documentation are available at http://tron-mainz.de/tron-facilities/computational-medicine/galaxy-lims/

Where is is middleware

Middleware is all about integration. Middleware has existed in various forms for many years in systems such as the IBM Customer Information Control System (CICS), numerous message queuing systems such as IBM's MQ Series, the Common Object Request Broker Architecture (CORBA), Microsoft's Component Object Model (COM), Java 2 Enterprise Edition (J2EE), and the latest rage, Web services. Virtually every form of application, programming language, operating system, and hardware has been a target of an integration effort involving these middleware systems or their cousins. Middleware is everywhere.

The integration of existing GIS and modelling systems: with urban applications

The integration of existing modelling and geographic information systems is an important activity that enhances the value of these systems. In this paper, we present a simple and comprehensive approach for the integration of separately developed software systems. Any information system can be integrated using our methodology without the complexities introduced by providing an interpretation of a universal language. The design of our integration methodology consists of four separate components: the protocol for communication, a message queuing system, wrapping software and an integration manager. Relevant conceptual models and implementation techniques are discussed in the paper. We also describe some examples of the software we have successfully integrated and present an example script for managing a simple integration activity.