WIXLIB

portal systems with minimal programmingexpertise, and that is relatively easy to install.§ Use common Grid technologies and standards:minimize impact on already burdened resourceadministrators by eliminating the need for proprietaryGridPort daemon on HPC resources.§ Provide a scalable and flexible infrastructure: Facilitateadding/removing Grid resources, services, jobs, andusers.§ Security: support HTTPS/SSL encryption at all layers,and provide access control.§ Single login: Required for easy access to and navigationbetween Grid resources.§ Adopt Global Grid Forum standards:activelycollaborate and promote Global Grid Forum activities.§ Client applications and portal services should be able torun on separate webservers: Enable scientists to buildtheir own application portals and use existing portals forcommon infrastructure services.As a result of these design goals, and lessonslearned from building several production Grid portals, wehave arrived at a Grid portal system that meets most ofthe goals mentioned above, and presents a scalable,generalized solution for Grid portal development. Theproject has met all of the goals set above with theexception of the last goal, though an architecture inwhich clients host Grid application portals on localsystems and use the NPACI portal services is indevelopment and has been successfully prototyped. It isdiscussed in the Application Portals section of thispaper.2.2Related WorkThere are a variety of projects designed to ronments such as Gateway [16], WebSubmit [20],and the NCSA Portals Notebook and ChemWorkbenchprojects [21]. Note that the Computing PortalsOrganization web site maintains a current list of projects[3]. All of these projects are web-based interfaces to adistributed set of HPC resources, and we discuss 3projects that are typical of current approaches to portaltechnologies.Gateway employs a programming model that isimplemented as a virtual metacomputer. Evolving fromthe WebFlow project [22], it is based on object-orientedtechnologies. The user interface consists of userprogrammable modules that interact with a system ofdistributed Gateway servers, via secure applets.Gateway plans to use Globus to access HPC resources,but Gateway requires that a Gateway server run on eachHPC system. GridPort avoids this complexity by using theweb server to process and build Globus commands andthen communicate directly with the Globus processes onthe HPC systems. In addition, we have decided not to useapplets and Java, since they are not supported on allbrowsers.The NCSA ChemWorkbench project is a componentbased approach that provides access to Grid services andresources through an application running on the desktopand employs components that are objects and that useXML to describe public interfaces and protocols. Basedon software developed by the Common ComponentArchitecture Forum, the Workbench project is testinghow well these components facilitate distributedcollaboration.WebSubmit is an early portal project, and providesbasic functions such as file transfer, directorymanipulation, and job execution. The GridPort toolkit andWebSubmit projects are very similar: both are based onthe use of CGI scripts, and both provide web-based userinterfaces. Differences between the projects ile in thesecurity model and the way in which the back-endservices are implemented. Where possible, the GridPortsoftware takes advantage of grid services such asGlobus, whereas WebSubmit uses SSH and specificallybuilt commands for each system. We note that Globuswas not readily available at the time that WebSubmit wascreated.At this time, we are aware of only a few projectsspecifically devoted to developing portal software at thetoolkit level, such as the Grid Portal Development Toolkit(GPDK) [23], a Java Servlet implementation with manysimilar functions to those of GridPort, and the GlobusCommodity Grid Toolkit project [24], a clearinghouse formany toolkits that interface to the GlobusMetacomputing Toolkit.3.The GridPort ToolkitThe GridPort Toolkit has been in use as the backendengine for the NPACI HotPage and other applicationportals since 1999, and has undergone continuouschange as the needs of multiple application portals haveevolved. Recently, the GridPort software has beenupdated and generalized to increase security, support abroader range of services, and make porting it to othersites easier and faster.The toolkit has been modified so that multipleapplication portals can access the same instance of theGridPort toolkit library. This is important for two reasons.First, each application portal such as the HotPage must

Figure 1. The diagram shows the layers discussed in the previous section, and indicates the types ofclient devices and portals and software/services are currently in use or that we plan to install in the nearfuture.be able to manage its own filespace, and also use theGridPort libraries. For multiple instances of portals, itbecomes complex and cumbersome to have to install acopy of the GridPort libraries for each portal. This canpresent maintenance challenges in the event that thelocal portal administrator has to modify some part of thecode, or move the portal home directories. Second,GridPort supports single login: this is accomplished byrequiring, at present, that all portals be hosted on thesame domain (for example, npaci.edu). Portals hosted byservers in the npaci.edu domain can access the samesecurity data (e.g. cookies), which contain encryptedinformation about the session data. This is discussed inthe Security section below.The current GridPort portal system is shown inFigure 1. In this schematic, we represent different partsof the portal system as layers. Each layer represents alogical part of the portal where data and service requestsflow back and forth, and handles some specific aspect orfunction of the GridPort portal system. These layers are:Clients:These are typically web browsers.However, we have included other portals as clients,based on the web-services software that we aredeveloping. This is discussed in detail in Section 4.3.1.NPACI Portals: Currently, NPACI applicationportals exist on the same machine and are served toclients by separate virtual webservers, and they all usethe same instance of the GridPort libraries. This allowsthem to share data, libraries, filespace, and otherservices on the webserver machine. The bottom portal isa web-service portal, and is intended to be used by otherapplications and clients (see Section 4).Portal Services. In addition to mediating betweenclient requests and Grid services, the GridPort softwarealso performs services for the portals and users such asmanaging session state and portal accounts and filecollections, and monitoring the GIS system. These areservices that are portal specific, and are not typicallyaddressed by Grid or web developers.Grid Services and Compute Resources. These layersare the standard middle and backend tiers of the Grid, andrepresent the layer where Grid services such as Globus,Legion, SRB, NWS, Apples and Metaschedulers areavailable.3.1Technologies EmployedWherever possible, the GridPort Toolkit employssimple technologies. On the client side, we do not requirethe use of client-side XML or applets, since some of ourusers still use older browsers and platforms that do notsupport these technologies. On the server side, we choseto implement the portal software in Perl/CGI since thissoftware is easy to install under most webservers and issupported on all HPC systems, making it easy for portaldevelopers to install and support. We realized that morecomplex technologies such as Java and CORBA could beused to provide more advanced services, but using thosetechnologies would not further our goal of enablingtechnology transfer. However, several current portalresearch projects such as Gateway [16], the MissisipiPortal [25] and the Grid Portal Development Kit [23]employ these technologies and have demonstrated theirusefulness and stability, making them reasonable

candidates for further investigation and possible use inGridPort.The GridPort Toolkit v2.0 is implemented in Perl5/CGI, and has been installed and tested under bothNetscape and Apache webservers. It should run on anyUnix/Linux OS/webserver combination that supportsSSL encryption and the HTTPS protocol and has therequired Perl/CGI libraries installed. At NPACI, thewebserver software used is Netscape Enterprise runningon Solaris.Data and configuration files are used by many scriptsat run-time. Typically, these are flat text ASCII files thatare easily changed by site administrators. At NPACI,some of the data used in these files is generated fromdatabases. In general, we avoid live database hits inorder to reduce latencies and to ensure that the portal isable to deliver services even if the database server isinaccessible.GridPort makes use of other key Grid technologies.The Globus/GRAM gatekeeper is used to run interactivejobs and tasks on remote resources [15]; Globus GridSecurity Infrastructure (GSI) and Myproxy are used forsecurity and authentication [15][26]; the SDSC StorageResource Broker (SRB) is used for distributed filecollection and management [27]; and the Globus GridInformation Systems/Grid Resource Information System(GIS/GRIS) is used for information services [15].3.2. Services SupportedPortals using the GridPort system provide twocategories of services to the application portals runningon the system: informational and interactive. Interactiveservices require user authentication, while informationalservices are open to any users without logging in to theportal. GridPort functions are used primarily byinteractive services at this time.Interactive services are the secure transactions thatprovide users with direct access to HPC computeresources and allow the webserver to perform tasks forthe user on those resources. To access interactiveservices, the user needs to login and authenticate viaweb pages. For this, we use the Grid SecurityInfrastructure (GSI) provided by the Globus Toolkit.Each interactive portal user needs a unique portalaccount, the creation of which requires valid accountson the resources supported by the portal. The portalmanages the user’s portal account and keeps track ofsessions, user preferences, and portal filespace. GridPortprovides a single login environment for multiple portals(though there are certain constraints on portal setup,discussed below in the section on security issues). Oncea user is logged into an NPACI portal, the user hasaccess to any NPACI-hosted portal that is part of thesingle login environment.Currently, GridPort v2.0 supports the followinginteractive functions:Accounts: The portal manages the user’s accountand keeps track of sessions, user preferences, and portalfilespace. All portal users must create a portal account,and they must have a valid PKI/GSI certificate. Currently,the NPACI portals accept certificates from several sites(such as NPACI, Alliance, NASA/IPG, Cactus, andGlobus). For NPACI users, we have created an on-linecertificate creation system.Authentication: Users can log on to NPACI portalsusing two mechanisms: either authentication againstcertificate data stored in the SDSC repository, or by usingthe Myproxy server. Most of our users do not care tomanage and handle certificates, and many of them aremobile, making it even more complex to handle thesecertificates. For example, if a user is logging into a portalon a public browser at the airport, she will most likely nothave access to her certificate. Until the use of secure IDcards (or a similar mechanism) is universally supported,we have chosen to implement a secure repository for ourusers. This is discussed in detail below.Jobs: All remote tasks are currently executed via theGlobus/GRAM gatekeeper. To execute any job or taskthrough the portal, a series of steps must be completed inorder for the transaction to occur: (1) user login statusmust be confirmed, (2) the job command is parsed, (3) theuser’s environment is established, (4) a Globus RSLcommand is assembled, (5) the user proxy is verified orrecreated, (6) the command is issued to the Globusdaemon running on the remote host, and (7) the resultsare parsed, formatted, and returned to the web browseron the user’s workstation, stored on the portal, ortransferred to the user’s SRB file collection. GridPortsupports compiling and running programs, performingjob and batchscript submission and deletion, and viewingof job status and history.Command execution: Users may execute simple Unixtype commands such as mkdir, ls, rmdir, cd, and pwd. Thesteps in performing command execution are similar tothose used in managing jobs.Files: By providing file and directory access tocompute and archival resources and portal file space,GridPort enables file transfer between the localworkstation and the HPC resources. Users can alsoperform common file management operations on remotefiles, such as tar/untar, gzip/gunzip, and movement toarchival storage.

It is easy to modify the GridPort toolkit to add morefunctionality, or to reflect local site policies (such as useof additional authentication mechanisms).3.3. Resources SupportedThe current version of the GridPort toolkit employsthe Globus Toolkit as the mechanism for connecting toremo te computational resources. Any system runningGlobus can be added to the system by incorporating thedata about the system into a flat text configuration file.Currently, the NPACI Portals connect to the followingsystems: IBM (Blue Horizon, SP); Compaq (TCS1);CRAY (T3E, T90); Sun (E10K); SGI (O2K); HewlettPackard (V2500); and various workstations and clustersrunning Globus. These resources are located at severalsites, including SDSC, NCSA, Pittsburgh SupercomptingCenter, NASA/IPG, UT Austin, Univ. of Kentucky, andothers. In addition, we can access file archival systemsrunning software compatible with the PKI/GCI certificatesystem, and we have recently added the ability to accessany file system running an SRB service.3.4. Security IssuesSecurity between the client web browser and the webserver is handled by SSL using a 56- or 128-bit key. Forcommunications between the web server and the grid,the SSL RSA X509 certificate technology that is afeature of the GSI Toolkit authentication system(gssapi ssleay) is employed.User authentication is accomplished by providingthe portal with a valid proxy file. The proxy may begenerated from a key/certificate pair or the portal mayretrieve the proxy on behalf of the user from a Myproxyserver. The password used for proxy retrieval or proxygeneration by the portal is never stored and travels theinternet via a secure https connection.Session files and other sensitive data like userproxies are stored in a restricted access portalrepository. The repository directory structure is locatedoutside of webserver filespace, and has user and grouppermissions set such that no user except the webserverdaemon may access these files and directories. Userlogin sessions are tracked via a browser cookie which isassigned a random value by the webserver when theuser successfully authenticates to the portal. Therandom value in the cookie corresponds to a session file,which ties the cookie in the user’s browser to a specificuser on the portal. The session file also contains atimestamp which GridPort uses to expire user loginsessions that have been inactive for a set period of time.Portal users must create a portal account. The creationprocess requires the user to to supply the portal with adigital certificate from a known Certificate Authority(CA). Once the user has presented the portal with thiscredential, the user will be allowed to use the portal withthe digital identity contained within the certificatepresented to the portal. In order to access acomp utational resource through the portal, the user mustalready have privileges on that computational resource.When a portal uses GridPort to make a request on behalfof the user, GridPort presents the user’s credentials to thecomputational resource, which decides based on the localsecurity model whether the request will be honored ordenied. The portal acts as a proxy, executing requests onbehalf of the user on resources that the user is authorizedto access based on the credentials they presented whenthey created their portal account. Portal users have thesame level of access to a particular resource through theportal as they would if they logged into the resourcedirectly.3.5. Using GridPortIn order to install GridPort, it is necessary to have aserver running an http daemon that supports CGI scriptsand secure connections via the https protocol. Theserver must have a working installation of Perl, version5.0 or newer. In addition, GridPort uses the Globus clienttools that must be installed on the webserver. The currentGridPort snapshot was developed on a Solaris 2.5.1machine running the Netscape Enterprise web server, Perl5.004 04, and Globus 1.1.3.The GridPort software may be downloaded fromhttps://gridport.npaci.edu/downloads. To install it, untarthe GridPort tar file into a directory outside of webserverfilespace, but that is accessible by the user the webserverdaemon. Then step through each directory in the GridPorttree, read the included README files, and modify theconfiguration files as appropriate.The portal software that is using GridPort shares thesame filespace as the GridPort Toolkit. The applicationportal developer incorporates the GridPort librariesdirectly into the code, and makes subroutine calls toGridPort software to access the functionality thatGridPort provides. Once GridPort has been installed andconfigured, building tools based on the GridPort code issimple, yet enables complex behavior. A batch jobsubmission tool from the HotPage, for example, containsonly three lines of code that reference GridPort. The restof the 750 lines of Perl code are specific to the needs ofthe HotPage portal, and consist mostly of html formattingcode. Each of the CGI scripts for all of the application

portals developed with GridPort follow this patternclosely, using between 3 and 6 lines of Perl code toaccess GridPort functions.Science portals based on HotPage and GridPorttechnologies have been implemented at the NASAInformation Power Grid, the Department of DefenseNaval Oceanographic Office Major Shared ResourceCenter, the National Center for Microscopy and ImagingResearch (NCMIR), the University of SouthernCalifornia (USC), the Daresbury Labs, UK, and the SanDiego Supercomputer Center. The GridPort researcheffort has also resulted in collaboration among portaldevelopment groups at NPACI, NCSA, the Globusproject, and NASA IPG to develop a common PACI-widegrid portal, the PACI HotPage. The goal of thecollaboration is to develop a common grid infrastructureso that user portals can access resources across all thecollaboration sites. Many of the sites that started portaldevelopment with HotPage code have gone on to buildtheir own portal systems, which was the goal of thetechnology transfer aspect of this project.3.6. LimitationsThe GridPort Toolkit has proven to be very usefuland modular software. The code has been ported toseveral systems and is used for multiple productionapplications. However, due to the design constraintsand chosen technologies, there are limitations to thesystem. First, the portal software is based on Perl/CGI,which is known to have lower performance onwebservers than technologies such as Java servlets dueto the fact that each time a new request arrives, thewebserver must instantiate a new Perl process. There aresoftware systems available that incorporate Perlprocesses into the webserver process, but we have notused them. However, in the day-to-day operation of theHotPage and other portals, we have not really noticedany unacceptable latencies associated with using Perl.There are latency issues associated with the portalsystems. This becomes a perception problem, sinceportal users tend to have expectations that events onthe portal will happen instantaneously, which is notalways the case. The latencies are due to factors such asfile upload/dowload/transfer through the webserveritself, network latencies (out of the control of the portalsoftware), and known latencies associated with usingthe Globus GRAM gatekeeper.There are other latencies associated with how thewebpages are built. As discussed above, due to thetypical profile of users within the PACI community, wehad to limit client side features to the simplest set, andso the pages are constructed of simple HTML andjavascript, and all the portals are frames-based (frames areused to display results and request status). The result isthat the portal itself is often much simpler in layout anddesign than one that would be built as an applicationrunning locally using advanced technologies such asJava. We approach this from a ‘level of service’ view: as aportal user community becomes more sophisticated, weadd more advanced technologies. For example, in theGAMESS portals , user now have the option to install alocal version of OpenGL visualization software, anddownload the QMView plugin and interactively viewresults.Getting Grid Portal accounts is cumbersome. Thecurrent GridPort toolkit supports users with GSIcertificates, and we can only ma

boisseau@tacc.utexas.edu Abstract Grid portals are emerging as convenient mechanisms for providing the scientific community with familiar and simplified interfaces to the Grid. Our experience in implementing Grid portals has led to the creation of GridPort: a unique, layered software system for building Grid Portals. This system has several