No activación del régimen de responsabilidades

Dictamen de Liquidación Presupuestaria 2014

5. No activación del régimen de responsabilidades

Service Level Agreements provide a mechanism for formalising QoS requirements. They are formal statements for expressing expectations and obligations between parties. Within the Grid research community there have been many SLA specifications, each addressing a particular requirement such as task submission or resource management. Examples of such specifications include the Job Submission Description Language [67], the Web Service Level Agreement Specification [68] and the WSAgreement Specification [69]. There have also been other initiatives which never made it to formal specification, but define methods for expressing aspects of Grid usage. These include the Usage Record [70], the Grid Economic Services Architecture [71], Service Negotiation and Acquisition Protocol [72] and the e-Contracts [73] initiative.

2.3.1 Job Submission Description Language (JSDL)

The Job Submission Description Language (JSDL) [67] defines the application requirements needed in order to submit a Grid job. The elements which make up the schema are shown in Figure 3. It is defined with a Job Definition root element which comprises of a single mandatory element, the Job Description. This description holds information related to the Job such as its ID, the application and resource requirements, plus any data staging requirements. The vocabulary used within JDSL is influenced by a number of network batch schedulers and the DRMAA [74] standard. This allows it to provide job definitions for most local resource managers. JSDL does not provide job definitions to application services which have a web service interface. For this the authors admit that WS-Agreement is more appropriate. JSDL does not provide elements which can be used to record the provenance of the Job. Once the Job has been admitted to the execution host JSDL provides no elements which can be set dynamically. In a business environment this may itself be a requirement of the job. Examples include the verification of the current state of the job or the validation that the SLA completed with no violations. Other omissions include identification of the parties involved.

Figure 3 JSDL Pseudo Schema

2.3.2 Web Service Level Agreement (WSLA) Specification

The Web Service Level Agreement (WSLA) [68] specification defines a service level agreement language to support dynamic electronic services implementing QoS guarantees within a Web Services Framework [75]. The elements which make up the schema are shown in Figure 4. The language is XML based and able to describe heterogeneous objects relevant to an SLA implementation. An SLA agreement consists of a description of the parties involved; a service definition and obligation description. This describes qualitatively and quantitively, what is covered by the agreement. Action guarantees are included to express what actions should be performed should a pre- condition be met. This form of adaptive SLA management applies mainly to the SLA, rather than application management.

2.3.3 WS-Agreement

WS-Agreement [69] is a specification intended for the management of WSRF service environments using agreement negotiation. The negotiation is considered stateful and involves a series of automated message exchanges between agreement parties. An agreement Web service factory provides the negotiation interface and a WSRF service instance represents a signed service level agreement. The agreement has state and a lifecycle from creation to termination. The methods used in its implementation are open – allowing for domain specific elements to be added [76]. The elements which make up the schema are shown in Figure 5.

Figure 5 WS-Agreement Pseudo Schema

2.3.4 Usage Record (UR)

The Usage Record (UR) [77] is responsible for defining a common format for exchanging basic accounting and usage data within Grid systems. The elements which make up the schema are shown in Figure 6. The language is XML based providing usage information on elements such as CPU duration, wall duration, processor and node count.

Figure 6 UR Pseudo Schema

2.3.5 Grid Economic Services Architecture (GESA)

The Grid Economic Services Architecture (GESA) [78] is responsible for defining the GESA service specification for chargeable Grid Services and the Grid Payment System. GESA is not strictly an SLA, it allows service selection and usage based on economic [79] considerations and provides a payment system for Grid services. The architecture includes the use of the Record Usage Service (RUS) [80] and the Grid Payment System. By attaching economic and usage meta-data in the form of service data elements, and a number of service interface definitions, users are able to request Grid service pricing information prior to instantiation.

2.3.6 Service Negotiation and Acquisition Protocol (SNAP)

The Service Negotiation and Acquisition Protocol (SNAP) [72] provides a common protocol for negotiating for the right to consume a set of resources and the subsequent acquisition of the negotiated resources. SNAP provides a framework for three types of SLA: task (TSLA), resource (RSLA) and binding (BSLA). A TSLA is an agreement that specifies the desired performance for an application service. An RSLA specifies the right to use a specific Grid resource. A BSLA associates an RSLA with a TSLA and specifies how that RSLA be applied so that the TSLA can be fulfilled. Whilst SNAP manages the negotiation and acquisition of resources for task submission it does not address the issues of resource management once the SLA exists and the resources are in use.

2.3.7 e-Contracts in e-Commerce

E-contracts [73] governing transaction-based business-to-business (B2B) interactions support value-added service provision. Although this research does not originate from within the Grid community, parallels can be drawn in its goals. The contracts are subject to similar lifecycle procedures; drafting, negotiation and monitoring. The contract specification expresses similar concepts to WSLA and WS-Agreement, such as service obligations, prohibitions and permissions. One novelty of the approach is the expression of obligations, prohibitions and permissions by role. This allows contract negotiations at the organisational level rather than just at the user level. This approach can increase the size of the contract document if many roles have to be considered. An extension [81] to the research considers automatic mechanisms for dealing with e-contract non- compliance. Contracts are deemed to be within one of five levels of compliance whilst they are active. Level 1 reflects total compliance and level 5 total contract failure and the inability to apply corrective measures. This classification of contract violation is more fine-grained than the provisions made for violation in SLA specifications such as WSLA and WS-Agreement. The approach deals more with contracts at the organisation level where a single event or action cannot cause total failure. In WSLA and WS- Agreement, single events or actions can lead to the violation of an SLA, so it becomes meaningless to implement levels of compliance. The SLA used within this thesis is specified at the user level on a task basis, where single actions or events can cause SLA violation, therefore such an approach is not considered.

In document ASAMBLEA LEGISLATIVA DE LA REPÚBLICA DE COSTA RICA COMISIÓN PERMANENTE ESPECIAL PARA EL CONTROL DEL INGRESO Y GASTO PÚBLICOS (página 29-35)