Report on Cloud License Management Requirements and New Approaches

Transcription

1 Project Acronym: OPTIMIS Project Title: Project Number: Optimized Infrastructure Services Instrument: Thematic Priority: Integrated Project ICT Internet of Services, Software and Virtualisation Report on Cloud License Management Requirements and New Approaches Activity 5: WP 5.1: Federated Service Operation License Management Due Date: M6 Submission Date: 10/12/2010 Start Date of Project: 01/06/2010 Duration of Project: 36 months Organisation Responsible for the Deliverable: Fraunhofer-SCAI Version: 1.0 Status Final Author(s): Wolfgang Ziegler Thomas Weuffel Ana Juan Craig Sheridan Fraunhofer-SCAI Fraunhofer-SCAI ATOS FLEXIANT Reviewer(s) Csilla Zsigri Benoit Hudzia 451G SAP

2 Project co-funded by the European Commission within the Seventh Framework Programme Dissemination Level PU Public X PP Restricted to other programme participants (including the Commission) RE Restricted to a group specified by the consortium (including the Commission) CO Confidential, only for members of the consortium (including the Commission) This is a public deliverable that is provided to the community under the license Attribution- NoDerivs 2.5 defined by creative commons Full licensing information is contained in Annex A. OPTIMIS Consortium

3 Table of Contents EXECUTIVE SUMMARY INTRODUCTION PURPOSE GLOSSARY OF ACRONYMS GENERAL REQUIREMENTS FOR LICENSE MANAGEMENT IN CLOUDS CLOUD PROPERTIES RELEVANT IN OPTIMIS SERVER VIRTUALIZATION TECHNOLOGIES Requirements for Cloud environments Dynamic mobility of workloads among clouds Third party scenarios LICENSES LICENSE SERVER APPLICATIONS SPECIFIC REQUIREMENTS FOR LICENSE MANAGEMENT IN THE OPTIMIS ENVIRONMENT LICENSES LICENSE SERVER APPLICATIONS ADDITIONAL CAPABILITIES Deployment of a complete license service instance to a target infrastructure Deployment of a Trusted Entity Trusted clock Token security NEW APPROACHES LICENSE MANAGEMENT SOLUTIONS IN OPTIMIS SmartLM prototype BEinGRID prototype COMMERCIAL LICENSE MANAGEMENT SOLUTIONS FOR GRIDS/CLOUDS GenLM IBM s BYOSL CONCLUSIONS ANNEX A. GLOSSARY ANNEX B. REFERENCES ANNEX C. LICENSE CONDITIONS OPTIMIS Consortium

4 Index of Figures Figure 1: A firewall blocking the communication between application and license server...2 Figure 2. Actors in licensing and license management in a Cloud environment...5 Figure 3: Deployment of a trusted entity in the Cloud...10 Figure 4: SmartLM license management environment...12 Figure 5: Overall architecture of the SmartLM License Service...13 Figure 6: BEinGRID License Management Architecture...16 Figure 7: Components of GenLM...18 OPTIMIS Consortium

5 Executive Summary Deliverable D reports on requirements for license management in Clouds and new developments in this area. Deliverable D comprises three major sections General requirements for license management in Clouds (section 2) Specific requirements for license management in the OPTIMIS environment (section 3) New approaches (section 4) Section 2 describes requirements with respect to the licenses, requirements on the application level and the license service. It is shown that for single Cloud infrastructures the same requirements are valid as already identified for Grid infrastructures in the last years. As a consequence, software licensing developments of previous Grid projects can de adapted for the Cloud. Second section discusses additional requirements that arise from the advanced features of the OPTIMIS environment, i.e. the support for Cloud federation. Three specific additional requirements have been identified: A proxy for the license server (trusted entity), which is deployed in the Cloud and tunnels the communication between the application API and the license server at the end-users home organisation. The possibility to deploy an entire license server into the Cloud equipped either with a subset of the licenses available at the user s home organisation or with a network connection to the license server of the user s home organisation when a license is requested. The provision of a source for trusted time (trusted clock) accessible by the application API to reduce the risk of license misuse through clock tweaking of the respective VM where the application is executed Finally, new methods for securing a license token have been identified as an additional requirement, which could exploit attributes of a virtualised environment. Section 4 presents new approaches suitable for license management in Clouds. Two of them, stemming from the European Grid projects SmartLM and BEinGRID are already delivering initial responses to the set of requirements identified before. Both are available for the use in OPTMIS. The other two (GenLM and IBM s BYOSL) are either only available under a commercial license or limited to a set of applications of IBM. The conclusions sum up the findings of the three sections on general and OPTIMIS specific requirements and new approaches. During the lifetime of the OPTIMIS one updated version of this deliverable will be produced reflecting the evolution and refinement of requirements and the changing state-of-the-art: D M18: Refined version of Report on Cloud License Management Requirements and New Approaches OPTIMIS Consortium Page 1 of 27

6 1 Introduction Deliverable D describes the requirements for license management in Cloud environments. Why software licensing and management of software licenses is a topic in OPTIMIS at all? The reason is that current technologies for software licensing and management of software licenses has been designed under the assumption that the license server (responsible for the authorization of the execution of a license protected application) and the application are located in the same administrative and network domain. This assumption was valid over the long period when computing took place in the IT infrastructure of an organization or company. IT infrastructure was based on the model of local computing centres providing both resources for computation and the software used for e.g. simulations together with the required licenses locally. Thus, these licenses are provided on the basis of named users, hostnames (IPaddresses), or sometimes as a site license for the administrative domain of an organisation. If we want to use this software in a distributed service oriented infrastructure, using resources that are spread across different administrative domains that do not host the application s license server, we run into trouble as can be seen in Figure 1. Figure 1: A firewall blocking the communication between application and license server With the advent of Grid computing more than 10 years ago using remote resources for e.g. executing simulations became common in the scientific communities. However, Grids were off-limits for commercial, license-protected applications because the licenses usually are bound to hardware within the domain of the user and do not allow access from outside, e.g. due to firewalls, thus, enforcing local use of the protected applications only. In contrast, Grid environments are usually spread across multiple organisations and administrative domains. Even worse, extending Grids to virtualised infrastructures, like utility and Cloud computing, introduces additional limitations since the underlying hardware and their performance indicators, e.g. CPU type and frequency are hidden, while they are often used in license agreements. The wide distribution Clouds have reached today was mostly driven by business interests and it is foreseeable that virtualisation and Cloud infrastructures will rule out the traditional IT infrastructures in the medium term for the same reason. Thus, new mechanisms for software licensing and license management in Clouds for the considerable number of industrial, license OPTIMIS Consortium Page 2 of 27

7 protected applications ready to enter the Cloud are required. Without considering these licensing issues the OPTIMIS approach would be incomplete. Section 2 presents general requirements with respect to Clouds and section 3 presents more specific requirements for the OPTIMIS Cloud environment, which is distinguished from other Cloud infrastructures, e.g. by its capability to dynamically federate Cloud infrastructures or move workload to a new infrastructure provider in case of problems with the current infrastructure. To cope with and benefit from the enhanced elasticity capabilities (e.g. through dynamic federation or workload migration) of OPTIMIS enhanced Cloud infrastructures, a number of specific requirements have been identified that the OPTIMIS toolkit should fulfill in a federated cloud scenario. Moreover, support for dynamic migration of services to another Cloud in case of, e.g. performance problems has also been captured in form of a requirement. Section 4 describes in more detail the two license technology approaches that will be used in OPTIMIS: the outcomes of two European projects, SmartLM and BEinGRID. Finally, to complete the overview of the current state-of-the-art in software licensing in Clouds section 4.2, will present two (commercial) approaches for licensing in distributed computing infrastructures will be presented: GenLM and IBM s BYOSL. 1.1 Purpose The purpose of this deliverable is delivering background information on actual technologies for software licensing and license management for Cloud environments by Presenting requirements for software licensing in Clouds and more specifically in OPTIMIS Clouds Motivating and describing the two approaches to be used in OPTIMIS: SmartLM and the BEinGRID approach Briefly presenting the other two (commercial) approaches for licensing in the Cloud that exist today: GenLM (another token-based approach) and IBM s BYOSL for Amazon s EC2 1.2 Glossary of Acronyms Acronym API BYOSL D DRS EC EC2 ILMT OGF PM PO PVU QoS Definition Application Programming Interface Bring your own software and license Deliverable Document Review Sheet European Commission Amazon Elastic Cloud IBM License Metric Tool Open Grid Forum Project Manager Project Officer Processor Value Unit Quality of Service OPTIMIS Consortium Page 3 of 27

8 SLA VM WP WS-Agreement WSAG4J Service Level Agreement Virtual Machine Work Package Web Services Agreement WS-Agreement for Java OPTIMIS Consortium Page 4 of 27

9 2 General requirements for license management in Clouds Prior to discussing the requirements we present and discuss the different actors in licensing and license management in a Cloud environment. As depicted in Error! Reference source not found. there are five major actors involved: The independent software vendor (ISV), which developed and owns the application, sells the right to use the application to its customers and provides a license that rules the terms of usage. The user who will use the application to achieve a goal. The user s home organisation that buys the right of using the application from the ISV and receives a license for authorisation of the application use managed by a license server. The service provider, which is contracted by the user s home organisation to provide a service (the application) in an external infrastructure environment (the Cloud). The infrastructure provider (Cloud provider) hosting the service deployed by the service provider. Figure 2. Actors in licensing and license management in a Cloud environment As shown in Error! Reference source not found. the ISV provides a license to the user s home organisation that governs the use of the application, e.g. number of features available, number OPTIMIS Consortium Page 5 of 27

10 of machines, which can be used to execute the application in parallel, number of users that might use the application in parallel, etc. The license server at the user s home organisation manages the license and in particular may create a license token for authorising the execution of the application. The license token contains all the information necessary to execute the application according to the user s request (and with the constraints defined in the ISV license). This token is passed to the service provider (together with the application if the service provider does not have a copy of it). In the last step the service provider deploys the service (the application) into the Cloud together with the license token and starts the service or informs the user that the service is ready for execution. 2.1 Cloud properties relevant in OPTIMIS It is widely accepted that the advances and increased adoption of Cloud computing leads to the commoditization and industrialization of IT. Cloud services today range from providing raw computing resources (CPU, storage and network), in the infrastructure layer, to SaaS offerings such as desktop virtualization, CRM or payment application services. It is expected that further advances in Cloud services will go beyond, offering the users and service providers the capability of aggregating and brokering in a wide ecosystem of available commodity services that can be combined and assembled to deliver added-value services. In OPTIMIS this has already started and this segment is called software infrastructure-as-a-service (SIaaS). SIaaS represents the software component of a cloud infrastructure (sitting between the physical infrastructure and the cloud platform). SIaaS encompasses the enabling technologies that are required for a cloud to function properly (for consumers to easily and efficiently use cloud functionality to their best advantage. SIaaS is a service providing specific application support capabilities. SIaaS is not a user consumable cloud service, as it supports applications or higher-tier cloud services. Software developers use SIaaS to create applications not dependant on internal infrastructure components. More information is available in deliverable D7.1.1 (Cloud Taxonomy Report) [12]. Software products can t be left out, they need to adapt to these trends. Software Licenses the right to use a vendor s product are currently offered to customers under many different models [6]: named-user (employee-based), concurrent-user, hardware-platform or device based, role-based and transactional-based. Of all these available models, the most common and problematic in the hybrid cloud scenario envisaged by OPTIMIS are the hardware-platform or device-based models. Issues originate from three different main aspects: use of virtualization, dynamic mobility of workloads among Clouds and third party scenarios such as brokers and aggregators, in more detail described in the following sections. 2.2 Server virtualization technologies Server virtualisation is a software technique that allows perceiving a single physical server as multiple virtual machines (VMs). A VM is then, a software partition created within a physical server such that the guest operating system and application run almost exactly as if they were running into physical machine itself. The piece of software that realises this software abstraction is the hypervisor, or VM Monitor, the piece of software in between the physical server and the VMs. Server Virtualisation is not in any way a modern technique; it has been extensively used during 60 s and 70 s in order to share mainframe computers among several user groups that could run different operating systems on a unique, and usually very expensive, hardware. In late 90 s this technique gain the attention of the industry by the irruption of VMware with x86 virtualisation, and its potential for server consolidation, fault containment, security and OPTIMIS Consortium Page 6 of 27

11 resource management. This supposed to be a significant change in Data Centre management, by breaking the 1:1 association between physical servers and applications and becoming the technology foundation for Cloud computing (IaaS) developments. Today s licensing schemes designed for server virtualization take one of the following approaches[2]: Requirements for Cloud environments Software Licences not bound to any hardware component or physical instance: the license is a mobile object that can be validated independently of the Cloud and physical machine in which the application is being executed. Software licenses are elastic objects: As analogy to Cloud s IT infrastructure elasticity, in Cloud environments Software licences would be able to being managed elastically, on-demand and with a pay-per-use approach. Software licences are charged when used: For any kind of virtualised environments, licenses would not have to be charged while the VM is not running, so that it is not providing service. Software Licences not bound to any specific virtualization technology: Currently there are License Management systems that are bound to the execution of a determined virtualisation technology. In Cloud environments, with the aim of getting full VM portability this restriction would have to be eliminated Dynamic mobility of workloads among clouds In the past, several approaches discussed the need for License Management Systems in distributed Grid environments such as the solutions provided by SmartLM [1], BEinGRID [3] and GenLM[4]. Generally speaking, Software Vendors demonstrated unwillingness to adopt these developments, given that they meant a significant change in their business models: from a fixed and secure income model to a flexible approach and more dominated by the user. But, in any case, Grids did not get the same attention from the market Cloud computing is getting in such a short time span, which makes it difficult for software vendors to ignore it. In fact, current License Market developments show an increasing interest to provide tools to satisfy user requirements in this area, such as OpenLM based on FlexNet Requirements for Cloud environments In general, for using software licenses in distributed computing infrastructures like Clouds licenses must be able to travel with the application to the respective execution environment Software Licences and License Servers are not bound to any particular domain or LAN: Licensed applications have to able to be executed in any Cloud, private, public or hybrid, with licenses validated and used from any available resource Third party scenarios Brokerage and Cloud aggregator scenarios can drive new opportunities for Software Vendors, having new instruments and innovative markets to deliver their products Requirements for Cloud environments: Cloud providers license distribution: Cloud providers could be seen by software vendors as a new distribution channel for their products. Cloud providers would have to be able to authorize third parties to make use of an available licence by a determined period of time, or under determined circumstances. OPTIMIS Consortium Page 7 of 27

12 Cloud providers logical license aggregation: In this scenario a Cloud provider would have to be able to aggregate several software licenses into a offering, managing this aggregation as a single unit. A good example of the appliance of this scenario is a specialized Desktop as a Service offering, containing access to several licensed applications through this offering. 2.3 Licenses For the licenses purchased from the ISV by the end-user s home organisation it would be beneficial to support new business models as e.g. pay per use. This would require a modification of the ISV licenses, which now are purchased at a fixed price independent from the effective usage and with annual maintenance fees. Also, as mentioned above a Cloud provider could by the license from an ISV and host the licenses in a license server inside the Cloud. The Cloud provider could then provide access to the license protected software on a pay per use base to the Cloud users. This model would not require changes of the ISV license. 2.4 License server For the license server controlling the user of applications protected with software licenses it is required either that at runtime of the application a bi-directional network connection is available, which allows the application to connect to the license server to authorize the request to execute it, or that at runtime a local authorization is available, either based on a license server operated in the Cloud or in form of a location independent authorization, e.g. in form of a software token. 2.5 Applications Depending on the type of authorization available as described in the previous section no changes are required in case of access to a license server provided at runtime, either remote at the home organisation of the user or locally in the Cloud, or the applications need to be furnished with an API that allows to use software tokens to determine the authorisation. OPTIMIS Consortium Page 8 of 27

13 3 Specific requirements for license management in the OPTIMIS environment In the OPTIMIS Cloud environment additional requirements arise due to the extended support for elasticity. In case of a detected risk of insufficient resources leading to underperforming services the OPTIMIS toolkit would allow to dynamically add resources of an additional Cloud provider if the current Cloud provider cannot increase its resources. Moreover, also in case of temporary or permanent problems OPTIMIS toolkit would allow to transparently migrate the services to a new Cloud provider. In both cases, licenses for a license-protected application being part of the provided service would have to be available at the new Cloud environment. Since it cannot be assumed in general that the new Cloud provider could provide exactly the license needed to continue the execution of the application this requires a token-based approach, where the token can travel with the application to the new Cloud environment. 3.1 Licenses The ISV license, which is used to create the token is hosted by the user s home organisation and already capable to create applications for this scenario. No additional requirements arise. 3.2 License server Since the license server creating the token is operated at the user s home organisation and does not require a connection with the application during run-time there are no OPTIMIS specific requirements with respect to the license server. 3.3 Applications The applications need to be furnished with an API that allows using software tokens to determine the authorisation. 3.4 Additional capabilities To fully benefit from the increased elasticity through different types of Cloud federation additional capabilities of the licensing service will be developed and implemented on top of the SmartLM solution. Capabilities considered are splitting the license, e.g. in terms of numbers of features, hosted license server at the users home organisation Deployment of a complete license service instance to a target infrastructure When a service including license protected applications is regularly deployed and used in a certain Cloud infrastructure a dedicated license server should also be deployed in this Cloud environment. This would allow the end-user to use the local license server in the Cloud instead of creating tokens using the license server of the end-user s home organisation each time the use of the applications in the Cloud requires authorisation. To achieve this there are two possibilities to realise the license server to be deployed in the Cloud: The deployed license server acts as a proxy to the license server operated at the enduser s home organisation, gets the authorisation to create tokens from this license server and all license management is done by the license server at the end-user s home organisation. This approach requires a network connection between the license server deployed in the Cloud and the license server operated at the end-user s home organisation. The ISV s license is divided thus that a subset is managed at the license server operated at the end-user s home organisation while the other subset is managed by OPTIMIS Consortium Page 9 of 27

14 the license server deployed in the Cloud. This approach does not require a network connection after deployment. Both approaches will be studied and the most suitable selected for implementation in the OPTIMIS project Deployment of a Trusted Entity Instead of deploying a stand-alone license server a trusted entity cloud be deployed in the Cloud. This trusted entity would receive tokens from license server of the end-users home organisations. A license-protected application would then be able to communicate with the trusted entity to verify the authorisation for using the application. Moreover, the trusted entity should allow maintaining a communication channel to the license server to extent or reduce the authorisation inside a token or to invalidate a token. The trusted entity will be designed and implemented in year one and two of the OPTMIS project. Figure 3: Deployment of a trusted entity in the Cloud Trusted clock The API of the application checking the usage authorisation should be able to verify the time of the environment using a trusted source for the time. This helps to avoid that an authorisation can be misused by tweaking the local clock of the VM (or of the hardware resource hosting the VM) the application is deployed with. The extension of the API will be designed and implemented in the second year of the OPTIMIS project Token security Currently the input file required by an application, e.g. the input data for a simulation, is used to protect the token against being used multiple times with different input data. However, this protection should be extended in Cloud environments, e.g. taking information into account that could be contributed by the infrastructure provider or the service provider. Token security mechanisms will be investigated in the third year of the OPTIMIS project. OPTIMIS Consortium Page 10 of 27

15 4 New approaches This section presents new developments having emerged in the last years or months in the area of software licensing and license management suitable for use in Clouds. It includes a presentation of the outcome of the European projects SmartLM and BEinGRID selected for usage together with the OPTIMIS toolkit in the OPTIMIS Cloud environment. Moreover, it briefly presents GenLM, a commercial tool for software licensing in distributed computing environments and IBM s offer for customers to Bring your own software and license (BYOSL) to an Amazon Cloud. 4.1 License management solutions in OPTIMIS OPTIMIS will not develop an own licensing solution but will use two existing approaches that will be adapted to the OPTIMIS Cloud environment: 1. The prototype developed in the European SmartLM project [8] 2. The prototype developed in the European BEinGRID project [9] The reason for selecting these two approaches is twofold: both are available for the OPTIMIS without restricting licenses 1 and both fulfil requirements for the use in Clouds. SmartLM provides new technologies for licensing and license management developed for Grid infrastructures that can be used in Clouds as well. The key property of the licensing technology is the separation of authorisation for license usage (when the user is requesting a license) from the authorisation for executing an application (when the applications starts-up on a remote resource in the Grid or Cloud). The second authorisation is done offline without the need of an connection to the license server at the user s home organisation. This approach requires using the SmartLM API in the application as policy decision point. It makes authorisation information required by the application at runtime available through mobile license tokens that contain inter alia the authorisation information. As the tokens are self-contained mobile objects they can travel with the application whenever the application is moved to an execution environment. The BEinGRID approach in contrast is designed to work on top of an existing license management environment of an application, namely FlexNet [10] and is requiring a network connection at runtime between the VM where the application is executed and the license server. The BEinGRID approach is targeting on applications where the API cannot be replaced. It makes authorisation information available requested by the application during runtime from the license server by tunnelling the request/response protocol between the application and the license server. Since both the SmartLM and the BEinGRID approach already fulfil the basic requirements for use in Clouds and can initially be used out of the box we present in the following sections the respective technology in more detail. 1 The SmartLM prototype can be provided by two partners of the OPTIMIS that were also partners in the SmartLM project: ATOS and SCAI. The BEinGRID prototype is available from an open source repository without restricting licenses. OPTIMIS Consortium Page 11 of 27

16 4.1.1 SmartLM prototype SmartLM is a licensing and license management technology developed in the European SmartLM project [8]. The project started in February 2008 and ended in July 2010 delivering a prototype. The SmartLM License Management Service is a component that provides the technology to authorise execution of license-protected software owned by a site using Cloud infrastructure. Being a stand-alone component the License Management service has no particular requirements towards the OPTIMIS toolkit but is rather addressing requirements coming from other components in OPTIMIS as specified in D [7]. Figure 4 depicts the SmartLM license management environment from the user s point of view. Figure 4: SmartLM license management environment In OPTIMIS we will reuse the prototypical implementation of the SmartLM license service developed in the European project SmartLM. The overall architecture of the SmartLM license service is depicted in the following Figure 5. In contrast to the BEinGRID prototype described in section SmartLM provides both the licensing and authorisation technology and the license management tools as described below Architecture The SmartLM License Service follows a layered architecture comprising 6 layers: Co-allocation, Authentication, Administration, Management, Business, and Persistency. The services, components and interfaces described in the section component detailed architecture are the building blocks of this architecture. Figure 5 depicts the layered architecture of SmartLM highlighting the major communication paths between the components. The following section describes the different layers, the components inside a layer, and their interaction with other components. Finally, since security affects all layers, the fundamentals of the orthogonal SmartLM security are described. OPTIMIS Consortium Page 12 of 27

17 Figure 5: Overall architecture of the SmartLM License Service License Management Service The License Management Service is used as a central service for license administration, license storage and scheduling as well as token processing and usage record creation. It is composed by several components, each responsible for a specific part of the functionality. Since all components, which have a direct interaction with an actor (e.g. a administrator or another service) are implemented as separate web-services, it is possible to migrate a (sub-) set of these to another application server instance or even another host system. All other components are implemented as libraries, which are used by the web-services and other components. For interaction with a SmartLM administrator the Admin Service is used. On the one hand this service provides a set of operations, which allow the administrator to manage the set of handled licenses, for instance add new licenses or remove existing licenses. On the other hand it is responsible for license reservation creation and management. It processes the requests and delegates the scheduling decision to the Licenses Scheduler component, then parses and returns the schedulers result as a web-service-compatible output. The License Scheduler is a database-driven component, which manages all license reservation related operations. It is the elementary component of the License Management Service, since it is the only component maintaining information about all licenses, their states, the current utilization of the licenses and their features, etc. Since we use a relational-database at the scheduler level, all of this information are automatically persisted and exist during runtime and after a restart of the service (except you decide to use a In-memory database). After creating a reservation we use the client side of the Usage Record Creations component to create a new Usage Record. OPTIMIS Consortium Page 13 of 27

18 During the process of adding a new or removing an existing license as well as creating a new token for a reservation, the License Management Service has to interact with the different kinds of storages, to persist the tokens and the license documents. Therefore we introduced the Resource manager component, which is a abstraction layer for first the local file system, where the created tokens are cached/stored, and the Storage Service, where the licenses and all other global accessible documents are stored. The Resource Manager is responsible to find, read and write the required documents and knows how to interact with these different storage types SLA and Negotiation Service The SLA and Negotiation service provides license mechanisms based on WS-Agreement/WS- Agreement Negotiation. The Service is responsible of creating Service Level Agreements as a result of a user request for a license addressed to the license server. The created SLA describes all specific conditions of the application usage the user is entitled to, e.g. application id, duration, number of processors and guarantees like the maximum cost, etc. The WS-Agreement Negotiation protocol is used if the agreement may not be obtained in a single step (e.g. because the initial request cannot be fully satisfied) or the agreement has to be changed during lifetime. In order to implement WS-Agreement and WS-Agreement Negotiation, the SmartLM component SLA and Negotiation Service uses the WS-Agreement Framework for Java (WSAG4J). WSAG4J implements the basic features of the WS-Agreement protocol and also the WS- Agreement Negotiation extension developed in collaboration with the GRAAP working group of the Open Grid Forum. Furthermore, it uses a number of standards in conjunction with WS-Agreement to provide a complete development framework for SLA based services. The compatibility with external Orchestrator s also implementing WS-Agreement and Negotiation is easily accomplished and user driven co-allocation of licenses and compute resources (plus data, network, and other resources as necessary) is provided License Information Service The License Information Service (LIS) is a unique point of aggregation to collect pieces of information from different sources, which are the other components of the License Service. It has been implemented as a Java Web Service with a common front-end and a modular backend, based on Quartz ( a Java job scheduler, which can be embedded as a library. In fact it s possible to plug-in new modules in the back-end in order to collect data from new sources. In this way the other components, which need information are decoupled from the specific SOAP message schema of the source. They are required to know just the LIS front-end interface, the name of the data source and the optional parameters of the query. The mapping between the name of the source and the back-end module is defined in the configuration properties of the LIS, which are file based and can be modified without the need to restart the service. In the same file are included some security parameters which allow the LIS to rely on the authentication and authorization framework of the License Service. Moreover all the documents, exchanged among the License Service s components, are XML based, therefore the LIS supports XQuery ( and adopts Saxon ( as XQuery engine. This is valid also for the main data source, that is the License Management Service, but in addition all the messages exchanged between LIS and License Management Service are base64 encoded. OPTIMIS Consortium Page 14 of 27

19 License Administration Service The License Administration Service (LAS) is the main contact point for the Independent Software Vendor (ISV) and the License Service administrators in general. It acts as a proxy to forward the requests to the various internal components of the License Service and to report back the responses. It has been written in Java and adopts a Web Service interface, implementing a factory pattern to deal with multiple modules, which allow the LAS to interact with the other components, in particular, the License Management Service (LMS), the License Information Service (LIS) and the Policy Engine. The actions performed through the LAS interface are related to license, authorization and policy management, and resemble a CRUD (Create, Read, Update and Delete) paradigm since each of those three groups of operations is based on an XML document as information unit. Given the aforementioned loosely coupled architecture, it s possible to set-up a single LAS as gateway for multiple License Services or to use two LAS instances pointing to a single License Service for redundancy. The LAS relies on the security framework of the License Service, by means of the configuration properties stored in a file, which contains also the addresses of the other components and can be dynamically updated. Thanks to the delegation capability of the security frame- work, the LAS can act on behalf of the real administrator without breaking the authorization policies enforced by the Policy Engine. In fact each request keeps trace of the original user who has sent it. There are two clients that are able to interact with the LAS: a command line interface and a Web portlet Storage Service The Storage Service is responsible for storing XML data permanently in files or databases. This includes e.g. individual usage record documents, licenses and SLAs. Two modules compose the architecture of the service: a front-end module that ensures soap interactions between the backend and the other services belonging to the license server, and the backend that implements the file-system logic. The web-service is able to manage multiple independent storages (data bases or folders), with disparate access policies and backend types. The reason to separate the storages is to increase flexibility, allowing some critical components to manage its own storage while keeping the same interface. Each stored document has a unique identification, and is stored in a database Interfaces Provided A command-line interface and multiple graphical interfaces for the license service are available as depicted in the baseline technology (see Figure 5). However, none of them will be used directly by the OPTIMIS toolkit as described before and thus they are not described here BEinGRID prototype BEinGRID (Business Experiments in GRID) [9] was a research project financed by the European Commission as a part of the FP6 programme. Over four years of BEinGRID life the project covered 25 business experiments using different Grid technologies and some of them using commercial license-protected applications. There are useful license solutions in the market like FlexNet, but they are not supported in Grid or Cloud scenarios. In order to overcome this obstacle, one of the expected results that have been obtained during the course of BEinGRID project is to establish a license management solution able to support Grid or Cloud environment. The License Management Technical Cluster of BEinGRID has developed design patters as well as corresponding implementations to build a generic solution to support the transition to pay- OPTIMIS Consortium Page 15 of 27

20 per-use model for licensed applications from ISVs. The BEinGRID solution therefore needs a license technology like FlexNet that is responsible for the licensing technology and the authorisation of application usage. As shown in Figure 6 the BEinGRID approach consists of a management framework operating on top of this licensing solution, organising both authorisation on a user-level and the transparent tunnelling of the proprietary messages between the licensing components and the application Architecture Components Figure 6: BEinGRID License Management Architecture LM - Job Submission and Description This component allows a user to request license resource and covers the extension of the job description and its submission with respect to license management. These resources can be requested and used simultaneously and the information about the use of license travel with all corresponding job to make a cost-effective use of license. The requested resources can be either own licenses, licenses provided by the service provider or an external LSP. Job submission and description component extends the interface to pass details about authorization, accounting context and license resource to the application. OPTIMIS Consortium Page 16 of 27

21 LM Accounting Accounting component is in charge to perform the accounting and billing of licenses handled by the system. The component requires collecting different information to complete the accounting process. Log information from the proxy: Accounting context Time-stamp Log information from the license server: Time-stamp Number of licenses License features The accounting and billing process do not have a unique procedure to obtain the information related to the license usage, the details depends on whether licenses are owned such as the user, the service provider, an external static LSP or obtained via Grid broker. The functionalities for cost accounting are responsible of a Web Service and afterwards the accounting is triggered by the LM Proxy chain. We show bellow the functionalities of the Web Service: Retrieve the license accounts. Creation of license accounts. Delete license accounts. Retrieve account info from a license account. Provide a view over all license accounts LM - Proxy After the jobs runs at the provider site the LM-proxy establishes automatically the connection via the proxy chain to the license provider, and the license required can be transported. In BEinGRID license management systems the encapsulation is provided by the implantation of LM proxy-chain together with LM monitor. In addition, the license server requires interface to LM Job submission and also need to support both Authorization and Accounting component and it strongly depend on the license management system and the chosen transport layer. For BEinGRID license system implementation are focused on FlexNet as a License Management System and SOCKS as a transport layer LM - Monitor Monitor component monitors the status of available licenses and upon request returns this status to higher level services like license schedulers/brokers or an SLA monitor, in addition covers the ability to co-schedule licenses and resources. LM-Monitor only interfaces with the local scheduler and external Web Service, which in turn queries the license server. The implementation of this component is done as an independent Web Service from the rest of the architecture. OPTIMIS Consortium Page 17 of 27

22 LM Authorization The License Management Technical Cluster has an authorization mechanism covered by this component. LM-Authorization is in charge to trust or not a specific request at submit time via a query to a remote service, firstly based on local access list (ACL) and also there are implemented an alternative run-time authorization via a pin/tan mechanism. LM-Authorization acts in license resource requests as follow: User entitled to use a specific license server. User entitled to use a specific feature of the licensed software. User entitled to use a specific number of licenses. 4.2 Commercial license management solutions for Grids/Clouds Although the technology for software licensing already was identified as a limiting factor for the commercial adoption of Grids in 2005 and just recently was identified being under the top 10 obstacles for Cloud computing by the 451group little progress was made. To complete the presentation of the current state-of-the-art in software licensing two (and to our best knowledge the only two) commercial approaches are presented GenLM GenLM is available under a commercial license. The origin of GenLM is Grid computing and it was first deployed and used in a German national Grid project (PartnerGrid). However, the owners claim that GenLM is also suitable for Cloud environments. GenLM identifies users, resource providers and ISVs as the three stake-holders of Grid computing. GenLM provides a component for each of the stakeholders as depicted in Figure 7. The GenLM client is used by the user or by a pre-processing software to acquire a license token. The GenLM server is responsible for issuing licenses on demand. The GenLM license verifier is included in the ISVs compute software and checks whether a license is valid for the pending job. Figure 7: Components of GenLM The central idea of GenLM is to attach the software license to the input data of the batch job. GenLM creates a license token for a given set of input data. The license token is a file that can be transferred together with the input data to the compute site. It contains all information the license verifier needs in order to check the validity of the software license A. The License Token Lifecycle A token consists of a set of hashes of the input files and a license terms specification which is software-specific. The token is generated by the GenLM client and signed by the GenLM server. During job startup the token is evaluated again, see Figure 7. OPTIMIS Consortium Page 18 of 27

23 When a user wants to submit a job she needs to acquire a valid license token for her input data. The GenLM client starts by computing a cryptographic hash for all input files. These hashes are stored in the token. By the construction of the hash they uniquely identify the input files. In addition, the license terms requested by the user are stored in the token. These license terms are ISV-specific and would typically contain information such as the number of requested cores, the software modules to be used for the job etc. GenLM doesn t evaluate these terms typically, this information is used by the ISV to decide which license to issue for this specific job. The request token is then signed with the user s X.509 certificate and sent to the GenLM server. The server extracts the license terms and the user s identity from the request token. This information is forwarded to a policy plugin which can be implemented by the ISV. The purpose of the plugin is to enforce the ISVs business model. For example, the user s identity can be matched against a customer database. Depending on the contract of the user s organization the request will be billed separately or it is covered by a flat- fee license agreement. All necessary steps in order to be able to bill the customer will be made in the policy plugin. This might involve putting a billing record in a database. Assuming the license request is granted the server uses its own certificate to sign the request token. It is then sent back to the user. In GenLM the signed request token is called a license token since it contains a valid license. Together with the input data the license token is transferred to the compute site. A job is enqueued at the site, which will finally compute the results. On job startup the license token is inspected: First, the signature of the token is inspected. The public key of the license server is used to verify the signature of the license token. If the signature is correct, the application computes the input file hashes based on the local files and compares them with the hashes stored in the token. Given that the locally computed hashes are identical to the hashes stored in the license token, GenLM knows that the license server granted this job and the execution of the computation will be allowed. The major difference to the SmartLM approach is that authorisation of the creation of a token needs an Internet connection to the ISV since the ISV will authorise the license usage through an online process. While in SmartLM between the ISV and the respective customer a chain of trust is established that allows the customer to authorise token creation within the limits of the license acquired from the ISV and including the authorisation information of the ISV, which is finally checked by the application at runtime IBM s BYOSL In cooperation with Amazon IBM is offering the possibility for their customers to use own software licenses under certain conditions in the Amazon Elastic Compute Cloud (EC2) [11]. If the customer has acquired software license entitlements under IBM's International Passport Advantage or Passport Advantage (PA) Express Agreements, the customer may have the ability to run eligible IBM software programs in Amazon EC2 Instances using the bring your own software and license (BYOSL) model, providing the licensing and record keeping requirements defined by IBM are met (Sub-capacity licensing). The bring your own software and license ("BYOSL") option allows customers to bring and upload Eligible IBM software Programs on the Amazon EC2, provided customer complies with the Program use requirements and has sufficient quantities of PA software license entitlements. The BYOSL is restricted to IBM software listed as "eligible" in IBM s "Table of Eligible BYOSL Software Programs" may be uploaded to an Instance. When customer uses OPTIMIS Consortium Page 19 of 27