GridWay implements several state-of-the-art Grid-aware scheduling policies, comprising job prioritization policies (fixed priority, urgency, share, deadline and waiting-time) and resource prioritization policies (fixed priority, usage, failure and rank).

These policies are combined with:

GridWay interfaces infrastructures with different middleware stacks. With GridWay, users can access heterogeneous resources in a transparent way. For example, it can access resources configured with both GRAM pre web services and GRAM web services. It also permits the use of different grids with different software stacks, for example, Teragrid with Globus and EGEE with gLite.

GridWay supports multiple-user operation mode, and does not require additional middleware installation (apart from standard Globus services). Globus installation is not required in each end-user system.

GridWay allows different Grid deployment strategies, like Enterprise Grids, Partner Grids or Utility Grids.

GridWay executes different Grid application profiles:

GridWay is able to detect several problems that can occur when executing a remote job. It also implements mechanisms that make the execution more reliable. It can detect a remote system crash, a job failure (via the job exit code) or even a network disconnection (using the polling mechanism) and migrate the problematic job to another resource.

GridWay also performs periodic saves of its state in order to recover from local failure.

GridWay provides detailed statistics of Grid usage. In this way, the Grid administrator can properly plan usage policies and forecast workload. In addition, these statistics can be used by the scheduler to predict (per user) Grid resource response time.

GridWay is an open-source project, flexible and completely based on standards to leverage its usability and interoperability. For example, users can describe their jobs using JSDL. Similarly, programmers can build grid enabled applications using the DRMAA standard.

GridWay provides end-users with a familiar environment similar to that found on classical LRM systems. So GridWay CLI eases the adoption of Grid technologies.

GridWay 5.2.1 can be easily integrated with all the major Grid infrastructures. Its functionality has been extended to operate different Grid deployments, which includes support for different execution/transfer schemes, information models and service configurations.

Previous GridWay releases do not handle MAD crashes. GridWay 5.2.1 will reload a MAD process whenever a MAD is killed or crashed.

The dynamic information of a host gathered from the Grid Information server can be mixed with custom variables defined by the GridWay administrator. This functionality is very useful when you need to extend the information scheme but have no access to the Grid server. For example, you can use this new feature to add software or license attributes to grid resources that can subsequently be used for resource requirement expressions.

Middleware Access Drivers need some environment variables to work properly. Usually, sudo must be configured to preserve these variables (e.g. GLOBUS_LOCATION or GW_LOCATION). GridWay 5.2.1 has a new configuration interface to ease this configuration. In this way, global (and per user) environment variables can be defined for MAD execution. This new feature allows GridWay to work with delegated credentials when configured with a GRAM interface.

A GridFTP server, different from the GRAM server, can be defined for file staging. The storage server must be defined (SE_HOSTNAME, attribute) for those resources operated on in this way. This can be done either by modifying the IM's MAD or using the new static-dynamic information model.

Now job templates can be also defined using the OGF standard JSDL HPC profile.