We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Apps.RSS - FIWARE Forge Wiki

FIWARE.OpenSpecification.Apps.RSS

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Apps.RSS
Chapter Apps,
Catalogue-Link to Implementation RSS-RI
Owner UPM, Francisco de la Vega

Contents

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.

Copyright

  • Copyright © 2013 - 2014 by Telefónica I+D. All Rights Reserved.
  • Copyright © 2015 by UPM

Legal Notice

Please check the following FIWARE Open Specification Legal Notice (implicit patents license) to understand the rights to use these specifications.

Overview

The Revenue Settlement and Sharing System (RSS) GE is in charge of distributing the revenues originated by the usage of a given service among the involved stakeholders. In particular, it focuses on distributing part of the revenue generated by a service between the Marketplace/Store Provider and the Service Provider(s) responsible for the service. With the term "service" we refer to both final applications and backend application services (typically exposed through an API). Note that, in the case of composite services, more than one service provider may have to receive a share of the revenues.

Revenue sharing is based on a set of business models (revenue sharing models) which dictate how to distribute revenues. The RSS GE must be fed, via available APIs, with these models and additional information regarding service providers. In addition, Charging Data Records (CDRs), based on service usage information, must be periodically fed to the RSS GE to enable the revenue sharing process. CDRs must be created by another GE (e.g., the Store GE) and/or external system based on per service specified price models and accounting information.

Different revenue sharing models can be assigned to Service Providers, each of them based on a combination of parameters such as product class. For instance, the revenue sharing model used to calculate payments to a given Service Provider for music may be different from the one used for applications.

The RSS GE exposes an API for other components to send charging information and to manage revenue sharing models. It also features a GUI which can be used by RSS GE and Store GE administrators to manage revenue sharing models, access reporting information and perform additional administration tasks.

Additionally to this functionality the RSS GE must offer the possibility to consult reports, regarding the CDR received, to both RSS and Store administrators. Example of these reports can be the quantity of amounts received in a period, number of transactions per application provider, or information regarding the most purchased applications.

Finally as a supplementary functionality, expenditure limits functionality must be offered in this GE. The expenditure limit API provides a mechanism through which an application provider can limit the amount of money spent by a customer using the services, along a specific time interval. Once this limit is exceeded, it will not be possible to purchase anything until next period of time.

This API exposes the functionality that a provider will use to check the balance and accumulated expenses of a given customer, previously to accept a purchase.

Basic Concepts

In order to understand the functionality provided by the RSS GE, it is needed to describe some basic concepts that will be referenced along this document:

  • Charging Data Record (CDR): A CDR document contains charging information generated during a business transaction, including information of the charged services, the service provider, the customer, the charged amount, etc. These documents are used and aggregated by the RSS GE in order to determine the total amount charged regarding different service providers and applications. These CDRs are generated in external components (e.g the Store GE) and gathered by the RSS GE through the existing APIs.
  • Application/Product Class: An application/product class defines a group of services or applications with similar characteristics. Every application or service registered in the RSS GE belongs to an application/product class.
  • Revenue Sharing Model (RS Model): A RS Model specifies how to divide the total charged amount between the different stakeholders of the related application. These RS Models include information about the service provider, the type of event taken into account in the model (subscription, pay-per-use, etc), etc. RS Models are applied to complete application classes so all the charging information of the services within an application class is distributed according the same RS Model.
  • Settlement: The Settlement refers to the process of aggregating the charging information included in a set of CDRs and calculating the amount to be paid to the different stakeholders according to the related RS Model. The settlement process is launched periodically for all the service providers registered in the RSS GE or manually launched by a system administrator for a concrete service provider.
  • Expenditure Limit: Expenditure limits are defined in the RSS GE in order to allow users to control their expenses. Users of the RSS GE can define different expenditure limits that can be applied to transactions (maximum amount in a single transaction) or over a period (maximum amount spent during the related period). Expenditure limits are taken into account in the scope of a service provider, so users can define different and independent expenditure limits for the applications of different service providers.

RSS Architecture

Figure below shows the Revenue Settlement and Sharing System GE Architecture, which is divided into a series of functional modules.

Architecture of the RSS GE

As shown in the figure above, the RSS GE is divided into two main functional modules. The functionality that each module should provide is detailed below:

  • Settlement Management: This module in charge of the management of the settlement process, including the management of CDRs, Revenue Sharing models and the Settlement itself.
    • CDRs Management: Includes a service where the Store GE can feed the CDR documents containing charging information and a manager in charge of saving and retrieving this documents from the database.
    • Revenue Sharing Models Management: Includes a service where Revenue Sharing models can be fed and retrieved and a manager in charge of saving and retrieving this models from the database.
    • Settlement: This module preforms the settlement process, which aggregates the charging information stored in the different CDRs and calculates the revenue sharing using the related revenue sharing models.
  • Expenditure Limits and Control Management: This module is used to manage the expenditure control, including the management of expenditure limits and balance accumulated.
    • Expenditure Limits Management: Includes a service where expenditure limits can be fed and retrieved, and a manager for the creation and retrieving of expenditure limits in the database.
    • Balance Accumulated Management: This module is charge of the management of the accumulated balance. In this way, this module provides an endpoint where the accumulated balance of a user can be retrieved and updated according to charges in the Store GE. Moreover, this module is used to check if a transaction can be made according to the previously defined expenditure limits and balance.


The following diagram gives an overview of how the RSS GE interfaces with the rest of the GEs that make up the FIWARE business framework.


Architecture of the RSS GE


The main interactions between RSS and other GEs are based on REST services. The main interactions between the RSS GE and other components follow:

  • Store GE: This GE is in charge of the monetization of the different digital assets offered in the FIWARE Business Framework. In this way, the Store GE interacts with the RSS GE as follows:
    • Reception of CDRs: The Store GE feeds the RSS GE with detailed charging information related to the applications and services being offered in the FIWARE Business Framework. To do that, every time a user that has acquired an offering in the Store GE is charged (once, periodically, use-based), the Store GE generates a CDR document containig detailed information of the transaction and feeds the RSS GE with it.
    • Management of expenditure limits: The Store GE relies in the RSS GE to control the expenditure limits of the Business Framework users. To manage this limits, the Store GE uses the following services:
      • Expenditure limits management. The Store GE is able to create/update/delete expenditure limits for customers in any service provider or for a particular one. The limits could be defined for transactions and for time periods: daily, weekly or monthly.
      • Expenditure limits control. The Store GE asks the RSS GE if the customer will not exceed the expenditure limit because of the current transaction and feeds the RSS GE to update the new expenditure balance once the charge has been produced.
    • Management of Revenue Sharing Models: When a service provider creates a new offering in the Store GE, it retrieves the existing Revenue Sharing models related to the provider in order to allow her to choose the one that will be used during the settlement process of the charges originated by the offering. If none of the revenue sharing models fits the provider needs, the Store GE redirects the provider to the RSS GE in order to create a new one.
  • Repository GE: This GE is in charged of maintaining service descriptions in Linked USDL format. The RSS GE uses the Repository GE to save and retrieve Revenue Sharing models that has been serialized in RDF and linked to the service description.
  • Identity Management GE: The RSS GE uses the Identity Management GE to authenticate and authorize the users of the FIWARE Business Framework when accessing the APIs and/or the administration page.
  • Payment Broker (external component): The RSS relies on an external payment broker (e.g PayPal, bank payment gateways, etc) in order to actually pay service providers once the settlement process has finished.

Data Model

The RSS GE data model is depicted in the diagram below:

RSS GE data model


Note: the diagram above describes the general datamodel managed by the RSS GE; however, a GE implementation does not need to follow exactly this structure in the database.

The main data artifacts are described in the following paragraphs. Note that the parameters for these artifacts are distributed between different related tables of the above data model.


Revenue Sharing models

Revenue Sharing (RS) models describe the way to distribute revenues between the different stakeholders involved in a given service. A Revenue Sharing model is defined by:

  • Identifier. A unique model identifier.
  • Description. A textual description of the model.
  • Revenue source: The system that is originating charging information that will be part of the revenue sharing process.
  • Event id: Event that is being charged (pay per use, subscription, etc.).
  • Service provider id: Provider of the service charged.
  • Application Class: Type of application or service which is being charged. Note that the revenue sharing process will use charging information associated with all applications within the given class.
  • An algorithm. It defines how the share is calculated. The algorithm consists of:
    • Textual description. Short explanation of the algorithm.
    • Algorithm type. Type of algorithm applied to calculate revenue shares such as fixed percentage, functions with an increasing slope, intervals with fixed share per interval, etc.
    • Parameters. A set of values for the parameters associated to the algorithm (e.g. for the fixed percentage algorithm, the specific percentage), including the ids of the different stakeholders involved.

CDRs

CDRs provide charging information related to the usage of services available. Therefore they should provide information about the actual service being used, the application which uses the service, the Service Provider, the costs incurred, etc. Thus it should contain, at least, the following parameters:

  • CDR source: The system that is providing CDRs (Store, charging application, etc.).
  • CDR type: Type of CDR (charge, refund, etc.).
  • Correlation id: CDR sequence number - must be unique for each source.
  • Time Stamp: Time/date.
  • Country id: Mobile Country Code (ITU MCC).
  • Application id: Application or service which is being charged.
  • Parent Application Id (optional): Application which uses the service being charged.
  • Event id: Event that is being used for charging (subscription, pay per use, etc.).
  • Purchase Code: Identifier, in the source system, of the actual purchase operation.
  • Description: Additional textual description.
  • Cost: Amount of a given currency charged in this CDR.
  • Taxes: Taxes charged in this CDR in a given currency.
  • Currency: Actual currency used for charges.
  • User id: Consumer of the service.
  • Service Provider id: Provider of the service.
  • Product class: Application category.
  • Refund reason (optional): Free text describing reason for refund CDRs.

Service Providers

RSS GE needs to know the following information about Service Providers:

  • Identifier: Unique Service Provider reference.
  • Name: Legal name of the Service Provider.
  • Country id: Country where the Service Provider is established (ITU MCC).
  • Provider email: Email address of the service provider.
  • Provider address: Billing address of the service provider.
  • Payment currency: Currency in which the Service Provider will receive the payments.
  • Payment method chosen to receive the revenues. Different payment methods are supported, like:
    • Credit card. Note a Service Provider may have several credit cards. Parameters required:
      • Card number
      • Card name
      • Security code
      • Description
      • Expiration date
      • Credit card provider (VISA, MasterCard, etc.).
    • Paypal. Parameters required:
      • Email address
    • Bank account. Note a Service Provider may have several accounts. Parameters required:
      • Account number
      • Account name
      • Description
      • Swift code (US accounts)
      • IBAN (EU accounts)
      • Bank office address (EU accounts).

Expenditure limit information

Expenditure limits allow users to define the maximum expenses they allow within a period of time. This expenditure limits are applied in the scope of a given service provider, so users can define different expediture limits for the applications of different service providers.

In order to create and manage the information of expenditure limits and accumulated expenses of a customer, the RSS needs to know:

  • Limit Type: Type of period to check the expenses of a customer (diary, weekly, etc...).
  • Currency: Currency in which the amount must be paid.
  • Max Amount: Maximum expenses allowed along the period of time.
  • Service Provider id: Provider of the service.
  • User id: User identifier.
  • Expensed amount: Spent amount in the current period of time.
  • Next period start: Beginning of the next period of accumulation.

Main Interactions

This section contains the description of the main interactions that can occur between the RSS GE and their users or other components and generic enablers. The main interactions supported by the RSS GE follow:

  • Gathering CDRs
  • Create RS Models
  • Get RS Models
  • Update RS Models
  • Delete RS Models
  • Create Expenditure Limits
  • Get Expenditure Limits
  • Update Expenditure Limits
  • Delete Expenditure Limits
  • Check Balance Accumulated
  • Update Balance Accumulated

Additionally, the RSS GE interacts with external components for the management of users, service providers, and payments as described below:

  • Users management: The RSS GE gets information about its users (basically administrators) from the IdM GE of the FIWARE Security chapter. This information should include a user's identity, role and other relevant parameters. Besides, the RSS GE relies on the IDM GE for the authentication and authorization of users accessing the RSS GE.
  • Service Providers management: The RSS GE receives information about Service Providers from the Store GE. In this case, Service Providers are those users that have the provider role in the Store GE since is in this GE where offerings are created. When a new Service Provider accesses the Store GE, this component uses the RSS GE APIs to register the needed information regarding the Service Provider.
  • Payment Management: In order to distribute the revenue shares to all stakeholders, the RSS GE uses the payment data stored with the service provider information and an external payment broker which is the component that performs the payments to the different stakeholders.

Interaction Diagrams

Gathering CDRs

In order to calculate revenue shares, The RSS GE must be fed with CDRs by the Store GE as can be seen in the following diagram:

File:Receive-CDR.png
Gathering CDRs from the Store GE


Every time the Store GE charges a customer, it sends this charging information to the RSS GE in a list of CDRs or in a single one depending on the pricing model. Each CDR must include the parameters described in the CDRs section of this document.

Get RS Models

The RSS GE allows to retrieve the existing RS Models using its API. This allows the Store GE to retrieve the models created by a service provider in order to choose the RS model that best fits an offering being created. In this way, the Store GE binds the Application Class of the model to the offering in order to include it later in the CDRs.

File:Get-RS-Models.png
Store GE retrieving RS models of a provider


As can be seen in the diagram above, when retrieving the RS Models, the Store GE will provide the service provider id in order to retrieve her RS Models. However, it is also possible to retireve all the RS Models existing in the RSS GE.

Create, Update and Delete RS Models

In order to determine how to distribute generated revenues, service providers can create RS Models using the web interface of the API provided by the RSS GE, as can be seen in the following diagram.

File:Create-RS-Model.png
Creating RS Model from the RSS GE portal


To create a new RS Model the service provider have to include the parameters described in the Revenue Sharing Models Section of this document.

Moreover, service providers can update their RS Models providing new values for the different fields of the models and remove those models that are not needed.

Get Expenditure Limits

The RSS GE allows to retrieve the expenditure limits of the users in the system via API. It is possible to retrieve the default expenditure limits defined for the applications of a provider, or retrieve the limits established by a concrete user for the applications of a given service provider.


File:Retrieve-expenditue-limits.png
Retrieving expenditure limits from the RSS GE


As can be seen in the diagram above, the request can include different params: (1) The request can include only the service provider id, so the default expenditure limits for the service provider are returned. (2) The request can also include the user id, in which case the expenditure limits established by the user are returned.

Create, Update and Delete Expenditure Limits

In order to manage, check and update the expenses of a customer along a period of time, the Store GE will have to interact with the RSS GE to create/update/delete expenditure limits. In this way, the Store GE allows its users to manage their expenditure limits in the RSS GE in order to control their expenses when acquiring offerings.


File:Create-up-del-exp-limits.png
Creating and deleting Expenditure Limits from the RSS GE


As can be seen in the diagram above, expenditure limits can be created including only the service provider id. In this case, limits will be used as the default expenditure limits for users acquiring the applications of the related service provider.

On the other hand, expenditure limits can be created including also a user id. In these cases, the new limits replace the default limits for the service provider (if existing).

The request for creating a new expenditure limit must contain the following information:

  • type. Type of the limit (per transaction, daily, weekly or monthly).
  • maxAmount. Amount of the limit.
  • currency. Identifier of the currency to be charged in.


In the same way, it is possible to remove the existing limits for the applications of a service provider, including the default limits and the specific limits defined by the users.


Note: The RSS GE uses the same request for updating and creating expenditure limits.

Check and Update Balance Accumulated

In addition to the expenditure limits operations, the RSS GE also allows to check and update the balance of the different users according to the defined expenditure limits. The Store GE uses these operations to check if a user can perform a transaction without exceeding the limits and update the limit of the user once she has been charged.


File:Update-balance.png
Checking and Updating the Accumulated Balance of a user


As can be seen in the diagram above, the check and update balance operations include some information of the transaction being performed. This information must include the following fields:

  • appProviderId. Identifier of the provider.
  • service. The service or application that is being charged.
  • amount. Amount of the last expense to be checked or charged.
  • currency. Identifier of the currency to be charged in.

Basic Design Principles

The RSS GE exposes all its functionalities as REST Services to facilitate integration with other GE and external components. Besides, it provides a web based GUI for operation and management. The type of algorithms the RSS can use for calculating revenue shares can be easily extended by adding new algorithms.

In general, GE implementations should follow the following design principles:

  • API Technology Independence
The API abstracts from the specific implementation technology. Implementations using more than one type of platform and framework should be possible.
  • Web Browsers should not limit the functionalities of the RSS GE
HTML5, CSS and JavaScript must be used to fully exploit the brand new Web applications capabilities.


Re-utilised Technologies/Specifications

The RSS GE is based on RESTful Design Principles. The technologies and specifications used in this GE are:

  • RESTful web services
  • HTTP/1.1
  • JSON and XML data serialization formats
  • Linked USDL

Detailed Specification

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties. For a summary of terms and definitions managed at overall FIWARE level, please refer to FIWARE Global Terms and Definitions


  • Aggregator (Role): A Role that supports domain specialists and third-parties in aggregating services and apps for new and unforeseen opportunities and needs. It does so by providing the dedicated tooling for aggregating services at different levels: UI, service operation, business process or business object levels.
  • Application: Applications in FIWARE are composite services that have a IT supported interaction interface (user interface). In most cases consumers do not buy the application, instead they buy the right to use the application (user license).
  • Broker (Role): The business network’s central point of service access, being used to expose services from providers that are delivered through the Broker’s service delivery functionality. The broker is the central instance for enabling monetization.
  • Business Element: Core element of a business model, such as pricing models, revenue sharing models, promotions, SLAs, etc.
  • Business Framework: Set of concepts and assets responsible for supporting the implementation of innovative business models in a flexible way.
  • Business Model: Strategy and approach that defines how a particular service/application is supposed to generate revenue and profit. Therefore, a Business Model can be implemented as a set of business elements which can be combined and customized in a flexible way and in accordance to business and market requirements and other characteristics.
  • Business Process: Set of related and structured activities producing a specific service or product, thereby achieving one or more business objectives. An operational business process clearly defines the roles and tasks of all involved parties inside an organization to achieve one specific goal.
  • Business Role: Set of responsibilities and tasks that can be assigned to concrete business role owners, such as a human being or a software component.
  • Channel: Resources through which services are accessed by end users. Examples for well-known channels are Web sites/portals, web-based brokers (like iTunes, eBay and Amazon), social networks (like Facebook, LinkedIn and MySpace), mobile channels (Android, iOS) and work centers. The access mode to these channels is governed by technical channels like the Web, mobile devices and voice response, where each of these channels requires its own specific workflow.
  • Channel Maker (Role): Supports parties in creating outlets (the Channels) through which services are consumed, i.e. Web sites, social networks or mobile platforms. The Channel Maker interacts with the Broker for discovery of services during the process of creating or updating channel specifications as well as for storing channel specifications and channeled service constraints in the Broker.
  • Composite Service (composition): Executable composition of business back-end MACs (see MAC definition later in this list). Common composite services are either orchestrated or choreographed. Orchestrated compositions are defined by a centralized control flow managed by a unique process that orchestrates all the interactions (according to the control flow) between the external services that participate in the composition. Choreographed compositions do not have a centralized process, thus the services participating in the composition autonomously coordinate each other according to some specified coordination rules. Backend compositions are executed in dedicated process execution engines. Target users of tools for creating Composites Services are technical users with algorithmic and process management skills.
  • Consumer (Role): Actor who searches for and consumes particular business functionality exposed on the Web as a service/application that satisfies her own needs.
  • Desktop Environment: Multi-channel client platform enabling users to access and use their applications and services.
  • Front-end/Back-end Composition: Front-end compositions define a front-end application as an aggregation of visual mashable application pieces (named as widgets, gadgets, portlets, etc.) and back-end services. Front-end compositions interact with end-users, in the sense that front-end compositions consume data provided by the end-users and provide data to them. Thus the front-end composition (or mashup) will have a direct influence on the application look and feel; every component will add a new user interaction feature. Back-end compositions define a back-end business service (also known as process) as an aggregation of backend services as defined for service composition term, the end-user being oblivious to the composition process. While back-end components represent atomization of business logic and information processing, front-end components represent atomization of information presentation and user interaction.
  • Gateway (Role): The Gateway role enables linking between separate systems and services, allowing them to exchange information in a controlled way despite different technologies and authoritative realms. A Gateway provides interoperability solutions for other applications, including data mapping as well as run-time data store-forward and message translation. Gateway services are advertised through the Broker, allowing providers and aggregators to search for candidate gateway services for interface adaptation to particular message standards. The Mediation is the central generic enabler. Other important functionalities are eventing, dispatching, security, connectors and integration adaptors, configuration, and change propagation.
  • Hoster (Role): Allows the various infrastructure services in cloud environments to be leveraged as part of provisioning an application in a business network. A service can be deployed onto a specific cloud using the Hoster’s interface. This enables service providers to re-host services and applications from their on-premise environments to cloud-based, on-demand environments to attract new users at much lower cost.
  • Marketplace: Part of the business framework providing means for service providers, to publish their service offerings, and means for service consumers, to compare and select a specific service implementation. A marketplace can offer services from different stores and thus different service providers. The actual buying of a specific service is handled by the related service store.
  • Mashup: Executable composition of front-end MACs. There are several kinds of mashups, depending on the technique of composition (spatial rearrangement, wiring, piping, etc.) and the MACs used. They are called application mashups when applications are composed to build new applications and services/data mash-ups if services are composed to generate new services. While composite service is a common term in backend services implementing business processes, the term ‘mashup’ is widely adopted when referring to Web resources (data, services and applications). Front-end compositions heavily depend on the available device environment (including the chosen presentation channels). Target users of mashup platforms are typically users without technical or programming expertise.
  • Mashable Application Component (MAC): Functional entity able to be consumed executed or combined. Usually this applies to components that will offer not only their main behaviour but also the necessary functionality to allow further compositions with other components. It is envisioned that MACs will offer access, through applications and/or services, to any available FIWARE resource or functionality, including gadgets, services, data sources, content, and things. Alternatively, it can be denoted as ‘service component’ or ‘application component’.
  • Monetization: Process or activity to provide a product (in this context: a service) in exchange for money. The Provider publishes certain functionality and makes it available through the Broker. The service access by the Consumer is being accounted, according to the underlying business model, and the resulting revenue is shared across the involved service providers.
  • Premise (Role): On-Premise operators provide in-house or on-site solutions, which are used within a company (such as ERP) or are offered to business partners under specific terms and conditions. These systems and services are to be regarded as external and legacy to the FIWARE platform, because they do not conform to the architecture and API specifications of FIWARE. They will only be accessible to FIWARE services and applications through the Gateway.
  • Prosumer: A user role able to produce, share and consume their own products and modify/adapt products made by others.
  • Provider (Role): Actor who publishes and offers (provides) certain business functionality on the Web through a service/application endpoint. This role also takes care of maintaining this business functionality.
  • Registry and Repository: Generic enablers that able to store models and configuration information along with all the necessary meta-information to enable searching, social search, recommendation and browsing, so end users as well as services are able to easily find what they need.
  • Revenue Settlement: Process of transferring the actual charges for specific service consumption from the consumer to the service provider.
  • Revenue Sharing: Process of splitting the charges of particular service consumption between the parties providing the specific service (composition) according to a specified revenue sharing model.
  • Service: We use the term service in a very general sense. A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. Services could be supported by IT. In this case we say that the interaction with the service provider is through a technical interface (for instance a mobile app user interface or a Web service). Applications could be seen as such IT supported Services that often are also composite services.
  • Service Composition: in SOA domain, a service composition is an added value service created by aggregation of existing third party services, according to some predefined work and data flow. Aggregated services provide specialized business functionality, on which the service composition functionality has been split down.
  • Service Delivery Framework: Service Delivery Framework (or Service Delivery Platform (SDP)) refers to a set of components that provide service delivery functionality (such as service creation, session control & protocols) for a type of service. In the context of FIWARE, it is defined as a set of functional building blocks and tools to (1) manage the lifecycle of software services, (2) creating new services by creating service compositions and mashups, (3) providing means for publishing services through different channels on different platforms, (4) offering marketplaces and stores for monetizing available services and (5) sharing the service revenues between the involved service providers.
  • Service Level Agreement (SLA): A service level agreement is a legally binding and formally defined service contract, between a service provider and a service consumer, specifying the contracted qualitative aspects of a specific service (e.g. performance, security, privacy, availability or redundancy). In other words, SLAs not only specify that the provider will just deliver some service, but that this service will also be delivered on time, at a given price, and with money back if the pledge is broken.
  • Store: Part of the Business Framework, offering a set of services that are published to a selected set of marketplaces. The store thereby holds the service portfolio of a specific service provider. In case a specific service is purchased on a service marketplace, the service store handles the actual buying of a specific service (as a financial business transaction).
  • Unified Service Description Language (USDL): USDL is a platform-neutral language for describing services, covering a variety of service types, such as purely human services, transactional services, informational services, software components, digital media, platform services and infrastructure services. The core set of language modules offers the specification of functional and technical service properties, legal and financial aspects, service levels, interaction information and corresponding participants. USDL is offering extension points for the derivation of domain-specific service description languages by extending or changing the available language modules.
Personal tools
Create a book