Dear Aniruddha Gokhale - We are happy to inform you that your paper 997 - Managing Variability in Middleware Provisioning Using Visual Modeling Languages has been conditionally Accepted with Mandatory changes to HICSS 2007. Changes specified by the minitrack chair (Primary Reviewer) from the reviewers must be made prior to final acceptance. The reviews are included below. The final version of your paper must be submitted by September 10th to allow time for the minitrack chair to confirm that required changes have been made. To prepare the final version of your paper, please follow formatting requirements and submission instructions for "SUBMITTING FINAL VERSION OF YOUR PAPER" that are found at http://www.hicss.hawaii.edu/hicss_40/FinalSubmission.htm The formatting requirements are the same as the original paper, plus the addition of the author information. See Finalsample.doc for formatting of final paper: * Final paper must submitted in pdf format. * All author information must be included. * Double column, single spaced * No more than 10 pages in length, including all references, tables, etc. https://precisionconference.com/~hicss07/ Remember, final papers must be uploaded by September 10th, 2006, 5:00pm California time, for review by the minitrack chair. Presenting author must be registered for the conference by Sept. 15th. Sincerely, Guido Wirtz, HICSS 2007 guido.wirtz@wiai.uni-bamberg.de Primary Minitrack Chair ------------------------ Paper 997, Review 5 ------------------------ Title: Managing Variability in Middleware Provisioning Using Visual Modeling Languages Reviewer: Primary Minitrack Chair Characteristics of Submission Overall Rating 4 (Probably accept: I would argue for accepting this paper.) The Review The topic of the paper - a visual aids for deploying etc. distributed software in a middleware context- meets the minitrack topics almost perfectly. However, the paper is organized and written in a manner that makes it hard to really evaluate the benefits of the approach. Especially the question, how the language POSAML really does look like and what is more on a conceptual or modelling level remains vague throughout the paper. Besides formal flaws like missing an abstract as well as the Conclusions (?) also some of the section give the impression of a kind of 'last-minute deadline meeting' approach ... Because the approach definitely has its benefits, I would suggest to + shorten the intro in those parts that rely on general knowledge about middleware, deployment etc. and use this space to introduce your overall diseign ideas better + concentrate on POSAML and those aspects that can be discussed in a conprehensive manner in the context of a single paper (you tried to put too much into a single paper, I think) + structure the language and model description in a manner that it is better understandable for a novice + discuss evaluation issues in more detail + related work, e.g. why not using UML 2.0 diagrams etc. should be discussed better to justify the approach Maybe a restructuring towards: intro - (meta-)models - language - examples - evaluation would be helpful to transport your ideas better. Some additional (more or less small) details to be corrected ! + Figs including models and annotations are hardly readable, esp. Figs. 4, 12, 12 + some repetition should be avoided throughout the paper + some figures less but those that remina better explained may also be helpful Relevance 5 Theory 2 Methodology 4 Presentation 2 Validity: 3 References: 3 Contribution: 4 Originality: 4 Interest: 4 ------------------------ Paper 997, Review 1 ------------------------ Title: Managing Variability in Middleware Provisioning Using Visual Modeling Languages Reviewer: external Characteristics of Submission Overall Rating 2 (Probably reject: I would argue for rejecting this paper.) The Review This paper presents a visual modeling language named POSAML aimed at allowing designers to model the deplpyment and provisioning configuration aspects of middleware systems while allowing quality of service (QoS) validation. The environment is supposed to ease the designer's task by allowing him to rapidly explore various design alternatives through an interface positioned at a higher level fo abstraction than current manual/programmatic tecniques. The proposed approach is also presented as being less error-prone. The paper presents work that is interesting, but a significant lack of structure makes it difficult to read (English is fine, it is really a matter of structure). Moreover, most of the sections related to POSAML are mere (unstructured) descriptions of POSAML elements and features, often presented without a rationale for the design choices made. The scientific content of the paper is thus weak. Some descriptions seem too detailed, while others are too short to get a clear understanding of a specific construct. Again, this is all due to a lack of structure in the description. Similarly, figures are loosely connected to the text, except for Fig 3. They often contain a lot of elements, which makes it difficult to extract relevant information. However, my main problem with the paper is that I miss a) a clear introduction to the visual notation, b) discussions about the design choices. I would also have liked to get some information about how POSAML has been evaluated. In the absence of both the afore-mentioned discussion on design choices and empirical evidence, I consider the lack of factual elements about the effectiveness of POSAML to be a major obstacle to the acceptance of this paper. Some additional comments follow: - page 1, column 2, "A linear text file, such as XML [...]": presenting XML files as linear text files is a little bit far-fetched. While it is true that the textual serialization of an XML document is linear, XML documents are hierarchical structures. - page 2, Fig 1: arrow labels are difficult to read on screen, and unreadable when printed. - page 3, column 2: fix reference "refsec:challenges" - end of page 4: this seems to be some form of syntax-directed editing environment. Please use appropriate terminology and reference related work. Relevance 5 Theory 2 Methodology 3 Presentation 1 Validity: 2 References: 3 Contribution: 4 Originality: 3 Interest: 3 ------------------------ Paper 997, Review 2 ------------------------ Title: Managing Variability in Middleware Provisioning Using Visual Modeling Languages Reviewer: external Characteristics of Submission Overall Rating 4 (Probably accept: I would argue for accepting this paper.) The Review The paper presents a visual modeling language called POSAML for deployment of software systems on middleware. It attempted to address the difficulties in provisioning and configuration of middleware due to the large amount of variability that middleware can provide. The paper analyzed the types of variability that middleware can provide and the design patterns of middleware. It devised a modeling language and implemented the language using the generic Modeling Environment GME. Meta-models in POSAML of the Reactor and Acceptor-Connector patterns were given in the paper to illustrate the capability and style of POSAML. The paper reported a large amount of research work done by the authors, which are interesting and original in many aspects. However, the presentation of the paper could be improved in a number of ways. First, the introduction could be shortened and more focused on the problems that the modeling language addresses. There was no evidence presented in the paper that problems discussed in the introduction were actually solved by the work reported in the paper. Second, Section II, especially Fig. 1, needs a better explanation. Third, the title of Section III is the design of POSAML, but the content is mostly about the meta-model of design patterns. Moreover, the structure of the paper could be better organized. For example, modeling could be grouped into one section to include modeling design patterns, modeling configurations, modeling features, etc. The tool supports to modeling can be grouped into another section to include QoS validation and generative capabilities, etc. Finally, and most importantly, case studies of the modeling language and the tools should be presented (or referred to if they have been reported elsewhere) to demonstrate how the problems discussed in section I are solved. In the discussion in Section V, the comparisons with existing work could be enhanced, especially why UML is not suitable for the problems that you are addressing. Relevance 4 Theory 3 Methodology 4 Presentation 2 Validity: 2 References: 3 Contribution: 4 Originality: 4 Interest: 4 ------------------------ Paper 997, Review 3 ------------------------ Title: Managing Variability in Middleware Provisioning Using Visual Modeling Languages Reviewer: external Characteristics of Submission Overall Rating 3 (Borderline: Overall I would not argue for accepting this paper.) The Review The paper describes a domain specific language for setting up deployment of applications. Instead of state-of-the-art textual deployment specifications (usually programs and/or XML), a graphical language and tool POSAML have been developed. This tool allows to compose patterns setting up the architecture of the application, specification of quality of service as well as benchmarks used for validating QoS. The pattern approach is based on reference [15]. The authors have defined a set of metamodels that represent those patterns and their composition. GME has been used to implement POSAML. The paper's topic is really relevant to the workshop, and DSLs may really help to solve the problems when deploying (networked) applications. However, the paper is neither a real paper on the described problems and their solution, nor does it really describe the DSL that is claimed to solve the problems. The authors spend much effort on convincing the reader that deployment and in particular provisioning of (networked) applications are currently solved in a more or less ad-hoc manner that leads to many problems. After coming to the (obvious) conclusion that a DSL may offer a solution, the paper describes some specific examples. However, the paper is not self-contained here as those examples are very specific and hard to understand without specific background knowledge. On the other hand, the proposed DSL is even less understandable since the authors do not really describe the essentials of the language. They just present some metamodels and some models according to them. But the reader - in my opinion - has little chance to understand them. For instance, the diagrams are cluttered with associations (in particular in Fig. 5), but there is hardly any association label. And the text does not describe the diagrams either. Since the topic of the paper is really interesting and the paper's problem is mainly its presentation, I consider the paper to be borderline. But I would (weakly) vote for acceptance under the condition that the authors improve the presentation, i.e., present less metamodels and models, but present them in an understandable way. Moreover, examples of pattern-based solutions should be presented in a more self-contained way. Detailed comments: p. 1, Fig. 1 and following text: The figure is hardly readable, and it is not explained in the text p. 3, sect. III: - \ is missing in front of ref{sec:challenges} - Fig. 2 is not really explained (this holds for the other metamodels and models, too). What is a "model" element in the figure? Is it a class with stereotype "Model"? - The edge layout in Fig. 2 (and the following) should be really improved. That way, associations are hard to follow as there are so many unnecessary bends such that the benefits of visual notations are clearly reduced. Fig. 5, 7, 8: What do they mean? In particular Fig. 5 and 8 are incomprehensible Relevance 4 Theory 3 Methodology 3 Presentation 1 Validity: 2 References: 4 Contribution: 3 Originality: 3 Interest: 4 ------------------------ Paper 997, Review 4 ------------------------ Title: Managing Variability in Middleware Provisioning Using Visual Modeling Languages Reviewer: external Characteristics of Submission Overall Rating 3 (Borderline: Overall I would not argue for accepting this paper.) The Review Although the language and methodology presented are no doubt valuable tools for software integration, the emphasis of the workshop is on visual notations and interactions. Aside from a reference to one workshop on visual modelling at VLHCC'05 to support the broad claim that "Visual aids are one of the best known techniques to intuitively reason about any system", this paper largely ignores the issues of visuality. No clear description is given of the language. Except for figure 7 which is obviously a screen shot of POSAML, it is not clear which figures depict diagrams that are part of the language, and which are simply explanatory. For example, in referring to figure 3 the text says "the Reactor metamodel for POSAML is shown in Figure 3". Does this mean that figure 3 is a diagram in the POSAML language, or describes a structure underlying the language, or something else? If a visual language is being presented, as the title suggests, then the reader has a right to expect that the syntax and semantics of that language will be explained, and that the language will be compared to other visual languages. Furthermore, from what I can gather about the POSAML language, I see nothing very innovative from the VL perspective. In short, I get the impression that visuality is quite inconsequential. Although the paper is relatively easy to read, the presentation is marred by typos, grammatical errors, irritating repetition, and lack of clarity including occasional lapses into corporate-style obfuscation. Examples are: p10: "The manual nature... is..." -> "The manual nature... are..." p10: "... and which uses incremental..." -> "... which uses incremental..." p9: "weaved" - the past participle of "weave" is "woven" p3: "Section refsec:challenges" ??? p3: ".. in accordance to the provisioning decisions." -> ".. in accordance with the provisioning decisions." p1: "... a visual domain-specific modeling language (DSML) [7], [8] called POSAML (Patterns-oriented Software Architecture Modeling Language)..." - This is twice repeated almost verbatim on p3 p1: "... which is detrimental to meeting the new market demands of faster time-to-market." - do you mean "resulting in unacceptably long development times." ? p9: "These parameters can be parameters..." p9: "...overall systemic effect..." - redundant Relevance 5 Theory 2 Methodology 3 Presentation 2 Validity: 3 References: 2 Contribution: 3 Originality: 2 Interest: 2