Referee 1 ******************************************* E: Referee Comments (For Author and Editor) The paper describes GridPort, a toolkit for building grid portals, and some application specific grid portal built using GridPort. Internally GridPort exploits the Globus grid infrastructure as middleware. The portals described are provided with the majority of the Globus system capabilities with the exception of the new Replica Management mechanism, and provide an easy to use interface to different kind of scientists. The implementation relies on HTML and perl scripts. The approach promotes both rapid prototyping and reuse, as demonstrated by the application portals that have been build in a few weeks using GridPort. Fundamental capabilities for a grid portal like job submission, monitoring and data transfer are provided, however the presentation does not cover sufficiently how the scheduling is done (user driven or automatic?). The section on the web services architecture is extremely relevant and presents key concepts for grid portals future directions. Also important is the access for mobile users using wireless devices. F: Presentation Changes The paper is written in a clear, concise style; it is easy to read and well organized. A section with details on scheduling should be added. Abstract, last sentence: ...system that being studied... should be ...system that is being studied... Section 1, last sentence: same Abstract correction Section 1.2, first sentence: ...that the creation of new portals...should be: ...that new portals... Section 2, last paragraph, first sentence: ... on the same system are use the same...should be: ...on the same system use the same... Section 2.4, second paragraph, third sentence: ...developing portals to this system...should be: ...developing portals with this system... Section 4.1, first paragraph, third sentence: Figure 3 should be Figure 7 Section 5, first paragraph, third sentence: We find should be we found Figures 5,6,7 are not clearly readable. Figure 1 shows GSI-FTP as "future", but the paper says it is already used in GridPort. Referee 2 ******************************************* This paper,submitted after the deadline,appears to have been hastily and sloppily prepared. It is considerably less polished than other submissions.It is poorly organized,replete with obscure (outside the authors ’"in crowd ")acronyms and jargon,has poor quality figures,and fails to offer any insight or thoughtful assessment of the authors' portal building experience. It is acceptable only after a major revision. A better title would be "Experience with the GridPort Toolkit ",since the paper doesn’t really address application portals in general. 1.Abstract "We have demonstrated ...extend multiple sites."This sentence should read "...portal en- vironments,and that the software ...". 2.Abstract "Finally,we discuss ...".Replace "being studied "with "is ". 3.Page 1,line 12 "unique methodology ".Claim to uniqueness is debatable. 4.Page 1,line 24 "time to describe the project " 5.Page 1,line 29 "Finally,we discuss ..."Replace "being studied "with "is ". 6.Page 2 GridPort appears to be middleware between HotPage and Globus,and thus inextricably tied to these two.Isn’t it presumptuous to assume that HotPage and Globus are the world standards for their respective functions? 7.Page 2,line 23 "separating our portal software into a Globus Perl CoG."Separating into Perl CoG and what else? 8.Page 2,line 33 "on the through ":On the what? 9.Page 2,line 49 "primary mechanism " 10.Page 3,line 1 "data about ":Data about what? 11.Page 3,line 4 O2K is not the name of any SGI system.What are these systems?How many processors, what operating system,what memory model? 12.Page 3,line 8 De .ne SRB. 13.Page 3,line 15 "Indiana ". 14.Page 3,line 16 De .ne CA. 15.Page 3 figure 1 "software/services that are currently " 16.Page 4,line 9 "on the same system use the same " 17.Page 5,line 5-7 These claims of a converged community and an accepted standard are premature and arrogant. The organizations listed in 1.4 by no means constitute the entire GCE community.GIS is a bad choice of acronym,since it means "geographic information system "to the rest of the world. 18.Page 5,line 45-46 Define LDAP and LDIF.Are all these acronyms really necessary?They make the paper hard to read. 19.Page 6,line 33 Define SSL. 20.Page 7,line 6 "this user must ". 21.Page 7,line 20 "We have found that developing portals to this system is good for startup."What does this mean? 22.Page 7,figure 3 The arrow directions do not make sense.How can there be no arrows going out from the Jobs box? 23.Page 8,line 8-10 This point should be emphasized,since the demands on a portal architecture for the former (canned codes)are considerably less than for the latter (optimization and model development.) 24.Page 8,Figures 4-5 Figures 4 and 5 are useless.Showing a few windows with unreadable text conveys no infor- mation to the reader. 25.Page 12,Section 5 Given the title of the paper,emphasizing practice and experience,the paper would be much stronger if a more careful and critical assessment was made as to the efficacy of the GridPort toolkit.The paper claims that the system has proven to "be a robust and flexible programming environment."At the least,this statement should be qualified by explaining the narrow sense in which the term "programming "is used here,i.e.,helping users access community models over the grid.Furthermore,some details about where the system still needs work or improvement would make the paper stronger.As it is,the paper simply says that the portal development needs to be simpler.Do the authors have some specific ideas about how this will be possible? Referee 3 ******************************************* E: Referee Comments (For Author and Editor) ------------------------------ The paper describes the successful work at SDSC to develop production caliber portals that implement grid services. * In section 2.3, the authors describe the use of cookies in security. Cookies are the standard way to maintain session state between client and server that are using HTTP but are not used specifically for security by servlet engines. * Not necessary but possibly interesting: since the paper deals with practice and experience with application portals, it would be interesting to describe any security problems that have come up while HotPage has been active, how they were dealt with, what steps were taken afterwards (i.e., a portal security lessons learned section). * I recommend a careful rereading to catch some typographical errors. Also, Figure 6 is hard to read. F: Presentation Changes See previous note.