Tài liệu Grid Computing P28 ppt

28 Building Grid computing portals: the NPACI Grid portal toolkit Mary P. Thomas and John R. Boisseau The University of Texas at Austin, Austin, Texas, United States 28.1 INTRODUCTION In this chapter, we discuss the development, architecture, and functionality of the National Partnership for Advanced Computational Infrastructure NPACI Grid Portals project. The emphasis of this paper is on the NPACI Grid Portal Toolkit (GridPort); we also dis- cuss several Grid portals built using GridPort including the NPACI HotPage. We dis- cuss the lessons learned in developing this toolkit and the portals built from it, and finally we present our current and planned development activities for enhancing Grid- Port and thereby the capabilities, flexibility, and ease-of-development of portals built using GridPort. 28.1.1 What are Grid computing portals? Web-based Grid computing portals, or Grid portals [1], have been established as effec- tive tools for providing users of computational Grids with simple, intuitive interfaces for accessing Grid information and for using Grid resources [2]. Grid portals are now being Grid Computing – Making the Global Infrastructure a Reality. Edited by F. Berman, A. Hey and G. Fox  2003 John Wiley & Sons, Ltd ISBN: 0-470-85319-0 676 MARY P. THOMAS AND JOHN R. BOISSEAU developed, deployed, and used on large Grids including the National Science Founda- tion (NSF) Partnership for Advanced Computational Infrastructure (PACI) TeraGrid, the NASA Information Power Grid, and the National Institute of Health (NIH) Biomedical Informatics Research Network. Grid middleware such as the Globus Toolkit provides powerful capabilities for integrating a wide variety of computing and storage resources, instruments, and sensors, but Grid middleware packages generally have complex user interfaces (UIs) and Application Programming Interfaces (APIs). Grid portals make these distributed, heterogeneous compute and data Grid environments more accessible to users and scientists by utilizing common Web and UI conventions. Grid portals, and other Web-based portals, provide developers and users with the capabilities to customize the content and presentation (e.g. page layout, level of detail) for the set of tools and services presented. Grid portals can enable automated execution of specific applications, provide explicit links to discipline-specific data collections, integrate (and hide) data workflow between applications, and automate the creation of collections of application output files. Portals can also provide a window to the underlying execution environment, reporting the availability of resources, the status of executing jobs, and the current load on the Grid resources. The software used to build Grid portals must interact with the middleware running on Grid resources, and in some cases it must provide missing functionality when the Grid middleware is not available for a specific resource or it is lacking capabilities needed by the Grid portal. The portal software must also be compatible with common Web servers and browsers/clients. Several generalized Grid portal toolkits have emerged that help simplify the portal developer’s task of utilizing the complex Grid technologies used for Grid services and making them available via a familiar Web interface. With the advent of Web services, interoperable protocols and standards are now being developed for Grid information and other Grid services. Web services will further simplify the use of Grids and Grid technologies and will encourage the use and deployment of more general Grid applications on the Grid. As Grid portal toolkits and the underlying Grid technologies mature and as Web services standards become more common, Grid portals will become easier to develop, deploy, maintain, and use. Software for creating Grid portals must integrate a wide variety of other software and hardware systems. Thus, portals represent an integration environment. This is part of the unique role that portals play at the Grid middleware layer: portals drive the integration of ‘lower’ middleware packages and enforce the integration of other toolkits. Furthermore, projects such as the GridPort [3], the Grid Portal Development Toolkit [4], and the Com- mon Component Architecture project [5] have demonstrated that integrated toolkits can be developed that meet the generalized needs of Grid applications as well as Web-based Grid portals. 28.1.2 History and motivation The NPACI, led by the San Diego Supercomputer Center (SDSC), was initiated in 1997 by the NSF PACI program [6]. NPACI is charged with developing, deploying, and sup- porting an advanced computational infrastructure – hardware, software, and support – to enable the next generation of computational science. NPACI resources include diverse BUILDING GRID COMPUTING PORTALS: THE NPACI GRID PORTAL TOOLKIT 677 high performance computing (HPC) architectures and storage systems at SDSC and at university partners. US academic researchers may apply for accounts on multiple resources at multiple sites, so NPACI must enable users to utilize this distributed collection of resources effectively. The NPACI HotPage was developed to help facilitate and support usage of the NPACI resources. The HotPage initially served as an informational portal for HPC users, espe- cially those with accounts on multiple NPACI systems [7, 8]. The World Wide Web had recently become established as a popular method for making information available over the Internet, so the HotPage was developed as a Web portal to provide information about the HPC and the archival storage resources operated by the NPACI partner sites (SDSC, the University of Texas at Austin, the University of Michigan, Caltech, and UC-Berkeley). As an informational service, the HotPage provided users with centralized access to tech- nical documentation for each system. However, the HotPage also presented dynamic informational data for each system, including current operational status, loads, and status of queued jobs. The integration of this information into a single portal presented NPACI users with data to make decisions on where to submit their jobs. However, the goals of the HotPage included not only the provision of information but also the capability to use all NPACI resources interactively via a single, integrated Web portal. Grid computing tech- nologies, which were supported as part of the NPACI program, were utilized to provide these functionalities. In 1999, a second version of the HotPage was developed that used the Globus Toolkit [9]. Globus capabilities such as the Grid Security Infrastructure (GSI) and the Globus Resource Allocation Manager (GRAM) enabled the HotPage to provide users with real time, secure access to NPACI resources. HotPage capabilities were added to allow users to manage their files and data and to submit and delete jobs. This version of the HotPage has been further enhanced and is in production for NPACI and for the entire PACI program. Versions of the HotPage are in use at many other universities and government laboratories around the world. The mission of the HotPage project has always been to provide a Web portal that would present an integrated appearance and set of services to NPACI users: a user por- tal. This has been accomplished using many custom scripts and more recently by using Grid technologies such as Globus. The HotPage is still relatively ‘low level’, however, in that it enables NPACI users to manipulate files in each of their system accounts directly and to launch jobs on specific systems. It was apparent during the development of the HotPage that there was growing interest in developing higher-level application portals that launched specific applications on predetermined resources. These application portals trade low-level control of jobs, files, and data for an even simpler UI, making it possible for non-HPC users to take advantage of HPC systems as ‘virtual laboratories’. Much of the functionality required to build these higher-level application portals had already been developed for the HotPage. Therefore, the subset of software developed for Hot- Page account management and resource usage functions was abstracted and generalized into GridPort. GridPort was then enhanced to support multiple application portals on a single Grid with a single-login environment. The usefulness of this system has been suc- cessfully demonstrated with the implementation and development of several production application portals. 678 MARY P. THOMAS AND JOHN R. BOISSEAU The driving philosophy behind the design of the HotPage and GridPort is the convic- tion that many potential Grid users and developers will benefit from portals and portal technologies that provide universal, easy access to resource information and usage while requiring minimal work by Grid developers. Users of GridPort-based portals are not required to perform any software downloads or configuration changes; they can use the Grid resources and services via common Web browsers. Developers of Grid portals can avoid many of the complexities of the APIs of Grid middleware by using GridPort and similar toolkits. Design decisions were thus guided by the desire to provide a generalized infrastructure that is accessible to and useable by the computational science community. If every Grid portal developer or user were required to install Web technologies, por- tal software, and Grid middleware in order to build and use portals, there would be a tremendous duplication of effort and unnecessary complexity in the resulting network of connected systems. GridPort attempts to address these issues by meeting several key design goals: • Universal access: enables Web-based portals that can run anywhere and any time, that do not require software downloads, plug-ins, or helper applications, and that work with ‘old’ Web browsers that do not support recent technologies (e.g. client- side XML). • Dependable information services: provide portals, and therefore users, with centralized access to comprehensive, accurate information about Grid resources. • Common Grid technologies and standards: minimize impact on already burdened re- source administrators by not requiring a proprietary GridPort daemon on HPC resources. • Scalable and flexible infrastructure: facilitates adding and removing application portals, Grid software systems, compute and archival resources, services, jobs, users, and so on. • Security: uses GSI, support HTTPS/SSL (Secure Sockets Layer) encryption at all lay- ers, provide access control, and clean all secure data off the system as soon as possible. • Single login: requires only a single login for easy access to and navigation between Grid resources. • Technology transfer: develops a toolkit that portal developers can easily download, install, and use to build portals. • Global Grid Forum standards: adhere to accepted standards, conventions, and best practices. • Support for distributed client applications and portal services: enables scientists to build their own application portals and use existing portals for common infrastruc- ture services. Adhering to these design goals and using the lessons learned from building several production Grid portals resulted in a Grid portal toolkit that is generalized and scal- able. The GridPort project has met all of the goals listed above with the exception of the last one. A Web services–based architecture, in which clients host Grid application portals on local systems and access distributed Grid Web services, will address the last design goal. As these Grid portal toolkits continue to evolve, they will enable developers, and even users, to construct more general Grid applications that use the Grid resources and services. BUILDING GRID COMPUTING PORTALS: THE NPACI GRID PORTAL TOOLKIT 679 28.1.3 Grid portal users and developers The Grid is just beginning the transition to deployment in production environments, so there are relatively few Grid users at this time. As Grids move into production, users will require much assistance in trying to develop applications that utilize them. In the NPACI HPC/science environment, there are three general classes of potential Grid users. First, there are end users who only run prepackaged applications, most com- monly launched in Unix shell windows on the HPC resources. Adapting these applications to the Grid by adding a simple Web interface to supply application-specific parameters and execution configuration data is straightforward. Therefore, this group will be easiest for transition to using Grids instead of individual resources, but most of the work falls on the Grid portal developers. These users generally know little about the HPC systems they currently use – just enough to load input data sets, start the codes, and collect output data files. This group includes users of community models and applications (e.g. GAMESS, NASTRAN, etc.). Many of the users in this group may never know (or care) anything about HPC or how parallel computers are running their code to accomplish their sci- ence. For them, the application code is a virtual laboratory. Additionally, there exists a large constituency that is absent from the HPC world because they find even this modest level of HPC knowledge to be intimidating and/or too time-consuming. However, with an intuitive, capable application portal, these researchers would not be exposed to the HPC systems or Grid services in order to run their application. Effective Grid portals can provide both novice and potential HPC users with simple, effective mechanisms to utilize HPC systems transparently to achieve their research goals. The second group consists of researchers who are more experienced HPC users and who often have accounts on multiple HPC systems. Most current NPACI users fall into this category. For them, building HPC applications is challenging though tractable, but as scientists they prefer conducting simulations with production applications to developing new code. While this group will accept the challenges inherent in building parallel com- puting applications in order to solve their scientific problems, they are similar to the first group: their first interest is in solving scientific problems. For this group, a user portal like the HotPage is ideal: it provides information on all the individual systems on which they have accounts. It allows users to learn how to use each system, observe which systems are available, and make an assessment of which system is the best for running their next simulations. While they already have experience of using Unix commands and the com- mands native to each HPC system on which they have ported their codes, the HotPage allows them to submit jobs, archive and retrieve data, and manage files on any of these from a single location. For these users, a user portal like the HotPage cannot replace their use of the command line environment of each individual system during periods of code development and tuning, but it can augment their usage of the systems for production runs in support of their research. The third group of HPC users in our science environment includes the researchers who are computational experts and invest heavily in evaluating and utilizing the latest computing technologies. This group is often at least as focused on computing technologies as on the applications science. This group has programmers who are ‘early adopters’, and so in some cases have already begun investigating Grid technologies. Users in this group 680 MARY P. THOMAS AND JOHN R. BOISSEAU may benefit from a user portal, but they are more likely to build a Grid application using their base HPC application and integrating Grid components and services directly. In addition, there are also Grid developers who develop portals, libraries, and applications. For these Grid users and for Grid developers, a Grid application toolkit is ideal: something like GridPort, but enhanced to provide greater flexibility for applications in general, not just portals. 28.2 THE GRID PORTAL TOOLKIT (GRIDPORT) GridPort has been the portal software toolkit used for the PACI and NPACI HotPage user portals and for various application portals since 1999. It was developed to support NPACI scientific computing objectives by providing centralized services such as secure access to distributed Grid resources, account management, large file transfers, and job management via Web-based portals that operate on the NSF computational Grid. Implementation of these services requires the integration and deployment of a large and diverse number of Web and Grid software programs and services, each with a different client and server software and APIs. Furthermore, the Web and the Grid are continually evolving, making this task not only challenging but also requiring constant adaptation to new standards and tools. GridPort evolved out of the need to simplify the integration of these services and technologies for portal developers. As additional application portals for the NPACI user community were constructed, the need for an architecture that would provide a single, uniform API to these technologies and an environment that would support multiple application portals emerged. GridPort was designed to provide a common shared instance of a toolkit and its associated services and data (such as user account information, session data, and other information), and to act as a mediator between client requests and Grid services. 28.2.1 GridPort architecture The GridPort design is based on a multilayered architecture. On top there exists a client layer (e.g. Web browsers) and beneath it is a portal layer (the actual portals that format the content for the client). On the bottom is a backend services layer that connects to distributed resources via Grid technologies such as Globus. GridPort is a portal services layer that mediates between the backend and the portal layers (see Figure 28.1). GridPort modularizes each of the steps required to translate the portal requests into Grid service function calls, for example, a GRAM submission. In the context of the architecture of Foster et al. [10] that describes the ‘Grid anatomy’, GridPort represents an API that supports applications (portals) and interfaces to the Collective and Resources layers. In a sense, a producer/consumer model exists between each layer. Each layer represents a logical part of the system in which data and service requests flow back and forth and addresses some specific aspect or function of the GridPort portal system. For example, GridPort consumes Grid services from a variety of providers (e.g. via the Globus/GRAM Gatekeeper); as a service provider, GridPort has multiple clients such as the HotPage BUILDING GRID COMPUTING PORTALS: THE NPACI GRID PORTAL TOOLKIT 681 Web browsers Personal Data Assistants (PDAs) NPACI BBE application portal www.sdsc.edu/BBE/ NPACI HotPage application portal hotpage.npacl.edu USC LAPK application portal gndport.npacl.edu/LAPK/ NBCR GAMESS application portal gridport.npacl.edu/GAMESS/ NPACL Telescience application portal gridport.npacl.edu/telescience/ PORTALS.NPACL.EDU Interactive services Informational services Authentication SDSC cert repository Portal user services File/data management Job management Information services CRON SSH NPACI Alllance PSC NASA/IPG Clusters Workstations Archlval CACL account -cration Myproxy GSI / interative GSI-FTP future SRB storage resources broker Globus GRAM GIS GBS GRIS OPACI Portals Grid services Portal servicesChents Computer resources webserver filespace Portal user file space Local host up download Information cache HTTPS HTTPS SSL Figure 28.1 The diagram shows the layers used in the GridPort multilayered architecture. Each layer represents a logical part of the portal in which data and service requests flow back and forth. On top is the client layer and beneath it is a portal layer. On the bottom is the backend services layer that connects to distributed resources via Grid technologies. GridPort is the portal services layer that mediates between the backend and portal layers. GridPort modularizes each of the steps required to translate the portal requests into Grid service function calls, for example, a GRAM submission. and other application portals that use the same instance of GridPort to submit a job. We describe each of the layers and their functions below. Client layer: The client layer represents the consumers of Grid computing portals, typ- ically Web browsers, Personal Digital Assistants (PDAs), or even applications capable of pulling data from a Web server. Typically, clients interact with the portal via HTML form elements and use HTTPS to submit requests. Owing to limitations in client-level security solutions, application portals running at different institutions other than the Grid- Port instance are not currently supported. This limitation can now be addressed, however, owing to the advent of Web services that are capable of proxy delegation and forwarding. The issue is discussed in further detail in Section 28.5. Portals layer: The portals layer consists of the portal-specific code itself. Application portals run on standard Web servers and process the client requests and the responses to those requests. One instance of GridPort can support multiple concurrent application portals, but they must exist on the same Web server system in which they share the same instance of the GridPort libraries. This allows the application portals to share portal- related user and account data and thereby makes possible a single-login environment. These portals can also share libraries, file space, and other services. Application portals based on GridPort are discussed in more detail in Section 28.3. Portal services layer: GridPort and other portal toolkits or libraries reside at the por- tal services layer. GridPort performs common services for application portals including 682 MARY P. THOMAS AND JOHN R. BOISSEAU management of session state, portal accounts, and file collections and monitoring of Grid information services (GIS) Globus Metacomputing Directory Service (MDS). GridPort provides portals with tools to implement both informational and interactive services as described in Section 28.1. Grid services (technologies) layer: The Grid services layer consists of those software components and services that are needed to handle requests being submitted by software to the portal services layer. Wherever possible, GridPort employs simple, reusable mid- dleware technologies, such as Globus/GRAM Gatekeeper, used to run interactive jobs and tasks on remote resources [9]; Globus GSI and MyProxy, used for security and authen- tication [11]; Globus GridFTP and the SDSC Storage Resource Broker (SRB), used for distributed file collection and management [12]; and GIS based primarily on proprietary GridPort information provider scripts and the Globus MDS 2.1 – Grid Resource Infor- mation System (GRIS). Resources running any of the above can be added to the set of Grid resources supported by GridPort by incorporating the data about the system into GridPort’s configuration files. Resources layer: GridPort-hosted portals can be connected to any system defined in the local configuration files, but interactive capabilities are only provided for GSI-enabled systems. For example, on the PACI HotPage [13], the following computational systems are supported: multiple IBM SPs and SGI Origins, a Compaq ES-45 cluster, an IBM Regatta cluster, a Sun HPC10000, a Cray T3E, a Cray SV1, an HP V2500, an Intel Linux Cluster, and a Condor Flock. Additionally, via the GSI infrastructure it is possible to access file archival systems running software compatible with the Public Key Infrastruc- ture/Grid Security Infrastructure (PKI/GSI) certificate system, such as GridFTP or SRB. GridPort supports resources located across organizational and geographical locations, such as NASA/IPG, NPACI, and the Alliance. GridPort is available for download from the project Website [8]. The latest version of GridPort has been rewritten as a set of Perl packages to improve modularity and is based on a model similar to the Globus Commodity Grid project that also provides CoG Kits in Java, Python, and CORBA [14, 15]. 28.2.2 GridPort capabilities GridPort provides the following capabilities for portals. Portal accounts: All portal users must have a portal account and a valid PKI/GSI certifi- cate. (Note that these accounts are not the same as the individual accounts a user needs on the resources.) The portal manages the user’s account and keeps track of sessions, user preferences, and portal file space. Authentication: Users may authenticate GridPort portals using either of two mechanisms: by authenticating against certificate data stored in the GridPort repository or by using a MyProxy server. GridPort portals can accept certificates from several sites; for example, BUILDING GRID COMPUTING PORTALS: THE NPACI GRID PORTAL TOOLKIT 683 NPACI GridPort portals accept certificates from the Alliance, NASA/IPG, Cactus, and Globus as well as NPACI. Once a user is logged in to a GridPort portal and has been authenticated, the user has access to any other GridPort-hosted portal that is part of the single-login environment. Thus, a portal user can use any Grid resource with the same permissions and privileges as if he had logged into each directly, but now must only authenticate through the portal. Jobs and command execution: Remote tasks are executed via the Globus/GRAM Gate- keeper, including compiling and running programs, performing process and job submission and deletion, and viewing job status and history. Additionally, users may execute simple Unix-type commands such as mkdir, ls, rmdir, cd, and pwd. Data, file, and collection management: GridPort provides file and directory access to compute and archival resources and to portal file space. Using GSI-FTP (file transfer protocol) and SRB commands, GridPort enables file transfer between the local workstation and the remote Grid resources as well as file transfers between remote resources. GridPort also supports file and directory access to a user’s file space on the Grid resource. Information services: GridPort provides a set of information services that includes the status of all systems, node-level information, batch queue load, and batch queue job summary data. Data is acquired via the MDS 2.0 GIIS/GRIS or via custom information scripts for those systems without MDS 2.0 installed. Portals can use the GridPort GIS to gather information about resources on the Grid for display to the users (as in the HotPage portal) or use the data to influence decisions about jobs that the portal will execute. 28.2.3 GridPort security Secure access at all layers is essential and is one of the more complex issues to address. All connections require secure paths (SSL, HTTPS) between all layers and systems involved, including connections between the client’s local host and the Web server and between the Web server and the Grid resources that GridPort is accessing. Security between the client and the Web server is handled via SSL using an RC4-40 128-bit key and all connections to backend resources are SSL-encrypted and use GSI-enabled software wherever required. GridPort does not use an authorization service such as Akenti [16], but there are plans to integrate such services in the future versions. The portal account creation process requires the user to supply the portal with a digital GSI certificate from a known Certificate Authority (CA). Once the user has presented this credential, the user will be allowed to use the portal with the digital identity contained within the certificate. Logging into the portal is based on the Globus model and can be accomplished in one of two ways. The Web server may obtain a user ID and a passphrase and attempt to create a proxy certificate using globus-proxy-init based on certificate data stored in a local repository. Alternatively, the proxy may be generated from a proxy retrieved on behalf of the user from a MyProxy server. 684 MARY P. THOMAS AND JOHN R. BOISSEAU If the proxy-init is successful, session state is maintained between the client and the Web server with a session cookie that is associated with a session file. Access restrictions for cookie retrieval are set to be readable by any portal hosted on the same domain. As a result, the user is now successfully authenticated for any portal that is hosted using the same domain, allowing GridPort to support a single login environment. Session files and sensitive data including user proxies are stored in a restricted access repository on the Web server. The repository directory structure is located outside Web server file space and has user and group permissions set such that no user except the Web server daemon may access these files and directories. Furthermore, none of the files in these directories are allowed to be executable, and the Web server daemon may not access files outside these directories. The session file also contains a time stamp that GridPort uses to expire user login sessions that have been inactive for a set period of time. Grid task execution is accomplished using the GSI model: when a portal uses GridPort to make a request on behalf of the user, GridPort presents the user’s credentials to the Grid resource, which decides, on the basis of the local security model, whether the request will be honored or denied. Thus, the portal acts as a proxy for executing requests on behalf of the user (on resources that the user is authorized to access) on the basis of the credentials presented by the user who created the portal account. Therefore, portal users have the same level of access to a particular resource through the portal as they would if they logged into the resource directly. 28.3 GRIDPORT PORTALS As the number of portals using GridPort increased, the complexity of supporting them also increased. The redesign of GridPort as a shared set of components supporting centralized services (e.g. common portal accounts and common file space) benefited both developers and users: it became much simpler for developers to support multiple application portals because code, files, and user accounts were shared across all portals, while users only had to sign in once to a single account in order to gain access to all portals. Figure 28.2 depicts the GridPort approach used for implementing portals. The diagram shows the relationships between multiple application portals residing on the same machine and accessing the same instance of GridPort. In this example, all the application portals are hosted on the *.npaci.edu domain. The Web servers for these URLs and the application portal software reside on the same physical machine and have access to the shared GridPort file space. Each portal also has its own file space containing specialized scripts and data. The portal developer incorporates the GridPort libraries directly into the portal code, making subroutine calls to GridPort software in order to access the functionality that GridPort provides. The application portal software is responsible for handling the HTTP/CGI (Common Gateway Interface) request, parsing the data, formatting the request, and invoking GridPort when appropriate. Furthermore, since GridPort is an open source, the application portal developers at a given domain may modify GridPort to suit their needs. GridPort intentionally decouples handling HTTP/CGI data so that clients can make GridPort requests using other languages (e.g. Java, PHP, etc.). [...]... requirements cannot be satisfied until some basic Grid infrastructure issues have been resolved The usefulness of Grid portals and applications, and therefore BUILDING GRID COMPUTING PORTALS: THE NPACI GRID PORTAL TOOLKIT 693 their rate of development and acceptance, will be limited until the following Grid tools, components, and capabilities are available: • Grid accounts and allocations: Accounts and access... applications and for workflow usage models Grid schedulers must account not only for computational resource loads but also for network performance and data transfer times • Advanced Grid Tools: To fully utilize the Grid, additional tools are needed for development and optimized performance of Grid applications This includes Grid- aware compilers for handling Grid binaries’, Grid I/O libraries, and parallel libraries... portals (user and application), Grid applications, legacy applications, problem solving environments, and shells [35] The initial redesign phase will focus on Grid portals and the Grid Web services needed to support them Subsequent efforts will further generalize GridPort for the development of Grid applications and other GCEs, after the Grid infrastructure needed to support Grid applications has matured... Symposium on High Performance Distributed Computing, August, 2000, Project Website last accessed on 7/1/02 at http://hotpage.npaci.edu 4 Novotny, J (2002) Grid portal development toolkit (GPDK) Concurrency and Computation: Practice and Experiencer, Special Edition on Grid Computing Environments, Spring 2002 (to be published) BUILDING GRID COMPUTING PORTALS: THE NPACI GRID PORTAL TOOLKIT 699 5 Bramley, R... new version of GridPort that will have a 694 MARY P THOMAS AND JOHN R BOISSEAU ‘components and tools’ approach to facilitate dynamic composition of portal tasks The scope of GridPort will be expanded to provide a toolkit not only for the development of portals but also for developing more general Grid applications and distributed Grid Web services ( Grid Web services’ are defined to be Grid services... Registration and management of the executable binaries for each Grid compute architecture is even more difficult and must be automated Avaki has accomplished much in this area, but it must become available for all Grids, not just Grids based on Avaki software • Grid schedulers: Effective utilization of Grid resources requires efficient Grid scheduling beyond advanced reservations Portals and applications... Weather Service) and estimate data transfer times [36]; and interoperate with Grid schedulers GridPort services can be local or remote Grid Web services will be used to provide many of these capabilities Portlets are included at this layer because they can deliver content to portals 695 BUILDING GRID COMPUTING PORTALS: THE NPACI GRID PORTAL TOOLKIT Clients Browsers PDA's Cell phones, pagers Shell, command... personalization File, collection and data management Centralized Grid accounts, anthorization, authentication Grid services Grid technologies GIS NWS Globus GT2.0 Condor gridFTP Grid Web services GIIS/GRIS GIS Jobs MPICH-G LSF SGE PBS Events Globus GT3.0 Brokers Schedulers File management SRB Messages Directory SRB collections Discovery: UDDI, OGSA Registry Grid resources Compute Network Collections Instrumentation... the GridPort GCE architecture, which is based on a multilayered approach, as in Figure 28.1 The architecture has been extended to include applications (which include portals) and Grid Web services Shaded boxes represent layers and types of services that will be implemented as part of the GridPort toolkit Grid services (technologies) layer: This layer represents the resource-level Grid However, Grid. .. UDDI as the service repository and discovery system GridPort Grid Web services system will interface with the OGSA services Although these services have the potential to enhance and simplify Grid computing capabilities, the Grid community will need to address basic research questions about the scalability of Web services, how well they interact on the Grid, and how to determine the logical order in which . general Grid applications that use the Grid resources and services. BUILDING GRID COMPUTING PORTALS: THE NPACI GRID PORTAL TOOLKIT 679 28.1.3 Grid portal. etc.). BUILDING GRID COMPUTING PORTALS: THE NPACI GRID PORTAL TOOLKIT 685 hotpage.npaci.edu gridport.npaci.edu/GAMESS gridort.npaci.edu/LAPK gridort.npaci.edu/Telescience