Home | About

• Home
• Technical Solutions
• Technical Publications
• Grid Business
• Announcements
• Grid Middleware
• Existing Grids
• Grid Links

GRIA is a Grid middleware which enables use of the Grid in a secure, interoperable and flexible manner.

GRIA makes use of business models, processes and semantics to allow resource owners and users to discover each other and negotiate terms for access to high-value resources.

GRIA implements an overall business process to find, procure and utilise resources capable of carrying out high-value, expert-assisted computations.

By focusing on business processes and the associated semantics, GRIA enables users to provision for their computational needs more cost effectively, and develop new business models for some of their services.

Services from different providers can be combined together to create applications using a simple and easy-to-use API.

GRIA was initially developed within the EC IST GRIA project, which ended in 2004. GRIA continues to be enhanced to meet the needs of industry through developments in the EC IST SIMDAT and NextGRID projects. GRIA 4.0 has also been used by Open Middleware Infrastructure Institute as the basis for their middleware, and some components are still common between the two. The main differences between the OMII and GRIA middleware is that while OMII focuses on supporting e-Science users, GRIA focuses on the needs of industry and places greater emphasis on providing managed and secure processes for managing resources and services.

GRIA is available as open source software at no cost. To access the software, the prospective user only needs to register and accept the terms and conditions when downloading the software packages.

For more information regarding the licence please check the GRIA web site www.gria.org .

Development of GRIA 6 is expected to begin before the end of 2006, but the schedule for releases is yet to be defined. GRIA 6 will raise the bar again for interoperability by making use of standards, and will incorporate more powerful models of service orchestration (workflow) and management, making it easier to flexibly deploy and configure a wide range of services to meet different business requirements.

PBAC 2 is a dynamic access control mechanism for web services. Web services create resources and allow users to perform operations with them. When a user tries to access a resource by invoking an operation on a web service, the PBAC system checks that the user is authorised to perform the requested operation on that resource.

GRIA Service Provider Management: The service provider management package allows a service provider to support service level agreements and if necessary bill for service usage, via a simple management protocol that can be used with GRIA basic application services and with other (non-GRIA) application services, if required.

It consists of:

• A Trade Account Service (see core functionalities)
• An SLA Management Service

These provide the service manager with the ability to define their available resources (e.g. CPUs, applications, etc), assign portions of their resources to customers by the way of service level agreements (SLAs), and bill for resource usage based on the pricing terms in these agreements.

Data management is provided by the following services:

• Data Service (Basic Application Services): This allows remote users to upload and download data files to the service provider, and to transfer data between Data Services hosted by different service providers. The Data Service also supports management of access rights (for read or read-write access) granted to other users or service providers.
• GRIA OGSA-DAI Service: The GRIA OGSA-DAI service package allows clients using the OGSA-DAI libraries access to databases through a GRIA service. The OGSA-DAI service can be deployed on its own to provide unmanaged access to databases, or it can be used with the GRIA service provider management package to take advantage of its billing and service level agreement functionality.

User integration is provided by the following services:

• GRIA Client: The GRIA client allows usage of GRIA services, such as data storage, batch processing and database systems. It also allows usage of the GRIA management services, which are needed so that use of the other services can be recorded and billed.
• There are two ways to use GRIA services:
  • The default GRIA client provides a Swing-based graphical interface which lets you manage accounts and service level agreements, run jobs and store data. The client supports plug-ins allowing support for new types of service to be added without recompiling the client.
  • GRIA services can also be used directly from your own applications, by using the GRIA client library. This provides a set of low-level Java objects which provide access to the remote services' operations and can be used by non-graphical applications (batch processing), or by applications where you wish to replace the standard GRIA interface components with your own. The client library also contains the default Swing components, which can be embedded into your application directly.
• GRIA Client Management: Each GRIA trade account or SLA represents a business relationship between a client organisation and a service provider. The service provider records usage of their services using these resources, and the client organisation uses them to find out what they owe or have used. Therefore, each trade account or SLA is accessed by both parties. Typically, a project manager in a client organisation needs to control access by many groups of users to many of these remote management resources. This can be done manually (by updating the access control rules on the remote resources), but with large numbers of management resources and users this becomes difficult.
• The client management package contains the private account service, which can be deployed within a client organisation to manage access centrally.
• Job Service (Basic Application Services): This allows remote users to start, monitor or kill computational jobs, executed by the service provider. The Job Service will fetch input from and write input to a local Data Service. The Job Service can be configured to support multiple applications, which are chosen by the service provider.

• Workflow:
  • GRIA Workflow Plugins for Taverna (for composing workflows of GRIA Jobs and data transfers): GRIA Workflow Plugins are components that extend the Taverna workbench and Freefluo workflow enactment engine. They enable GRIA job and data transfer operations to be composed by workflows using the Taverna workbench, and enable such workflows to be executed by the Freefluo workflow enactment engine.
  • GRIA Workflow Application (for deploying Taverna workflows as GRIA applications): The GRIA Workflow Application software includes tools for deploying and running Taverna workflows as GRIA applications. A command line deployment tool generates GRIA application wrapper scripts and other requisite files from a Taverna workflow. Running the deployment tool generates a new application that can be deployed to the GRIA Job service in the usual way using the Job Service Administration web pages. For convenience in the documentation, we refer to GRIA applications that have been created from workflows as workflow applications. Also, a job created from a workflow application is referred to as a workflow job.
• Brokering: Supported by the API, i.e. it is possible for someone to create a Broker but it is not provided out of the box.
• Accounting: Trade Account Service: This supports the creation and management of trade accounts, each representing a trust relationship between the service provider and a customer (the account's budget holder), who is responsible for all service access on their account. The budget holder can then allow others to access services, and can monitor usage on the account. Services that need to bill for their usage do so by recording charges at the customer's trade account.
• Steering: GRIA provides a workflow service that allows end-users to create workflows to be executed. These workflows are exposed as single resources to the users but may incorporate usage of many different resources. GRIA also allows users to create their own applications that may incorporate decisions of any kind, like choosing the best available resources during execution.
• Interactive access: GRIA provides an API for access to all resources and thus enables users to interact to all available resources.
• Addressing (WS-Adressing compliant?) GRIA is WS-addressing compliant.
• Transactions: GRIA provides an API for access to all resources and thus enables users to create transaction scripts depending on the outcome of each step of the process.
• WS-RF compliant? It is compliant in some cases but not 100%. Some work is done on this but it will take some time depending on the maturity of the standards.