Subject: RE: PSE (Re: ITR Pre-proposal) Resent-Date: Fri, 17 Dec 1999 12:19:20 -0500 Resent-From: Geoffrey Fox Resent-To: p_gcf@npac.syr.edu Date: Fri, 17 Dec 1999 11:52:39 -0500 From: "Manish Parashar" To: "Tomasz Haupt" , "Dick Pritchard" CC: bedford.1@osu.edu, root.1@osu.edu, mfw@brahma.ticam.utexas.edu, gcf@npac.syr.edu, kenf@osc.edu, clint@brahma.ticam.utexas.edu, "Connie Pritchard" , welsh@superior.eng.ohio-state.edu, mpesz@brahma.ticam.utexas.edu, sadayappan.1@osu.edu, sbryant@brahma.ticam.utexas.edu, bromwich.1@osu.edu, "Sharon Kraft" Tom, The writeup looks very good and would probably be sufficient for the preproposal. I had a couple of suggestions: 1) I might be a good idea to havei a specific enumeration of the CS research contributions of the proposed work. The text makes it sound "generic" which this work certainly is not. 2) It seems to be separate from the application rather than driven by it. This will probably come in the next iteration once the two parts are tied together. The idea would be to have the each of the "features" of the PSE are driven by a critical need of the overriding application. 3) We could structure it a little but that can wait will the actual proposal. Let me know if you need me to take a cut at something. Regards Manish > -----Original Message----- > From: Tomasz Haupt [mailto:haupt@npac.syr.edu] > Sent: Friday, December 17, 1999 1:16 AM > To: Dick Pritchard > Cc: bedford.1@osu.edu; root.1@osu.edu; mfw@brahma.ticam.utexas.edu; > gcf@npac.syr.edu; kenf@osc.edu; parashar@caip.rutgers.edu; > clint@brahma.ticam.utexas.edu; Connie Pritchard; > welsh@superior.eng.ohio-state.edu; mpesz@brahma.ticam.utexas.edu; > sadayappan.1@osu.edu; sbryant@brahma.ticam.utexas.edu; > bromwich.1@osu.edu; Sharon Kraft > Subject: PSE (Re: ITR Pre-proposal) > > > > > Dick Pritchard wrote: > > > OK, gang. Based on our Monday meeting and lots of help from the > CSM gang at > > UT-Austin, here's the next cut. It's within the page limits, > but there are > > some missing pieces, most notably the PSE diagram and text. > > > > Tom Haupt is my focal point for the PSE, but I'm > > assuming that Manish and Ken are chiming in. Clint and Mary for UT. > > Please find attached PSE text. A diagram will follow. > You may find my text a little too lengthly. Unfortunatelly, my > English is not > good enough to compactify it without making it incomprehensible. > Fill free to > improve (and unPolish). Anyway, I expect a feedback from Ken and Manish. > Tom > > Just in case you do not have MS Word on your unix workstation: > > PSE framework > > The goal of this Problem Solving Environment is to provide the > researcher with > a problem-oriented interface to more effectively utilize High Performance > Computing (HPC) resources from the desktop via the Web browser. > This "point & > click" view hides the underlying complexities and details of the > HPC resources > and creates a seamless interface between the user's problem > description, the > user's desktop system and the heterogeneous computing resources. > These HPC > resources include supercomputers, mass storage systems, > databases, workstation > clusters, collaborative tools, and visualization servers. In addition to a > seamless access to resources, the researcher will be provided > with a set of > tools for composing of applications from independently developed > modules. The > user will be assisted by a knowledge system to select adequate components. > > The proposed Problem Solving Environment will be implemented as a > three-tier > system, a prototype of which has been successfully demonstrated within the > Gateway project. A web browser based front end will provide > visual tools to > define a problem to be solved. The middle tier that implements a > distributed > component model (CORBA components in Java), will then transform > the problem > descriptor into a computational task to be executed using back > end resources. > The middle tier components will be placed in a hierarchical collection of > object containers (similarly to the JavaBeans model). The containers will > provide common services such as component life-cycle management, component > persistence, security, and inter-component communications based on event > notification (similarly to DCOM and Enterprise JavaBeans). This > way, the task > of the module developer will be reduced to implementation of the module > business logic only. Generally, the modules will act as proxies > for services > rendered by the back end. Here we follow the standard industry model of > accessing databases: a middle tier component implementing a JBDC interface > serves as a proxy of the back end DBMS. We extend this model to > include HPC > resources. For example, a proxy module for job submission and control will > implement the emerging Grid Interface, currently approximated by > the Globus > matacomputing toolkit API. > > Implementation of the PSE involves many challenges. Unlike the > Gateway project, > the most prominent feature of the system will be capability to compose > applications of independent, distributed modules. The research > issues to be > addressed here include specification in the problem descriptor > how the modules > interacts with each other (within a single address space, and > "meta-application > couplings"; grid to grid communications and boundary exchanges; different > spatial and temporal resolutions, to name a few). In most cases, > the couplings > will require high performance communication protocols. A CORBA > based system, > very adequate for communications between the middle tier > components, does not > guarantee performance needed for communications between > computational objects > in the back end. Our research goal here is to provide a solution > in form of a > proxy communication channels between proxies objects in the > middle tier to be > realized in the back end as a platform dependent high performance > channels. > This kind of solution is necessary to fulfill our fundamental goal of > separating the process of generating the problem description in > the front end > from the complex details of actual implementation of the > application in the > back end. Finally, we want to investigate other back end issues > such as runtime > adaptation as the result of the resources and application > dynamics as well as > enabling interactive experimentation. The issues will include > determining both > the policies regarding when to adapt and the mechanics regarding > how to adapt. > It will also deal with deploying control points at which users can > interact/experiment with the applications. > > > > > > >