About
The enormous research, interest and need around SOA (Service Oriented Architecture) are driving the creation of new solutions where general public, academia and businesses can benefit of new services.
Grid utility computing will be a key enabling technology for such a vision. This implies that Grid needs to embrace, along the academic research, the commercial area as well. Originally Grid was born as a mean to share resources among academic partners, based on trustiness, common vision etc. In this case, the “best effort” model on which the Grid relied was enough.
However, business grids will guarantee better services, not only in term of QoS, but also as accountability and security.
Objectives
Enable applications on the Grid. Business Grids need to run applications. However, there are cases with particular requirements, such as:
- Application is restricted to run only on a particular OS (e.g. windows);
- Application code is closed, which means not accessible for reading and modifying;
- Application needs to enforce privacy and data security control;
For business Grids to be competitive, the limits above mentioned need to be overcame. The more applications are enabled the larger is the set of users capable of using the infrastructure.
Enable users to use the Grid. In order for users to be able to access the Grid, accounting mechanisms, in terms of logging, authorization, billing and data protection, need to be in place.
Offer chargeable services with guarantied QoS. Business Grids should offer services according to some particular pricing model. Users have to be guaranteed to get what they paid for, while Grid providers should be guaranteed that users make use of the services bought and no harm is caused to the infrastructure as well as to processes of other users. Business contracts, showing the responsibilities of the parties involved, have to be established.
Overview
Below it is depicted an overview of the architecture, showing the components addressing the objectives above mentioned. The customer should gain access to the infrastructure through the SLA engine that creates the necessary SLA by getting low level accounting information. Once the SLA is created, the service is setup and the customer can use the infrastructure. The SLA engine communicates with the QoS engine in order to enforce the SLAs created.