Glossary. Whitepaper. July 20, 2010

Transcription

1 Glossary Whitepaper July 20, 2010 The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/ ) under grant agreement n

2 Contributors Short name SAP ENG Intel TID UDO FZI FBK PMI CITY XLAB GPI TA Full partner name SAP AG Engineering Ingegneria Informatica S.p.A. Intel Performance Learning Solutions Ltd. Telefónica Investigación y Desarrollo Universität Dortmund FZI Research Centre for Information Technologies Fondazione Bruno Kessler - Centro per la ricerca scientifica e tecnologica Politecnico di Milano City University XLAB razvoj programske opreme in svetovanje d.o.o. GPI S.p.A. Telekom Austria Notices The information in this document is provided "as is", and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law. Copyright 2009 by the SLA@SOI consortium. * Other names and brands may be claimed as the property of others. This work is licensed under a Creative Commons Attribution 3.0 License. Document History Version Date Author Changes SLA@SOI consortium Initial version after first project year SLA@SOI consortium Revised version after second project year SLA@ SOI FP Glossary 2

3 Table of Contents 1 Overview Glossary Services & Products... 7 Service... 7 Service Interface Type... 8 Business Service... 8 IT Service... 8 Hybrid Service... 9 Software Service... 9 Infrastructure Service... 9 Content Service... 9 Offered Service Service Type Service Implementation Service Instance Internal Service External Service Service Lifecycle Roles Service Provider Service Customer Software (Component) Provider Infrastructure Provider Framework Administrator Business Manager Software (Service) Manager Infrastructure Manager SLA Manager Software Designer Service Consumer Agreement Initiator Agreement Responder Agreement Observer Service Level Agreement Service Level Agreement Agreement Offer Agreement Template Agreement Term Service Description Term Guarantee Term Service Level Objective Service Level Consequence IT systems IT layers Software Component Component Context Usage Profile Operation Level Agreement Policy Resource Appliance Virtual Machine Service / Application Management SLA@ SOI FP Glossary 3

4 Manageable Application / Components (Management) Information Model Manageability Infrastructure Instrumentation Management Agent Manageability Interface References SLA@ SOI FP Glossary 4

5 1 Overview The EU FP7 research project [1] researches the systematic management of service level agreements (SLAs) in service provisioning scenarios. This document provides the most important concepts and terms coined in the project. These concepts are consistently used throughout the various outputs of the project in particular the scientific activities but also the industry-oriented use cases. The concepts covered relate to the areas of services, roles, SLAs, IT systems, and IT management. Special emphasis has been put on the interrelationships between the various concepts. Related glossaries There are a couple of related glossary efforts which are briefly reviewed in the following: IT Infrastructure Library: ITIL Version 3 - Service Improvement [2] ITIL provides a very well-defined, coherent and broad glossary for all kinds of terms related with IT assets and IT management. SLA@SOI is generally aligned with the ITIL terminology and shares the notion of service, SLA, OLA, service/infrastructure provider. W3C: Web Services Glossary [3] The W3C glossary focuses on software / Web services and related terms. SLA@SOI is generally aligned with the W3C terminology. SLA@SOI: much more detailed taxonomy for services and SLAs; refined role model NEXOF-RA [4] The NEXOF-RA project defines a very broad set of service-related and general IT-related terms. SLA@SOI is generally aligned with the NEXOF-RA terminology and shares the notion of service and SLAs. BREIN [5] The BREIN project provides an extensive glossary on Grid-, services-, software- and resource-related terms. SLA@SOI is generally aligned with the BREIN terminology and shares the notion of service, SLA, service provider and resource/infrastructure provider. IT-Tude [6] The IT-Tude/gridipedia glossary created by the BeInGrid project covers a large set of grid-related terms. SLA@SOI slightly differs from the IT-Tude notion of services, as it goes beyond Grid services to general purpose services. WSAgreement [7] The WS-standard WSAgreement provides a detailed definition of SLArelated terms. SLA@SOI adopts most of the WSAgreement terminology in the context of SLAs while refining some of them a but further.

6 Unique value of the glossary Though adopts many of the terms specified in other glossaries and is generally aligned with them, there are also some unique value characteristics related to our glossary. 1. Our glossary tends to be more specific than related external ones as it has to take less stakeholder perspectives into account. This relates in particular to the notion of services, where presents a pretty precise taxonomy of services and different flavours and aspects of them. 2. At the same time SLA@SOI takes a broader view on services by considering business, software and infrastructure services simultaneously while many other glossaries tend to focus on one type of service. 3. SLA@SOI attempts to provide concrete examples for almost all terms in order to complement the abstract definitions with some concrete meanings. This of course bears the risk of oversimplification but turned out to be extremely useful in order to grow a common and deep understanding with respective stakeholders. 4. SLA@SOI provides a fairly detailed specification of expected stakeholder roles. 5. SLA@SOI provides some harmonized terms which have different origins (for example on the notion of operation level agreements and contracts). SLA@ SOI FP Glossary 6

7 2 Glossary This chapter features the most important definitions grouped by categories such as services, roles, SLAs, IT systems and others. 2.1 Services & Products This section serves for defining services including the different flavours and perspectives under which they can be considered. The following figure gives an overview about the different perspectives on services, namely the 3 main characteristics that are used to describe a service but also concrete examples/instances for all these categories. Figure 1: Overview on basic service terms Service Status Approved Description A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. (source: ITIL) As the concept of value is very subjective, we might also say that service represents some function or type of task performed by a provider on behalf of a customer. SLA@ SOI FP Glossary 7

8 Services can be further described along the following dimensions: service interface type (business, IT, hybrid) service lifecycle/concreteness ( service type/abstract service, offered service, service implementation, service instance) service exposure ( internal service, external service) A hotel booking service listed in a public registry (requires hotel rooms and some software for the actual service delivery; possibly also human resources). A service endpoint may refer to a hotel room BUT neither the hotel nor a hotel room is a service. A compute service provided by Amazon (requires infrastructure resources but also some management software resources). A service endpoint may refer to a computer BUT the computer is not a service. A payroll service provided by SAP (requires software, infrastructure and human resources). A service endpoint my refer to a payroll component Web service interface BUT the software component is not the service. The service definition is intentionally very broad. We neither specify at this stage any details about service type, concreteness, exposure nor about involved roles nor considered phase of a service lifecycle. Service Interface Type Status Approved Description The service interface type describes the nature of an actually exposed service, i.e. about the nature of his invocation interface. Note that for a service type it does not matter which entities might be needed internally for implementing/delivering a service; e.g. an IT service which internally needs some human administrator for maintaining the internal IT landscape is still considered as an IT service. On the topmost level we can distinguish business services and IT services. In addition, there might be bundled service with a hybrid service type, i.e. having an aggregation of elements of different interface type. Business Service Status Approved Description A business service is exposed/invokable via at least some non IT elements. This may range from supporting features to a bare IT service (such as a support hotline) to purely non-technical services (such as tax consulting). A support hotline offered in combination to some IT services. Human services such as meal delivery or consulting. IT Service Status Approved Description An IT service is exposed/invokable by means of information SLA@ SOI FP Glossary 8

9 technology. IT services are roughly classified into software services, infrastructure services or content services. The business aspects of an IT service in which the user access is at the IT level are considered in the Service Offer for that service. Hybrid Service Status Approved Description A hybrid service is a set or bundle of other services where all these services are exposed to the customer but have different service interface types (e.g. an IT service and a business service). Software Service Status Approved Description A software service is a specific IT service which is exposed/invokable by means of software entities such as Web services, user interfaces, or software-based business processes. A plain Web service. A UI service that can be displayed in a browser. A BPEL process. A complete application (e.g. office application). A middleware (e.g. application server, enterprise service bus). Further sub-types of software services could be easily created such as application services (everything with business logic) and middleware services. Infrastructure Service Status Approved Description An infrastructure service is a specific IT service which exposes resource/hardware-centric capabilities. Note that the boundary between higher-level infrastructure services and lower-level middleware services is blurred; e.g. a middleware database service could be also considered as an enhanced infrastructure storage service. Usage of a (possibly virtualized) compute node as a service. Usage of a (possibly virtualized) storage block device. Usage of a (possibly virtualized) network element (e.g. VPN). Usage of a memory, instruments and sensors. Content Service Status Approved Description A content service (e.g. media/data service) is a specific IT service which exposes the delivery of data over the network over the network. streamed media content (e.g. movies) a digital library SLA@ SOI FP Glossary 9

10 Offered Service Status Approved Product (for commercial offers) Description An abstract service (more precisely: service type) which is offered by a specific Service Provider to its Service Customers. Offered services are typically registered in a service registry so that customers can discover them and can initiate a negotiation procedure. Offered services MAY refer to any service or composition thereof irrespective of the service type. They also MAY have QoS constraints associated with them. An Offered Service may have a purely technical description, or may be described in legal, commercial and business terms (in which case Offered Service is synonymous with Product) A 10Mb/1Mb DSL connection bundled with IPTV offered by Telefonica A suite of web-based enterprise applications offered by Google Offered Services might be of commercial nature or not. Service Type Status Approved Abstract Service Description A service type specifies the external interface of a service possibly including non-functional aspects. It does not specify any means (components, resources) which are needed for the actual provisioning of that service. A hotel booking service listed in a public registry (requires hotel rooms and some software for the actual service delivery; possibly also human resources). A service endpoint may refer to a hotel room BUT neither the hotel nor a hotel room is a service. A compute service provided by Amazon (requires infrastructure resources but also some management software resources). A service endpoint may refer to a computer BUT the computer is not a service. A payroll service provided by SAP (requires software, infrastructure and human resources). A service endpoint my refer to a payroll component Web service interface BUT the software component is not the service. Service Implementation Status Approved Description A service implementation is a possible concrete realization of a given service type. A SQL DB service may have 2 implementations: a MySQL DB or a IBM DB2. A business software might be offered in 2 deployment options, all functions assembled on one logical machine or functions (e.g. App Server and DB) separated on 2 machines. Both implementations may be realized with different actual instances (i.e. each for a particular customer and with particular resources). Service Implementations know about the elements (software SLA@ SOI FP Glossary 10

11 components, hardware resources or others) that are needed to provide the service. There may be more than one Service Implementation for a given service type. Service Implementations may still rely on other service without knowing how those can be/are implemented. Service Instance Status Approved Description A service instance is a concrete realization of an offered service which is ready for consumption by service users. It relies on the instantiations of all the resources required for a given service implementation. A running SQL DB (e.g. based in the service implementation of MySQL) A running business software with a chosen deployment option. A fully deployed address verification services that can be immediately invoked by a service user. Internal Service Status Approved Description Internal services are exposed within the boundaries of an organization, i.e. within one administrative domain. An infrastructure service offered within the IT department of an organization and used by some applications. A lower level software service (e.g. for time conversion) used by higher-level services implementing actual business logic. Internal services (and likewise internal SLAs) have many commonalities with external services ( normal SLAs). However, the legal context is typically more relaxed and so might be the conditions expressed in the respective internal SLAs. External Service Status Approved Description External services are exposed across the boundaries of an organization, i.e. across at least two administrative domain. Amazon Compute Cloud offered over the Internet. Service Lifecycle Status Not intended for approval. Description A service typically undergoes a complete lifecycle, from its early design up to final decommissioning. Details about our envisaged lifecycle including phases and involved roles and activities will be specified in a separate document. SLA@ SOI FP Glossary 11

12 2.2 Roles The following definitions specify the main roles in the context of SLA-based service provisioning. Figure 2: Overview on basic roles We start with the definition of general roles with respect to the service lifecycle. Service Provider Status Approved Description An organization supplying services to one or more internal customers or external customers. (source: ITIL) Service Customer Status Approved Service Client Description Someone (person or group) who orders/buys services and defines and agrees the service level targets. (source: ITIL) The head of an IT department (CIO) who negotiates services with possible providers. In a non-commercial setting the service customer might get a service for free, i.e. without paying anything. SLA@ SOI FP Glossary 12

13 Software (Component) Provider Status Approved Description An organization producing software components which might be used by a service provider to assemble actual services. However, the software provider typically may not know the precise conditions under which his software components will be used within a service. Consequently, a software provider delivers software components rather than services. A database provider who does not know workload and data pattern characteristics of specific customers. A business software provider who has initially crafted the software for very large customers; however, the software is actually also used by a service provider who focusses on a specific niche of very small customers. Infrastructure Provider Status Approved Analogous to a Resource Provider [Foster] Description A specific kind of service provider that focuses on the provisioning of infrastructure services. Framework Administrator Status Approved Description A specialization of service provider: person that configures/adapts the SLA@SOI framework for a specific application. Business Manager Status Approved Description A specialization of service provider: person that defines the SLATs of products and joins available services in a product. Software (Service) Manager Status Approved Description A specialization of service provider: person that defines software-based services, takes care of their management and supports the SLA manager in creating appropriate SLA templates. Infrastructure Manager Status Approved Description A specialization of infrastructure provider: person/system that is interested to measure and control infrastructure properties SLA@ SOI FP Glossary 13

14 Virtual Hardware Manager: Person/System that is interested to measure and control virtual hardware infrastructure properties SLA Manager Status Approved Description A specialization of service provider: person/system that is responsible for managing SLATs and SLA relationships. This role might also coincide with other management roles, e.g. a business manager might be also responsible for business-level SLAs with customers and third parties. Software Designer Status Approved Description A specialization of software provider: person that designs/develops the architecture and components of a specific SLA based application. Service Consumer Status Approved Service User Description Person(s) who actually consume/use the provided services. Typically they belong to the service customer. Employees of a company who actually use the services bought by the IT department. The following role definitions describe the respective roles actors can take within a negotiation. Agreement Initiator Status Approved Description An agreement initiator is a party to an agreement. The initiator creates and manages an agreement on the availability of a service on behalf of either the service customer or service provider, depending on the domain-specific signaling requirements. (source: WSAgreement) In tenders, the template is provided by the customer and the agreement offer by the provider, i.e. the provider is the initiator. Agreement provider may be either provider, customer or any other entity acting on their behalf. Agreement Responder Status Approved Description The agreement responder is a party to an agreement. The responder implements and exposes an agreement on behalf of either the service provider or service customer, depending on the domain-specific signalling requirements. (source: WSAgreement) SLA@ SOI FP Glossary 14

15 Agreement Observer Status Approved Description A third, trusted party that monitors/observes whether an agreement is actually hold by both agreement parties, i.e. service provider and service customer. Not yet considered in SLA@SOI 2.3 Service Level Agreement This section serves for defining core concepts around a service level agreement. Service Level Agreement Status Approved Agreement, SLA Description An agreement defines a dynamically-established and dynamically managed relationship between parties. The object of this relationship is the delivery of a service by one of the parties within the context of the agreement. The management of this delivery is achieved by agreeing on the respective roles, rights and obligations of the parties. The agreement may specify not only functional properties for identification or creation of the service, but also non-functional properties of the service such as performance or availability. Entities can dynamically establish and manage agreements via Web service interfaces. (source: WSAgreement) An Agreement between a service provider and a customer. The SLA describes the service, documents service level targets, and specifies the responsibilities of the service provider and the customer. A single SLA may cover multiple services or multiple customers. (source: ITIL) A Service Level Agreement (SLA) is an element of a formal, negotiated contract between two parties, viz., a Service Provider (SP) and a Customer. It documents the common understanding of all aspects of the service and the roles and responsibilities of both parties from service ordering to service termination. (source: SLA Management Handbook, TMForum) A single SLA may cover simple or compound services, or multiple customers. SLAs may be dynamic. Dynamic SLAs include one or more parameters that are variable. These variable parameters may be associated with agreed pricing scales. Due to the broad usage of SLAs we intentionally provide three definitions which are all valid but emphasize slightly different aspects of an SLA. A slightly weaker form of an SLA is the Operation Level Agreement or Internal SLA which is primarily used for Internal Services or for managing relationships between different internal components. SLA@ SOI FP Glossary 15

16 Agreement Offer Status Approved Description An offer is the description of the agreement relationship that is sent from initiator to responder during agreement creation, indicating the relationship which the initiator would like to form. (source: WSAgreement) The WS-Agreement definition continues to say This offer is accepted or rejected by the responder., but this implies no negotiation so it is removed from here. Agreement Template Status Approved Description An agreement template is a (XML) document used by the agreement responder to advertise the types of offers it is willing to accept. (source: WSAgreement) While WSAgreement promotes XML documents as templates we also support arbitrary other syntax forms backed up by an abstract syntax. Especially for WS-Agreement-compatible templates: Like an agreement document, the template is composed of a template name, a context element, and agreement terms, but additionally also includes information on agreement creation constraints to describe a range of agreements it might accept. Agreement Term Status Approved Description Agreement terms define the content of an agreement. It is expected that most terms will be domain-specific defining qualities such as for example service description, termination clauses, transferability options and others. (source: WSAgreement) This is a combination of multiple Service Description Terms and Guarantee terms, using logical operators. Service Description Term Status Approved SLA parameter Description Service Description Terms describe the functionality that will be delivered under the agreement. The agreement description may include also other non-functional items referring to the service description terms. (source: WSAgreement) An instrument of type X producing data according to spec Y Guarantee Term Status Approved Guarantee Description Guarantee terms define the assurance on service quality associated with the service described by the service definition SLA@ SOI FP Glossary 16

17 terms. They refer to the service description that is the subject of the agreement and define service level objectives, qualifying conditions and business value expressing the importance of the service level objectives. (source: WSAgreement) The quality (e.g. availability) of service on execution that needs to be met When those objectives have to be met Service Level Objective Status Approved SLO, Service Level Target Description Service Level Objective represents the quality of service aspect of the agreement. Syntactically, it is an assertion over the terms of the agreement as well as such qualities as date and time. (source: WSAgreement) A commitment that is documented in a Service Level Agreement. Service level targets are based on Service Level Requirements, and are needed to ensure that the service design is Fit for Purpose. Service level targets should be SMART, and are usually based on Key Performance Indicators (KPIs). (source: ITIL) Availability >= 95% Service Level Consequence Status Approved Service Level Penalty Description An action that takes place in the event that a Service Level Objective is not met. (source: SID Model, TMForum) 2.4 IT systems This section serves for defining core elements of an IT system. IT layers Status Not intended for approval Description An IT system can be grouped into the following main layers (from top to bottom): End-user application: software that exposes functionality to human users. Business logic: functional components implementing basic business rules and logic. They may be used by other business logic components or by end-user applications. Middleware: infrastructural software that implements support functionality, often with a distributed nature. Operating System: system software that provides a layer of abstraction above hardware Hardware: physical hardware-centric resources, their virtualized counterparts and low-level management functionality including SLA@ SOI FP Glossary 17

18 BIOS and firmware. End-user application: a Java client application, A web user interface Business Logic: A web service Middleware: Application server, service bus Operating System: Linux Hardware: CPU, virtual machine Software Component Status Approved Description Software components are the entities produced or assembled at design-time by a software provider. A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. (source: Szyperski eta al., 2002) Software components themselves do not constitute a service nor are attached to a service level agreement. A service provider may decide to offer software component(s) as a service. For this, the component has to be deployed and operated (i.e. running) and special service management actions need to be set in place (e.g. SLA template definition, service registration etc.). So a Software Service can be offered by a Software Component. Nevertheless, not all programs implementing Software Services are necessarily components. The non-functional (or QoS quality of service) properties of these services depend on the components internal structure and their (operational) context. At design-time the software component s non-functional behaviour may be made explicit by the software provider via parameterized contracts. Independent deployment means that a component can be deployed without any knowledge or adaptation of the component s internals (= implementation). This property assures that components can easily be deployed by third parties (not only by the component developer). Component Context Status Approved Description The environment within which a component is used. One component can be instantiated and used within multiple contexts. Several factors of the context influence the component's QoS properties: The usage profile The deployment of the component into a resource environment The external services (here understood as other software and infrastructure artefacts) provided to the component SLA@ SOI FP Glossary 18

19 Usage Profile Status Approved Description A usage profile determines how a component is used within its context, that is, how many calls are made to the component s services (or how frequently these calls are), which service call sequences can be identified and which data is provided as input parameters for the service calls. A reporting function s usage profile might be specified via 10 concurrent users, each of them executing the function at business hours (from 9 to 5) and having a think time of 10 minutes. Operation Level Agreement Status Approved Internal SLA, Parameterized Contract Description Operation Level Agreements / Contracts can be used for specifying the conditions under which an Internal Service or a component is to be used by its customer. A component s provided and required interfaces (including QoS properties) form a contract between the component (supplier) and its environment (client): If the client fulfils the precondition of the supplier, the supplier will fulfil its post condition (source: Betrand Meyer 1992). Such a contract can be parameterized for example, the QoS of the provided services depends on the QoS of the services which the component requires from the environment. Parameterized contracts allow for a parametric specification of a component s QoS properties. Once the context within which the component will be used is known, the parametric QoS specification of the component and the properties of the context can be combined to determine the actual QoS properties of the component. An agreement between an application component and an application server detailing the expected throughput and response time characteristics. Operation level agreements are expected to have many commonalities with Service Level Agreements which should allow for a highly homogeneous and integrated management of both. Policy Status Approved Description A rule which describes a constraint applicable to an entity within the Context under examination. Policies may describe what is allowed (and under what circumstances), what is not allowed (and under what circumstances), or both. Policies are mainly used within the domain of a service/infrastructure provider. Some policies might have been derived from a SLO. Business policies Customers from certain countries get a price reduction of 10% Infrastructure policies Replace each hardware node after 3 years of operation SLA@ SOI FP Glossary 19

20 Rebalance workloads on a CPU as soon as the utilization goes beyond 50% Resource Status Approved Description A generic term that includes IT Infrastructure, people, money or anything else that might help to deliver an IT Service. Resources are considered to be Assets of an Organisation. [ITIL] Some categories of resource include physical resources (e.g. compute node), and virtual resources (e.g. virtual machine). Appliance Status Approved Description A specific bundle of pre-configured Hardware, Operating System and Middleware onto which business logic can be deployed and instantiated. Appliances can be physical or virtual. Virtual Machine + Linux OS + Java Tomcat Application Server Virtual Machine Status Approved Description An instance of a virtual computer, hosting a functional operating system. 2.5 Service / Application Management Manageable Application / Components Status Approved Description To ensure that applications - as part of the overall IT environment managed by a service provider - can be managed according to the provider s needs, they need to provide an additional interface, the manageability interface, for their management. The interface provides the necessary application-specific information and functions to monitor and control the application s services and associated components. The interface must be compatible to the service provider s management environment in terms of the management architecture and related management tools used. (Management) Information Model Status Approved Description A (management) information model defines structures and SLA@ SOI FP Glossary 20

21 languages for describing information that is relevant to the management. More precisely, it defines the syntax and semantics of this information. Most commonly, the central element of an information model represents the managed object, which is used for defining the management abstraction/view on a managed resource (e.g. services, components, hardware resources, etc). Manageability Infrastructure Status Approved Description The manageability infrastructure comprises all elements of the manageable application that are necessary to implement the functions and provide the information that are delivered at the manageability interface. This includes management agents, instrumentation code as well as a management information model that describes the manageability interface. The goal of the manageability infrastructure is NOT to provide a generic management interface. So not all conceivable information is provided. The provided information is rather tailored to the needs of the service provider. Thus, the scope of offered management information in our case is predetermined by the scope of SLA parameters and management functions supported by the SLA management framework Instrumentation Status Approved Description The instrumentation includes the additional code that must be added to a component by the software provider to collect management information, implement management functions and communicate with the management agents. The implementation of the instrumentation s interface to the management agents in terms of functionality, granularity and communication issues is highly application specific and not subject of a management standard. Nevertheless, the instrumentation interface must provide all information and functions that are necessary to map the manageability interface s functionality. Sensors added to BPEL processes delivering events about state changes, for instance allowing determining performance-related QoS properties, like durations. APIs provided by a BPEL engine to access the execution log of processes. This however in most cases is not appropriate for realtime monitoring. Logging code added to a WS implementation, e.g. to log the response time of single methods. Management Agent Status Approved Description The mapping between the application-specific instrumentation SLA@ SOI FP Glossary 21

22 interface and the management architecture-specific manageability interface is handled by management agents. To achieve this, agents can be organized in a hierarchy in which high-level information and functions are provided by an agent using lowlevel information and functions of other agents. In general, an agent must be able to handle requests regarding all managed objects (MOs) and indications that it is responsible for according to the part of the management information model that was assigned to it. The model and information stored by the agent according to this model are part of the agent s management information base (MIB). The agent provides standardized access to the management information stored in its MIB to all management applications using the manageability interface of the application. A management agent itself is comprised of several modules, which also might support autonomic behaviour. Nevertheless, in SLA@SOI we focus on the provision of a unified view on the management information first. Then the agent basically corresponds to a data provider as introduced in WBEM. Note that it s totally left open, which management standard is used for implementing the agent s interface. This, for instance, might be WSDM, WS-Management, JMX or WBEM. Manageability Interface Status Approved Description The manageability interface is the collection of all management agent interfaces that are provided by the application s manageability infrastructure. The manageability interface adheres to the specific management architecture used in the IT provider s environment. Its description is based on a unified information model and functional model, its implementation (through the different management agents) by the organization and communication model. The manageability interface is an abstract concept as it only represents a collection of agent interfaces. It might for instance be implemented as a dedicated management service registry or by means of a CIM object broker (in case of WBEM). SLA@ SOI FP Glossary 22

23 3 References [1] Project Website. URL: [2] ITIL (IT Infrastructure Library): ITIL Version 3 - Service Improvement. URL: [3] W3C: Web Services Glossary URL: [4] NEXOF-RA project: Deliverable D6.1 - Reference Architecture Model V1.1. Actual submission date: 03/04/2009. URL: [5] Brein project: Glossary final public version. D3.2.4, 12/09/2008. URL: -> documents -> deliverables [6] IT-Tude.com: GridDic - the Grid computing Glossary URL: [7] Open Grid Forum: Web Services Agreement Specification (WS-Agreement). URL: SLA@ SOI FP Glossary 23