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.Marketplace R4 - FIWARE Forge Wiki

FIWARE.OpenSpecification.Apps.Marketplace R4

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Apps.Marketplace
Chapter Apps,
Catalogue-Link to Implementation WMarket
Owner UPM, Aitor Magán



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 © 2014 by SAP
  • Copyright © 2015 by UPM

Legal Notice

Please check the following FIWARE Open Specification Legal Notice (essential patents license) to understand the rights to use this open specification. This scheme differs from the one chosen for the rest of open specifications that make up the FIWARE platform since it is inherited from the one chosen by SAP between the two FIWARE license schemes allowed in Release 3.

To illustrate this open specification license from our perspective:

  • The specifications of this Generic Enabler are made available under IPR rules that allow for a exploitation and sustainable usage both in Open Source as well as proprietary, closed source products to maximize adoption.
  • This Open Specification is exploitable for proprietary 3rd party products and is exploitable for open source 3rd party products, including open source licenses that require patent pledges.
  • If the owner of this GE spec holds a patent that is essential to create a conforming implementation of the GE spec (i.e. it is impossible to write a conforming implementation without violating the patent) then a license to that patent is deemed granted to the implementation.

Note: SAP provides the software associated to the Marketplace - RI (Reference Implementation) according to the initial specification. UPM provides the software associated to the Marketplace - RI (WMarket) according to the current version of the specification as reflected in these pages. Both implementations are provided as open source under the BSD License. Please check the specific terms and conditions linked to this BSD open source license at https://github.com/conwetlab/WMarket/blob/master/LICENSE.txt. You can also obtain the Marketplace GE software using the FIWARE Catalogue at http://catalogue.fiware.org/enablers/marketplace-wmarket


In general a marketplace is an instrument to facilitate commerce by bringing together vendors and buyers, or offers and demand, or producers and consumers. A marketplace can support a variety of mechanisms to achieve this. This specification describes the FIWARE Marketplace Generic Enabler, which is part of the Applications/Services Ecosystem. Any offering in context of the application and service business can be supported by marketplace functionality. A marketplace implementation can offer many different kinds of services to the participants.

The core functionality of the Marketplace is to provide a uniform service interface to discover and match application and service offerings from providers and sources (e.g. published by different stores) with demand of consumers. This core functionality provides a basis for extended services depending on the domain and nature of the target markets.

Target usage

Internet based business networks require at least one marketplace and multiple stores, where people can offer and deal with services like goods and finally combine them to value added services. Offerings from stores are published on the marketplace where users can quickly find and compare them, which enables them to attend an industry-ecosystem better than before. Services become tradable goods, which can be offered and acquired on internet based marketplaces. Besides automated Internet services, this also applies for services that are provided by individuals. Partner companies can combine existing services to new services whereby new business models will be incurred and the value added chain is extended. The marketplace may also support the decision-making processes involved in the pricing choices a service provider in the FIWARE environment must make for its offerings.

Given the multitude of apps and services that will be available on the Future Internet, providing efficient and seamless capabilities to locate those services and their providers will become crucial to establish service and app stores. Besides well-known existing commercial application stores like Apple App Store or Google Play, there are first efforts to establish open service and app marketplaces, e.g. in the Amazon Web Service Marketplace, the U.S. Government‘s Apps.Gov repository and Computer Associates‘ Cloud Commons Marketplace. While these marketplaces already contain a considerable number of services, they are currently, at a premature stage, offering little more than a directory service. FIWARE will fill this gap by defining Generic Enablers for marketplaces and providing reference implementations for them.

User roles

  • Service provider will place offers on the marketplace or in a service/app store and is supported in pricing choices
  • Consumer can search, browse and compare offers
  • Repository will be used to get services descriptions
  • Service store will participate on a marketplace and publish offerings.
  • Channel Maker give consumers access to the marketplace

Basic Concepts

The marketplace is structured into five core components. These components are Registry and Directory, Offering & Demand, Discovery & Matching, Recommendation, and the Review and Rating component.

Registry and Directory

The Registry and Directory component holds information of registered stores, participants and their role (vendors, buyers, resellers, ...) and takes care of registering, updating, and deleting information about market relevant entities.

Offering & Demand

A service offering consists of a link to a concrete USDL description, a pricing model and a classification of the service. The Offering component is responsible for exchanging service offerings with stores and version handling/archiving of out-dated offerings.

Symmetrically to offerings also the demand side of the market need to be represented. A service demand can be created according to expected functionality, pricing and service levels, classified and published to the marketplace.

Discovery & Matching

This component is about discovering and matching offering and demand, either explicitly expressed by concrete offerings or implicitly contained in the search criteria for the inquiry process.


This component provides the user service recommendations based on the user's profile and context in comparison to explicit semantics of available offerings as well as previous activities and experiences of the marketplace participants (Wisdom of the crowd and social networks).

Review & Rating

The Review and Rating component allows users of the marketplace to give textual and star-rating feedback for services and stores along predefined categories. Reviews of users and their overall rating about applications and services can be used to improve the quality of the recommendation.

Marketplace Architecture

The Marketplace GE is used by other GEs within the FIWARE platform, namely the Composition Editor and the Service IDE. The Marketplace itself relies on functionality provided by the Identity Management Service GE and the Repository.

Marketplace in the context of the Business Framework

The Marketplace provides functionality necessary for bringing together offering and demand for making business. These functions include basic services for registering business entities, publishing and retrieving offerings and demands, search and discover offerings according to specific consumer requirements as well as lateral functions like review, rating and recommendation. FIWARE will focus on the core functions but aims to provide a framework to offer also additional services. Beside the core functions, a marketplace may offer value based on its "knowledge" about the market in terms of market intelligence services, pricing support, advertising, information subscription and more.

Furthermore, the marketplace can be accessible by an HTML-based user interface for end users (Marketplace Portal), namely service consumers and service providers (stores) or a programmatic API, which allows embedding market place functionality into existing applications and environments. So for example, the marketplace API can be used in order to provide marketplace access directly embedded into the composition environment (in-app shopping). A service/application store can register at the marketplace in order to create new service offerings on the marketplace. The actual buying process always takes place at a store. So for ordering a specific service, the buyer gets redirected to the store's ordering management service.

The functional components of the marketplace implementation are outlined in the following diagram. This functional architecture figure is to be seen as a blueprint for implementers of the marketplace GE. It does not presume the use of a certain technology. The general idea is that all functions will operate on a huge (virtual) database of entities relevant for the business framework, such as people, organizations, products, services, offerings, ratings, etc. In practice this data might be in one uniform distributed database or a set of databases, which only virtually build the marketplace database. In fact for scaling reasons, in huge marketplaces the database is rather realized by many systems, distributed globally. Linked Data can be a good foundation for a marketplace database abstraction layer (the web is the database). In this case, which FIWARE is focusing on, the marketplace database is more like a (semantic) index of all marketplace information bits and pieces stored elsewhere. As a query and update mechanism, we are relying on Semantic Web Repositories, Query Systems and a Query Language. The figure below shows the marketplace in context of the business framework.

Architecture of a Marketplace implementation

Main Interactions

Each functional block of the Marketplace can be considered as a GE as well. Consequently it has an own abstract operation protocol specification attached.

Registration and Directory (mandatory)

It should be possible to register a number of marketplace relevant entity types such as stores, market participants and their roles in certain business aspects (provider, consumer, reseller ...). The diagram below depicts an exemplary sequence of operations with the Registration and Directory component. A user application refers to an application which has marketplace functionally embedded.

Sequence of registration operations

The Marketplace provides a Register Entity operation for registering market participants and related business elements. It can be used to register a new Store on the marketplace. Parameters:

  • entity - Description of the entity to be created.

The following core entity types are supported:

  • Store - The stores which are comprised by the marketplace. The target stores will be queried by other marketplace components, in order to retrieve store offerings and to perform any store operations on them
  • Market Participant - The participants (users) of the marketplace. A market participant must have at least one of the following roles:
    • Guest - Guest users are only allowed to use the discovery capabilities of the marketplace.
    • Consumer - The actual buyers. The organizations or persons who can buy services and applications on the marketplace.
    • Provider - Providers of services and applications available on the marketplace. Information about providers must be made available different components on the marketplace.
    • Reseller - Reseller of services and applications. The reseller has no own service portfolio and sells services from other providers.

Existing registration information on the marketplace can be modified or updated with the Update Registry Entry operation. The parameters are similar to the Register Entity operation:

  • entity - Description of the entity to be updated including the entity identifier.

For unregistering entities such as stores or market participants from the marketplace, the Unregister Entry operation will be used. Unregistering an entity from the Marketplace means that this entity gets flagged as unregistered and not further considered for the marketplace operation. So, complete deletion is not possible due to consistency and history-preservation reasons. The following parameter is required:

  • entity - Entity to be unregistered from the marketplace registry.

Offering & Demand (mandatory)

Offerings are retrieved from various sources (actually mainly stores, but other sources would be also allowed). So one of the operations is to ask a registered store for actual offerings. The following diagram shows an example sequence of offering management on a marketplace.

Example sequence of offering management operations

The Create Offering operation can be used to actively push a new service offering from a registered store into a marketplace. This operation returns the identifier of the published offering. The following parameters need to be exchanged:

  • service identifier - Identifier of the service to be offered / link to a USDL service description.
  • pricing model - Pricing model for the service/app.
  • classification - Optional - Classification of the offering, e.g. name of a category the offering belongs to

The Update Offering operation can be used to update an already published offering on the marketplace. The old offering information gets versioned on the marketplace. This operation returns an OK status result on success or a parameter allowing to identify the reason for fault for further exception handling. The following parameters need to be exchanged:

  • offering identifier - Identifier of the offering.
  • service identifier - Identifier of the service to be offered / link to a USDL service description.
  • pricing model - New or updated pricing model for the service/app.
  • classification - Optional - Classification of the offering.

In order to withdraw or end a concrete offering from the marketplace the End Offering operation is used. A complete deletion is not possible due to dependency and history reasons. The following parameters are exchanged:

  • offering identifier - Identifier of the offering.

This operation returns an OK status result on success or a parameter allowing to identify the reason for fault for further exception handling.

The Get Offering operation can be used to retrieve an offering from the marketplace. This operation delivers the actual offering data, such as pricing information, service description, associated store, and the offering classification. The following parameters need to be exchanged:

  • offering identifier - Identifier of the offering.
  • version - Optional parameter. If not set, the latest version of the requested offering is returned

The Get Offering History operation can be used to retrieve the history of an offering from the marketplace. This operation delivers a list of all version IDs and dates of an offering. The following parameters need to be exchanged:

  • offering identifier - Identifier of the offering.

The List Offerings for a Store operation can be used to retrieve all offerings from a specific store that is registered of the marketplace. For practical reasons it might be useful to restrict the list of offerings by specifying the number of results and the starting offset. The following parameters need to be exchanged:

  • store Identifier - Identifier of the store.
  • filter - Optional filter expression to reduce the number of delivered results.
  • offset - Index of the first offering to be returned.
  • max - Maximal number of results to be returned.

Discovery & Matching (mandatory)

The Discovery and Matching component supports primarily customers in finding offerings and stores matching their needs. The following diagram shows an example sequence of a marketplace user (a) searching and comparing offerings as well as a second user (b) searching for stores.

Example sequence of discovery and matching operations

The Free Text Search operation can be used to search the marketplace for offerings using a search string with wildcards and filters. This operation delivers a list of all offerings which matches the specified search term and filter constraints. The following parameters can be involved in the operation:

  • search string - Search string, potentially with wildcard operators.
  • filter - Optional - Filter expression to reduce the number of delivered results.
  • offset - Optional - Index of the first offering to be returned.
  • max - Optional - Maximal number of results to be returned.
  • page size - Optional - Number of results per page.
  • sort by - Optional - List of sort options, sorted by application order.

The Get Filter Options operation can be used to get the possible filter options for a free text search. There might exist some filter options which are specific to a certain classification category. If the classification input parameters is set, a list of these specific filter parameters gets returned.

  • classification - Optional parameter to get filter options for offerings associated with the specified classification.

Sort options are used to define the order of an offering result list. The Get Sort Options (optional) operation returns a list of possible sort options for a list of offerings. If a classification category is specified in the request, category specific sort options get returned. The optional parameter for category specific sort options is:

  • classification category - Optional parameter to get filter options for offerings associated with the specified classification.

To get a comparison of pricing models and USDL service descriptions among offerings the Compare Offerings (optional) operation is used. An optional filter expression can be used to reduce the number of delivered results. The parameters for this operation are:

  • offering list - List of offerings
  • filter - Optional - Filter expression to reduce the number of delivered results.
  • offset - Optional - Index of the first offering to be returned.
  • max - Optional - number of results to be returned.

The Store Search operation enables a client to search a marketplace for registered stores using a search string with wildcards and filters. A list of stores matching the search string as well as the specified filter criteria is returned.

  • search string - Search string, potentially with wildcard operators
  • filter - Optional - Filter expression to reduce the number of delivered results.
  • offset - Optional - Index of the first store to be returned.
  • max - Optional - Maximal number of results to be returned.

Review and Rating (optional)

The Review and Rating component allows users of the marketplace to retrieve and create textual and star-rating feedback for rate-able entities such as stores and services. An example sequence of marketplace users creating and retrieving ratings is illustrated below.

Review and Rating Example sequence

To get the average rating for a store, a service or any other rate-able entity on the marketplace the Get Rating operation is used. This operation delivers the average ratings for a rate-able entity by means of different rating categories as well as an overall average rating. The following parameters need to be exchanged:

  • identifier - Identifier of a store or a user or any other rate-able entity

The Get Ratings operation delivers the details of ratings for a rate-able entity. Filter expressions are supported to reduce the number of results. If no filter expression is given then all ratings for the specified entity instance are returned.

  • identifier - Identifier of a store or a service or any other rate-able entity
  • filter - Optional filter expression to reduce the number of delivered results.
  • offset - Index of the first rating to be returned.
  • max - Maximal number of results to be returned.

In order to retrieve a list of textual reviews for a rate-able entity the Get textual Reviews operation is used. It also supports filter expressions as well as limits and offsets. The following parameters are available for this operation:

  • identifier - Identifier of a store or a user.
  • filter - Optional filter expression to reduce the number of delivered results.
  • offset - Index of the first reviews to be returned.
  • max - Maximal number of results to be returned.

The Create Rating operation is used to persist a new rating for an entity in the marketplace. This operation returns the identifier of the new rating as result. To get the available rating categories for a rate-able entity use the later-described Get Rating Categories operation beforehand. The following parameter needs to be exchanged:

  • rating - Rating entry which includes a rating value for each mandatory rating category as well as a link to the rate-able entity instance

To get the available rating categories for a rate-able entity the Get Rating Categories is used. It returns a list of available rating categories for the specified service, store, or any other rate-able entity instance. The following parameter has to be provided:

  • identifier - Identifier of a rate-able entity instance.

The Create textual Review creates a textual review for an entity instance that is flagged as rate-able. It returns the identifier of the created review as result. As input parameter, the textual review is sufficient:

  • review - Review entry which includes the textual review and an the identifier of the rate-able entity instance.

Recommendation (optional)

The Recommendation component supports users in finding services matching their needs based on user specific data. The following diagram outlines an example sequence of a user retrieving recommendations.

Example sequence of recommendation operations

To retrieve a list of recommendations for a user the Get Recommendations based on User Profile operation is used. Recommendations might be based on the users’ profile, browsing behaviour, order history and other user specific data. This operation returns a list of recommended services till the specified limit. The following parameters need to be provided:

  • user identifier - Identifier of a user
  • max - Optional - Maximal number of results to be returned.

The Get Customer who were interested in X also were interested in Y Recommendations returns a list of services that were often bought together with the a given service. The supported parameters for this operation are:

  • user identifier - Identifier of a service
  • max - Optional - Maximal number of results to be returned.

To get the top rated services on the marketplace as a whole or the top rated services for a certain classification category the Get Top Rated Services is used. The following parameters are supported:

  • classification category - Optional parameter to get the top rated services for a certain classification category.
  • max - Optional - Maximal number of results to be returned.

Basic Design Principles

  • API Technology Independence

The Marketplace API is independent from implementation technology.

  • Interoperability and flexible use through HTTP content negotiation

As described in the architecture, the Marketplace offers different interfaces in order to satisfy users' need to discover, compare, create, and update offerings. The Marketplace determines the right representation from information provided in the users’ header data, so a client can receive the best representation for its abilities.

  • Multiple store support

The Marketplace GE is not limited to interact with one specific store. It supports multiple decoupled stores as long as they implement the marketplace interfaces for Registry and Offering & Demand.

Detailed Specifications

Documentation here:

Re-utilised Technologies/Specifications

The Marketplace 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

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