Referee 1 ******************************************* E: Referee Comments (For Author and Editor) ------------------------------ The paper needs to address the difference between Webflow and this activity. Can we disconnect and connect to the portal and have the jobs still running? F: Presentation Changes Summary: Replace "this way" with Thus. I do not like the use of the phrase This way. Introduction: The first two paragraphs are almost two introductions, maybe the first paragraph should be dropped? Maybe a better connection to the second should be established. Page 2: section 2. this is yet a different motivating example. I suggest to either stick with one motivating example or have a special section that lists and goes in detail to each of the motivating examples. Recommendation tighten introduction and motivating examples. Page 4. is the term actors used in the CS sense? This is unclear, if not explain what it is. Figure 1. Use UML Grid is almost always capitalized Figures are unreadable, why does everyone scale gif images to unreadability? Use vector graphics for figure 7. Referee 2 ******************************************* E: Referee Comments (For Author and Editor) ------------------------------ The paper describes a highly interesting project with a focus on real applications for everyday use. The structure of the paper is poor and it is difficult for the interested reader to fully grasp the concept behind the web portal. It may be helpful to have the description of the MCWP as chapter 4 (now chapter 5) and only after having introduced the concepts go into the details with "Portal Design". Information about comparable projects and research work has to be included to show how MCWP compares to other work in the field. This should also be reflected in the referenced literature. It is obvious that the article was not yet formatted. We expect this to be done before the paper is published. Currently figure 2 is incomplete. All figures should be of much better quality. F: Presentation Changes In the very general introduction the author states that city planners do make extensive use of computers. In this generality this is probably wrong. It is also doubtful to see computational power as a reliable source of forecast for the stock market. In figure 1 the classification of the users into administrators, developers, operators and customer analysts is done. In the later paper only the general term "user" is utilized. It would be helpful to demonstrate the usefulness of this classification if this general term would be replaced by the more specific term defined above wherever applicable. In the description of the application descriptor it would be very interesting to get more details how the "information how to build it" is provided. In the description of the job descriptor the author refers to figure 3 showing the analyst interface. It is not clear how this corresponds to the job descriptor. The text in the screen shots of figure 2,3,4 and 5 is unreadable. Referee 3 ******************************************* E: Referee Comments (For Author and Editor) ------------------------------ Re: Chapter 2 It is not obvious from the paper how tightly MCWP is coupled to DMEFS and SPUR. I would assume that these are initial sample applications and that the system can be extended (how?) to other application domains. Chapter 3: The term 'user' is used ambiguously. On one hand it is the generic class of users like developer, customer, etc on the other hand it is used where a specific class should be named. Chapter 5: The section on architecture should be expanded to explain the functions of the tiers more concrete. It is especially not obvious if all four Tiers are considered part of the Portal as Fig 7 suggests. The following questions should also be addressed: - Security, authentication, authorization - Systems supported as back-end F: Presentation Changes Heading of chapter 2 should probably read: Applications Driving MCWP Figure 2 has arrows pointing into it which should be labeled or omitted.