Meeting the Needs of Business

GRIA is the first Grid middleware designed using a service-oriented architecture to support business users of the Grid through service provision across organisational boundaries.

Grid Services are a specialised kind of Web Services that support long-lived, resource-intensive activities, which may require the combined resources of multiple Grid service providers, and may involve sharing of these resources between users from different organisations. Such activities are found in in business sectors such as engineering, finance, life sciences, media production and healthcare, and in academic research. They may involve resources of all kinds: data sources, storage, applications and processing.

In academic Grids, resource sharing is usually organised by service providers, who agree to share their resources to create a single 'resource pool' that can meet the needs of a common user community. However, this involves service providers and users signing up to a 'virtual organisation' with a common objective (that of the relevant user community), and agreeing unified policies for managing and granting user access to the shared resources. This arrangement is very expensive to establish and operate, does not meet the business needs of commercial service providers or consumers, and leaves no room for participants to compete openly on price or quality of service.

GRIA is designed to support the core requirements for business applications.

• Service providers should be able to operate independently of each other, and compete as necessary to provide services to paying customers.

• Customers should be able to control which services they consume, how much they are used, and by whom.

• Services should be subject to Service Level Agreements so providers know what service they have to provide, and customers know what service they will receive and at what price.

• Security should be up to commercial standards

• Service providers should be able operate within the terms of relevant application software licenses.

• Messages exchanged should conform to relevant standards.

• Operating costs should be minimised

To meet these goals, GRIA uses a fully decentralised management approach, with minimal dependency between sites. Each site offering GRIA services makes its own business decisions about which users to trust and on what terms, and is responsible for enforcing its own access policies and deciding which applications to support. Sites can interact with each other, but this is driven by their common consumers, and those consumers are responsible for managing the resulting dependencies. There are no global agreements to set up, and no virtual organisations need be established, though users can interact according to virtual organisation models if they want.

Managing Your Business Relationships

GRIA supports business relationship management through conventional business procurement models. When a consumer wants to buy services from a provider, they first have to open a trade account with the service provider. This trade account represents a trust relationship between a customer and service provider, based on the customer's willingness to pay for services provided. The two sides can constrain the level of trust by specifying a credit limit for each trade account, which represents the maximum amount of service the provider is willing to deliver before being paid, or the maximum amount of service the consumer is willing to pay for, whichever is the smaller.

The relationships between service providers and consumer organisations can be complex. A typical consumer organisation may have several relationships with each of several providers, each used by a different department or project, and each established and regulated by different authorised employees (e.g. project managers), as shown below.

Business Relationship Management

It is important to emphasise that the trade accounting service is a ledger, not a banking service. It records money that an organisation is owed or owes, not money which they actually have. It does not guarantee (the way a bank has to) that these records will be 100% complete and accurate, which is not feasible without reliable networks and roll-back facilities, as operated (for a fee) by clearing banks. A service provider cannot get money from the accounting service, or treat the balance of an account as cash that can be used to pay others, but can use the accounting service to generate invoices to send to customers. The customer may contest the details of such an invoice if there have been any operational or network errors, but GRIA can help resolve such errors because it signs and logs each message processed by its services. When the customer pays the bill, this should be reported to GRIA so it doesn't bill again for the same services.

Partnership.....But on Your Terms

GRIA allows service providers and customers to trade resources (applications, data, processing, storage) under the terms of bilateral Service Level Agreements (SLAs). An SLA describes quality of service (QoS) and other commitments by a service provider in exchange for financial commitments by a customer against an agreed schedule of prices and payments. GRIA allows service providers to advertise SLA templates that are proposed by customers during SLA negotiation.

SLA Management

Service providers deploy application services appropriate to their business operation. These services generate usage reports using their own QoS criteria which may be qualitative (e.g. error conditions) or quantitative (e.g. processing time, data transferred). GRIA uses these reports to monitor customer usage and the level of commitments from existing agreements compared with available capacity. GRIA can then automatically determine:

• whether to enter into a new SLA (with a given QoS) when requested by a customer;

• whether a requested service is covered by an existing SLA, and whether the service can be provided within the capacity of the provider;

• which SLA(s) should be breached when capacity is about to be exceeded, and how to reduce loads in the corresponding application service(s);

• when a consumer is exceeding the limits of an SLA, and how to prevent this by reducing service consumption in the corresponding application service(s); and

• what level and quality of service is actually delivered, and how much to bill for this.

To enter into a new SLA, a customer must be authorised to bill services provided under the new SLA to a GRIA charging account, and the account must have sufficient credit left to cover the scale of services that would be supplied under the SLA. This means the human manager of GRIA services can control how much service will be provided to which customers, but he only has to make one business decision: what credit limit to allow on the customer's trade account, if any. After that, everything is automated, which makes GRIA services very responsive to new user needs, yet inexpensive to operate for providers. This is critical in a business Grid where human resources can easily become the largest cost when running services - in GRIA these costs are minimised, so services can be profitable for providers while still being affordable for customers.

A Proven Approach to Security

The approach to security in GRIA is designed primarily to maintain the independence between sites whilst keeping operating costs down. GRIA 5 comes with standard Web Service security mechanisms to verify the identities (and roles) of users attempting to access services. Like most e-Commerce applications, but unlike some other Grids, GRIA does not give even authorised users direct access to run their own commands on computational nodes. Instead, users must request that the service run commands on their behalf, and by default the only commands supported are those defined by the service provider as application services.

This means GRIA service providers do not have to set up local accounts for each user (a significant operational cost in many academic Grids). It also reduces the amount of trust service providers must place in their users, enabling them to remain independent of each other even when interacting with other service providers on behalf of common users. Finally, it means service providers can ensure that applications used at their site are fully licensed, and avoid the risk of legal action by their own or their users' software suppliers.

GRIA 5 has dynamic policy management features to define and enforce policies for accessing service and consumer management functions, and for each individual data item and computation. This dynamic policy feature enables users to orchestrate interactions between services operated by totally independent providers, and to share results with other users as required. The GRIA 5 consumer management package also supports integration with 'home site' user authentication, and service policies can specify which site(s) are trusted to authenticate users against each individual policy clause. This makes it very easy to set up business relationships and start providing services to new customers within a few minutes.

Finally, by maintaining independence between service providers, GRIA allows them to remain responsible for their own security. Unlike many academic Grids, there are no single points of failure, and if one GRIA site suffers a security breach, the problem can be dealt with locally and other sites do not have to close down. GRIA's low-dependency approach thus ensures a high degree of intrusion tolerance, which is essential for business Grid service providers.

Industry Based Standardisation

Interoperability between Grid infrastructures provided by different vendors is an important requirement for both end-users and application developers. End-users want to be able to dynamically discover and bind to services provided by other organisations without having to be concerned with the underlying Grid technology. Application developers want to be able to provide problem solving environments at a level of abstraction that allows for interoperation between Grid technologies at the service interface without having to maintain complex adaptors. Interoperability is essential if Grid technology is to achieve dynamic and ubiquitous access to heterogeneous resources, as the Internet has enabled the Web. The Grid and Web Service communities are working towards this ambitious goal through the development of various specifications covering all aspects of service integration such as security, trust, state, notification, etc.

A description of how GRIA uses standards and specifications to provide key functionality is available in the "Relationship to Standards" section. The key Grid/Web Service standards and specifications used by GRIA are as follows.

• WS-I Basic Profile and WS-I Basic Security Profile, which describe profiles on industry Web Service specifications that promote interoperability.

• WS-Security, a set of SOAP extensions to provide message-level integrity, confidentiality and authentication.

• WS-Federation, which describes how to use WS-Trust, WS-Security and WS-Policy together to provide federation between security domains.

• WS-Addressing describes the encapsulation and use of a (possibly contextualised) Web Service address via End Point References (EPR)

• Web Service Resource Framework (WSRF), which describes a particular use of WS-Addressing to access resources via contextualised Web Services.

• WS-Notification, which defines a collection of interfaces for transmitting notification messages directly between a producer and a consumer using push- or pull-style transfer, plus a specification for distribution of these messages through a broker, and for defining topics that allow subscribers to select particular notifications of interest.

• SAML, an XML standard for exchanging authentication and authorization data between security domains.

Some of these standards are not yet fully mature, so GRIA uses as little of the less well established functionality as possible, and will increase its conformance as the standards become more mature.