Science Gateway: Integrating Research Tools

• Science Gateways are community-developed platforms that provide tailored tools, workflows, and access to advanced cyberinfrastructure for specific research domains.
• They streamline the use of heterogeneous computing resources by abstracting complex infrastructures into user-friendly, web-based interfaces.
• Science gateways support collaborative research by integrating simulations, data analysis, secure identity management, and scalable workflow execution.

A science gateway is a community-developed set of tools, applications, and data integrated via a portal or a suite of applications, usually in a graphical user interface, further customized to meet the needs of a specific community. In contemporary cyberinfrastructure practice, science gateways are user-friendly, community-oriented, often web-based platforms that give research communities access to data, tools, workflows, and computing resources; they sit on top of advanced cyberinfrastructure such as HPC, cloud, storage, and identity systems and translate that complexity into something particular scientific communities can actually use in everyday practice (Manset et al., 2014, Pierce et al., 2022, Parsons, 24 Oct 2025).

1. Conceptual scope and evolution

Science gateways emerged as a response to the heterogeneity of distributed computing infrastructures, including Grids, Clouds, supercomputers, and clusters. In this literature, a portal is a web-based entry point, whereas a gateway is a more general architectural notion: a layer that offers services, workflows, and tools to a community, usually via a portal but also via APIs, and mediates between users and one or more DCIs. The consequence is that science gateways are not merely websites placed in front of batch systems; they are distributed software systems with non-trivial architecture and quality-of-service requirements (Manset et al., 2014).

The early TeraGrid/XSEDE model already established several enduring properties. A science gateway presents a domain-specific, browser-based UI tailored to a scientific community, translates user actions into jobs on remote clusters and supercomputers, hides grid details such as certificates, GRAM, and GridFTP behind higher-level abstractions, manages credential use and accounting consistent with infrastructure policies, and provides mechanisms for viewing, sharing, and reusing results. In that sense, a gateway lets astronomers, chemists, or materials scientists interact with “simulations,” “stars,” or “nanocrystals,” rather than with schedulers and middleware (Woitaszek et al., 2010).

Subsequent work broadened the concept from a thin access layer to a socio-technical platform. Gateways are now described not only as interfaces to infrastructure but also as collaboration hubs, institutional commitments, and living software projects that must remain technically robust, community-aligned, and sustainable over time. This suggests that the defining feature of a science gateway is mediation: between communities and computation, between domain practice and infrastructure, and between short-term project delivery and long-term service operation (Pierce et al., 2022, Parsons, 24 Oct 2025).

2. Architectural patterns

Science gateway architectures vary, but several recurrent patterns appear. One widely used pattern is the workflow-oriented stack built on WS-PGRADE, gUSE, and DCI-Bridge. In that stack, WS-PGRADE provides the science workflow management and portal front-end, gUSE provides the middleware layer for integrating heterogeneous DCIs, and DCI-Bridge acts as the unified back-end connector. The workflow model is explicitly layered as graph, workflow, and application/template, allowing reusable configured workflows to be published in repositories for end users (Gordienko et al., 2014).

Another pattern couples a portal framework with workflow and interactive environments. In the Cherenkov Telescope Array workspace, a Liferay-based portal hosts WS-PGRADE/gUSE portlets for workflow management and an ACID web-desktop environment for interactive use of graphical and command-line tools. The same workspace is coupled to an authentication and authorization infrastructure based on Shibboleth and Grouper, illustrating a gateway design in which workflow execution, interactive analysis, and federated identity are integrated within one portal fabric (Costa et al., 2016).

A lighter architectural pattern is exemplified by AMP, where the web-based user interface is a traditional standalone database-backed web application using Django, while a separate GridAMP workflow daemon runs on a more restricted server and acts as the grid client. The portal and daemon communicate only through the shared database. This separates public web interaction from privileged grid orchestration and makes the data model the asynchronous communication bus between front end and back end (Woitaszek et al., 2010).

More recent gateway platforms adopt a multi-tenant platform-as-a-service model. In Apache Airavata and SciGaP deployments, multiple gateway front-ends are tenants connected to a consolidated middleware that manages workflow execution, data movement, security, and metadata. In parallel, HPC centers have begun exposing gateway-facing REST layers: FirecREST places an API gateway in front of compute, storage, utilities, tasks, delegation, and status microservices so that web applications can interact with Cray XC systems through HTTPS, OpenAPI-described endpoints, and token-based authorization rather than through ad hoc SSH logic (Wannipurage et al., 2021, Cruz et al., 2019).

3. Workflows, data movement, and heterogeneous execution

Scientific workflows are central to the gateway model. In the WS-PGRADE/gUSE tradition, workflows are drawn as graphs of jobs with input/output ports and directed links representing data dependencies. They are then bound to concrete executables, scripts, arguments, and resource requirements. This supports submission, monitoring, and result retrieval through a browser, while making tools such as LAMMPS, R, Pizza.py, AtomEye, debyer, and FFMPEG reusable bricks in larger computational pipelines (Gordienko et al., 2014).

In practice, gateways encapsulate complete scientific pipelines rather than isolated codes. Molecular-dynamics gateways support build-and-relax, loading, defect tracking, diffraction analysis, plotting, and movie generation inside one workflow. CTA workflows combine event selection, binning, livetime computation, likelihood fitting, and result staging to ownCloud. EXTraS exposes transient-source analysis by letting users configure instruments, energy bands, and time-interval logic for XMM-Newton observations, with one OBSID mapped to one cloud job. This suggests that gateways operationalize domain workflows as shareable and repeatable computational objects (Gordienko et al., 2014, Costa et al., 2016, D'Agostino et al., 2019).

Heterogeneous execution is equally characteristic. Gateways routinely target clusters, service grids, desktop grids, clouds, and national cyberinfrastructure. In the IMP Science Gateway, DCI-Bridge supports PBS, LSF, ARC, gLite, GT2/GT4/GT5, UNICORE, BOINC, CloudBroker Platform, and Google App Engine. In SGCI’s framing, modern gateways integrate with HPC clusters, clouds, storage systems, identity management, and workflow systems, often through national CI such as XSEDE and ACCESS (Gordienko et al., 2014, Pierce et al., 2022).

Data movement has become a first-class architectural concern. The canonical pattern in which every transfer passes through a gateway web server is now treated as a scalability bottleneck. Airavata MFT separates control and data planes: centralized services accept, monitor, and retry transfer requests, while distributed agents move data directly between endpoints. It supports agent-to-agent and agent-to-storage modes, along with SCP, SFTP, FTP, HTTP, TUS, Amazon S3, Google Drive, Azure Blobs, Box, and Dropbox. FirecREST reaches a similar conclusion from the HPC-center side by making job submission, filesystem operations, external transfers, and asynchronous task tracking explicit REST resources (Wannipurage et al., 2021, Cruz et al., 2019).

4. Identity, authorization, and confinement

Identity and authorization are structurally important because gateways must expose institutional resources to distributed communities while preserving accountability. One established pattern is federated identity: the CTA gateway uses eduGAIN, a Shibboleth Discovery Service, a CTA Identity Provider, and Grouper-managed attributes such as isMemberOf and eduPersonEntitlement, which are mapped to Liferay roles like Advanced WF User and WF User. This provides web-based access control without requiring local accounts for every user (Costa et al., 2016).

A more general service-oriented security layer is provided by Custos. Custos is designed as a multi-tenanted service for federated authentication, identity management, group and authorization management, and resource credential management. The system adds hierarchical tenant management for hosted gateway platforms and service accounts for non-browser applications and agent applications that act on behalf of users on edge resources. In deployment scenarios such as SciGaP, Galaxy, HTRC, and Airavata MFT, Custos externalizes security functions that gateways previously reimplemented locally (Ranawaka et al., 2021).

Gateway-facing HPC APIs adopt similar web-native security models. FirecREST uses Keycloak and OIDC so that clients acquire OAuth2/OIDC tokens and present them to the API gateway. A delegation microservice then generates short-lived OpenSSH user certificates, which internal microservices use to access Cray XC systems on behalf of the user. EXTraS uses robot certificates and per-user sub-proxies so that portal users can exploit EGI Federated Cloud resources without handling personal X.509 credentials directly (Cruz et al., 2019, D'Agostino et al., 2019).

Application-level confinement has recently become part of the science-gateway security discussion. Landlock allows a running process to give up future access to filesystem paths and TCP resources. For MPI applications used through science gateways, the recommended sequence is to allow network access while starting up MPI and then take it away prior to the reading of user-supplied parameter files. The paper testing this approach on the Einstein Toolkit, Octo-Tiger, and FUKA concludes that the present version of Landlock is suitable for safely sandboxing a Linux application, provided that UDP is controlled by other means (Brandt et al., 23 Sep 2025).

5. User experience, sustainability, and support ecosystems

Recent work argues that gateway sustainability cannot be understood purely as funding continuity or code maintenance. Science gateways are described as socio-technical platforms whose long-term viability depends on how user experience is woven into infrastructure decisions, staffing, timelines, and community engagement. From this perspective, UX is the lived experience of researchers trying to integrate a gateway into scientific practice over time, and it is shaped as much by legacy authentication, support models, and organizational constraints as by interface polish (Parsons, 24 Oct 2025).

An influential synthesis identifies three recurring UX orientations. In an ad hoc orientation, UX attention is informal, episodic, and reactive; issues are addressed when users complain, systematic feedback processes are absent, and UX debt accumulates. In a project-based orientation, teams budget time for usability studies, surveys, or workshops, but these activities are time-bounded and usually late-stage. In a strategic orientation, UX is treated as a cross-cutting, ongoing concern: teams use early-stage sketching and prototyping, maintain regular feedback loops, distribute UX responsibilities across roles, and integrate UX findings into governance and technical decisions. These are explicitly described not as a maturity ladder but as interpretive lenses for understanding how teams position UX relative to their work (Parsons, 24 Oct 2025).

The institutional ecosystem around gateways has also matured. The Science Gateways Community Institute provides sustainability training through Focus Week and Jumpstart, usability and user experience consulting, a community catalog of gateways and gateway software, workforce development through coding institutes, internships, and hackathons, and in-depth technical support through Embedded Technical Support. From 2016 onward, ETS involved 20 research software engineers as consultants and completed 59 client consultations. Client surveys reported a mean satisfaction score of $5.62$ on a 1–6 scale, a perceived benefit mean of $5.54$, and an average speedup of $6.4$ in the clients’ work. This operational model treats sustainability, UX, training, and embedded RSE effort as interlocking gateway infrastructure rather than separate concerns (Pierce et al., 2022).

6. Domain-specific realizations and broader usages

Science gateways are strongly domain-shaped. In materials science, the IMP Science Gateway Portal embodies the “science gateway” ideology as a user-friendly intuitive interface between scientists and software components plus various distributed computing infrastructures, and it is explicitly presented as a hub of virtual experimental labs. Its workflows support boron nitride nanotube thermal stability, graphene nanoindentation, and metal nanocrystal defect relaxation, while mapping software compositions such as LAMMPS + AtomEye or LAMMPS + debyer + R to virtual counterparts of laboratory methods like TEM, AFM, X-ray diffraction, and neutron diffraction (Gordienko et al., 2014).

In astronomy and astrophysics, gateways often combine workflow automation with domain archives or interactive analysis. The CTA workspace joins a workflow management system and an interactive virtual desktop environment under a common AAI. EXTraS combines a web portal, an archive of derived temporal products from XMM-Newton, visualization services, and EGI FedCloud execution; in a related educational deployment, the EXTraS science gateway was used in workshops where high-school students validated transient candidates and identified a peculiar flaring X-ray source in the globular cluster NGC 6540 (Costa et al., 2016, D'Agostino et al., 2019).

In atomic and molecular physics, AMPGateway uses Apache Airavata and SciGaP to expose BSR, CCC, UKRMol+, tRecX, XChem, and other codes through browser-based submission and monitoring interfaces. In astroparticle physics, LAGO integrates a standards-based data repository, persistent identifiers, and a Science Gateway that provides access to different clusters, Grid, and Cloud infrastructures worldwide. In undergraduate STEM education, QUBES reframes the idea as a “science education gateway,” with over 20,000 registered users, over 450 group workspaces, over 1,200 project areas, and over 2,100 OER resources; here the gateway model supports OER publication, professional learning, partner support, and customizable workspaces rather than only HPC workflows (Schneider et al., 2020, Asorey et al., 2016, Donovan et al., 2023).

A separate public-facing usage of the term appears at CERN. CERN’s Science Gateway is a flagship education and outreach centre, a permanent, free-admission science hub on CERN’s campus that opened to the public in October 2023 and had already welcomed over 500,000 visitors by mid-2025, with $N = 400\,838$ visitors recorded between 1 June 2024 and 31 May 2025 alone. This usage differs from the cyberinfrastructure sense: it denotes an immersive exhibition and educational complex rather than a computational gateway. A plausible implication is that “science gateway” now spans both mediated access to advanced research infrastructure and mediated access to scientific knowledge for public audiences (Cifuentes et al., 30 Sep 2025).