All reviews of published articles are made public. This includes manuscript files, peer review comments, author rebuttals and revised materials. Note: This was optional for articles submitted before 13 February 2023.
Peer reviewers are encouraged (but not required) to provide their names to the authors when submitting their peer review. If they agree to provide their name, then their personal profile page will reflect a public acknowledgment that they performed a review (even if the article is rejected). If the article is accepted, then reviewers who provided their name will be associated with the article itself.
Congratulations! Your article is ready to be published in the journal PeerJ Computer Science. We appreciate your interest in publishing your work in our journal and look forward to receiving further quality work from you.
[# PeerJ Staff Note - this decision was reviewed and approved by Sebastian Ventura, a PeerJ Section Editor covering this Section #]
Please ensure that the statistical analysis included in the article has been performed according to the technical standard required for publication. In particular, sample size, appropriate statistical measures, correction for multiple testing, effect size, degrees of freedom, and report relevant figures such as the statistic, n and exact p-values/confidence intervals as required.
This revision has significantly improved the paper. The authors have adequately addressed the comments included in my first review. Therefore, I have no further comments, and I would recommend the paper for publication.
No further comments.
No further comments.
No additional comments.
The authors should consider the comments of reviewer 2 to be considered for publication in PeerJ Computer Science.
[# PeerJ Staff Note: Please ensure that all review comments are addressed in a rebuttal letter and any edits or clarifications mentioned in the letter are also inserted into the revised manuscript where appropriate. It is a common mistake to address reviewer questions in the rebuttal letter but not in the revised manuscript. If a reviewer raised a question then your readers will probably have the same question so you should ensure that the manuscript can stand alone without the rebuttal letter. Directions on how to prepare a rebuttal letter can be found at: https://peerj.com/benefits/academic-rebuttal-letters/ #]
This is second review of the paper. Paper was substantially improved based on reviewer´s comments. All comments were addressed.
Reviewer´s comments were addressed:
Aim of the paper was explicitly defined in the Introduction. Research questions were defined.
Materials and Methods section was added.
Reviewer´s comments were addressed: research gap was identified.
Reviewer´s comments were addressed.
This submission presents a work to integrate Esper complex event processing engine and some message brokers. The paper introduces the problem, provides a background and motivation, and presents the implementation of the software architectures to be evaluated, followed by a description of the hardware resources used and the methods followed. After that, the authors present an empirical evaluation, a related work, and a discussion of the obtained results.
The paper is worth reading and well-referenced.
The authors provide a detailed background.
The different figures and tables presented by the authors are relevant to the content of the paper.
The authors have presented concise and relevant research questions. And the rest of the article heads in the right direction to provide answers to these questions.
The topic addressed in this paper is important, and the obtained results are interesting. Besides, the paper clearly defends the novelty and the interest of this proposed integration.
It will be interesting to see the application of this approach in a real case study, as the authors mentioned in the conclusion.
The authors provide an implementation of the software architecture and also discuss the obtained results. These two parts represent the core of their paper. However, I have a few additional comments:
- The authors explain why Esper was chosen as the "most appropriate" Event processing engine. However, I would appreciate seeing a detailed benchmark (in table format with the important comparative criteria), comparing Esper to other CEP engines, such as Apache Flink, Sidhi, etc, to corroborate their choice. This table will summarize the content of the "related work" section and also makes it easier to read.
- CEP rules have not been sufficiently discussed in this paper. How will the authors define these rules that are going to be used in the CEP engine? Are the rules defined manually or do they use (or intend to use) a method to automatically learn CEP rules?
- I have also a comment regarding the distributed CEP implementation. What about the cost? What do you propose to reduce the communication costs of distributed event processing? The other measurements presented in this paper are important but the cost is a non-negligible measurement in this kind of case.
All text and materials provided via this peer-review history page are made available under a Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.