• Unknown User
    Unknown User, 18/09/2014 00:06

     REVIEW 1 -
    PAPER: 111
    TITLE: Coordination-aware Elasticity
    AUTHORS: Stefano Mariani, Hong-Linh Truong, Georgiana Copil, Andrea Omicini and Schahram Dustdar

    OVERALL EVALUATION: 0 (borderline paper)

     REVIEW -
    There are concepts to describe elasticity control as a separate set of directives next to a cloud application. These directives are supposed to monitor the application and system behaviour and to react according to the cloud customer's policies in the sense of scaling in or out application instances, or reconfiguring them appropriately. Coordination models as known from agent-oriented computing are supposed to manage the behaviour of distributed agents according to some well-defined policies of the agent user.

    In this paper the authors combine both concepts to improve elasticity control in clouds. First they demonstrate that from the overall perspective there are a lot of similarities between both approaches. Second they describe their own approach how to integrate both worlds into an elasticity control system for cloud applications. This is demonstrated and explained by using a prototype system based on SYBL (an elasticity control language) and ReSpecT (an extension of a tuple-spacebased coordination system). Both systems are more or less previous work of the authors.

    As I am not an expert in this field, I have a hard time to figure out what bothers me about the paper. It seems to have a point, but I am not entirely convinced. The listings of Pseudocode 1 and 2 are supposed to demonstrate the benefits of the combined approach and I can follow that there are benefits. The problem however seems to be located in the poor programming model of current elasticity-control models. The combined approach seems to heal this a bit, but introduces even more complexity as users have to think in both worlds. Wouldn't it be much better to develop a new elasticity-control programming model that adopts certain concepts from control models, but is perfectly suited for the designated task? At least I would have expected some discussion about the problem, its ideal solution and the differences of both to the proposed contributions.

     REVIEW 2 -
    PAPER: 111
    TITLE: Coordination-aware Elasticity
    AUTHORS: Stefano Mariani, Hong-Linh Truong, Georgiana Copil, Andrea Omicini and Schahram Dustdar

    OVERALL EVALUATION: 2 (accept)

     REVIEW -
    The paper deals with the integration of elasticity programming directives, aiming to ease the task of controlling elasticity of cloud applications, with coordination laws, which are used to coordinate the execution of agents’ activities. As a concrete example, the paper presents how SYBL language, used for the specification of elasticity requirements, has been integrated with ReSpecT language.
    The paper is well structured, first presenting the elasticity and coordination concepts and then building upon them the approach for their integration. I would propose to accept the paper as the proposed approach is interesting and it seems to improve the enforcement of elasticity related controls, one of the key feature of cloud computing. The paper clearly explains how the approach was developed and also presents the prototype, showing the benefits of introducing the coordination-aware elasticity model.
    I would just give suggestions for the sake of completeness and readability. A mapping between the elasticity and coordination abstractions is proposed, specifying that it’s not an exact mapping. I would suggest to clarify whether the “not exact” mapping has implications to consider when using the approach proposed. As for the readability, it would be better to avoid to put long sentences within em dashes and to keep the figures’ captions short, moving comments within the body text.
    In Section IV C.  coordination-aware feedback loop is mentioned with reference to the Figure 8. I find the picture not very clear, it should be improved and few lines explaining the loop could be added.
    Some suggestions for improving the text:
    • Section I B: “we analyse we relationships”, should be “we analyse the relationships”
    • Section II A.: “rules to be trigger ”, should be “rules to be triggered”
    • Section III B: “by monitoring primitives, constraints and strategies”, should be “by monitoring, constraints and strategies primitives”. In the same section, “are usually put coordination and observation primitives”, should be “coordination and observation primitives are usually put”
    • “subject of” on a few pages: check whether you meant “subject to”
    • add the link to GitHub repository the first time you mention it (Section IV A, 1) )

     REVIEW 3 -
    PAPER: 111
    TITLE: Coordination-aware Elasticity
    AUTHORS: Stefano Mariani, Hong-Linh Truong, Georgiana Copil, Andrea Omicini and Schahram Dustdar

    OVERALL EVALUATION: 1 (weak accept)

     REVIEW -
    The paper presents a coordination-based approach for elasticity programming directives, based on the concepts of coordination-aware elasticity. The approach is aimed at supporting delegation and separation of concerns both at design-time and at run-time. Moreover, by exploiting the ReSpecT language and TuCSoN tool, elasticity control parameters can be dynamically adapted either by a human administrator or by software.

    The paper is interesting and well written. It deals with an interesting issue, by providing a general solution for it. Nevertheless, some parts should be improved, as reported in the following comments.

    1. The SYBL4 language and the ReSpecT5 are exploited to implement the prototype. Nevertheless, for the sake of clarity, such tools should be briefly described in the paper. 

    2. No experimental evaluation is reported in the paper. This is my main concern about the paper, because an experimental evaluation (carried on a single or multiple cloud environments) could make the paper in a more complete treatment.

    3. In my opinion, Figures 6 and 7 are too technical; they could be replaced by a meta-code schema. In alternative, both figures could be removed from the paper, in order to take place for an experimental evaluation section.  

    4. The current form of Figure 8 is not clear and should be re-designed in a more clear way.

Partita IVA: 01131710376 - Copyright © 2008-2021 APICe@DISI Research Group - PRIVACY