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

FIWARE.OpenSpecification.Apps.Store

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Apps.Store
Chapter Apps,
Catalogue-Link to Implementation WStore
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 © 2012 - 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.

Note: UPM provides software associated to the Store specification under an EUPL v1.1. Please check the specific terms and conditions linked to this EUPL v1.1 open source license at https://github.com/conwetlab/wstore/blob/develop/LICENSE.txt

Overview

The Store GE is part of the FIWARE Business Framework. The Store GE is mainly responsible for managing offerings and sales: it supports the publication of new offerings, manages offering payment, provides access to all purchased services and provides software downloads if the offering is part of a downloadable service (e.g. applications, widgets, etc.)

The resulting features constitute a list of the requirements that the Store GE will have to satisfy. They are defined below.

  • The Store GE is responsible for managing service offerings. To do this, it supports the registration of offerings published by an aggregator and may update one or more Marketplace GEs to enter a new offering, which is linked to the Store GE. Additionally, it registers the information about the offering by storing the business model of the service represented as a Linked USDL document in the Repository GE.
  • As there is no generic enabler that stores code, the Store GE will offer an endpoint from which it will be possible to download any resources that are part of a purchased and downloadable service. To do this, the Store GE defines an API to be implemented by the service provider. This API will be used as a mean for indirectly downloading the resources associated with the offering. Service providers that do not have an application server can also upload these resources to the Store GE.
  • The Store GE will offer a web portal for visualizing, searching and purchasing offerings, although the Marketplace GE can be used to search and compare offers published in different Store GEs.
  • When a customer decides to purchase an offering either via the Store GE web portal or by searching a Marketplace GE, the Store GE will manage offering payment, will contact the service provider to notify her the purchase of the offering, and will make sure that the customer is either given access to the web service or able to download the necessary downloadable service resources as specified above. Additionally, the Store GE defines an implementable API for downloadable services purchased via a client program that automatically adds the service resources to the client system. A possible example of this functionality would be the purchase of widgets via the Mashup Application GE.

Basic Concepts

User model and roles

Taking into account the different functionalities provided by Store GE, it is necessary to define a model that controls the privileges and possible interactions of Store GE users. Note that the Identity Management GE will maintain information about users and roles in the FIWARE platform. Therefore, the Store GE will rely on the Identity Management GE to manage users and roles.

The Store GE is based on the concept of organization. An organization will be managed like a user group. In this regard, some offerings may be acquired by the user purchasing the offering and be accessible to all users within an organization. Just as an organization has more than one member user, one and the same user may be a member of more than one organization and may have several offerings purchased at each organization. In the Store GE, offerings are considered to be published by an organization rather than an individual user, and users cannot publish an offering unless they are acting on behalf of an organization. This is not, however, incompatible with membership of other organizations. As mentioned above, the Identity Management GE will manage organizations.

Note that users must have at least one and may have any number of roles. The user roles defined depending on the privileges and possible interactions with the Store GE are as follows:

  • Admin: This role is responsible for system administration. System administration includes database administration, as well as the registration of instances of the Repository GE for storing the models of offered services in the Store GE and instances of the Revenue Settlement and Sharing System GE for performing the distribution of the generated revenues between the stakeholders involved in an offering. It is also responsible for registering the instance of the Store GE in the instances of Marketplace GEs in which the registered offers are to be published.
  • Provider: This role has the option of publishing service offerings, which, as mentioned above, will be offered by the organization on behalf of which the provider is acting at the time of publication.
  • Customer: This role has the option of purchasing an offering that may or may not become part of the services purchased by any of the organizations of which the customer is a member.
  • Developer: This role has the option of purchasing an offering that define a special price plan for developers that may include a revenue sharing model between the provider and the customer.

Note at this point that no role has been defined with respect to organizations. Likewise, the Identity Management GE, not the Store GE, is responsible for managing which role a user plays on behalf of a particular organization. It will simply notify the Store GE of the role that users are playing at any time and on behalf of which organization they are acting.

Store Architecture

Figure below shows the Store GE architecture, which is divided into a series of functional modules, as well as the relationships between the Store GE and other generic enablers. Users will be able to use the Store GE via its web portal while other enablers and final application and services will be able to contact the defined Store API to manage and purchase offerings previously discovered in the Marketplace GE. The diagram also illustrates the connection with the Application Mashup GE, which will use the Store GE to purchase the different web components that it uses to compose the mashups and to publish the resulting composite mashups. The Store GE will also connect to the Marketplace GE, which it will use to register any new offerings that have been published, and to the Repository GE in order to store the USDL documents describing these offerings and their associated documents (WSDL, WADL, etc.).Moreover, the Store GE will also connect to the Revenue Settlement and Sharing System GE that will be used to divide the purchased offering payments among their respective stakeholders. Finally, the Store GE relies on the Identity management GE in order to obtain users', organizations, and roles. The Store GE also obtains from the Identity Management GE information about the different applications registered by the users and organizations for access control. See the Identity management user guide for more information on this topic.

Store GE architecture

As shown in the figure above, the Store GE is divided into modules. Each module has a specific functionality and is connected to the other modules and external systems. The functionality that each module should provide is detailed below.

The Marketplace Interface module is responsible for communication with the Marketplace GE in order to register and remove the Store GE instance, as well as register and remove published offerings. This module will communicate with both the Offering module, responsible for registering offers, and the Administration module, which will register the Store GE instance.

The Repository Interface module is responsible for communicating with the Repository GE in order to both upload and download USDL documents associated with the published offerings. This module will communicate with the Offering module in order to get the USDL documents and with the Contracting module in order to send requests to download USDL documents.

The IdM interface module is responsible for communicating with the Identity Management GE in order to obtain information about users and organizations, as well as the different roles of those users. This module is also in charge of obtaining applications registered for access control in the identity management GE in order to include those applications as part of an offering, allowing customers to be granted real access to those services when they purchase the offering.

The Administration module is used by users with the Admin role to manage the Store GE and to register the Store GE instance in the instances of the Marketplace GE. This module reads and writes to all data models and contacts the Marketplace GE module in order to register the Store GE.

The Offering module is used to manage user-specific offerings. This module manages the provider offerings, i.e. it creates new offerings, publishes new resources, links resources to offerings and publishes and puts offerings up for sale. This module is also responsible for purchased offerings and gives consumers access to the information on these offerings and their linked resources. This module reads and writes from the Resource and Offering models and reads from the Marketplace and Repository models to get the information required to publish the new offerings. Additionally, this module contacts the Marketplace Interface module to send requests to manage the different offerings that are published in the Marketplace GE. It also communicates with the Repository Interface module, which it uses to upload and download the USDL descriptions of the different user offerings. This module also contacts the User Manager module, which it uses to manage the roles of the users sending the requests. Finally, this module contacts the IdM interface module in order to obtain information about the applications registered in the Identity management GE that can be included in an offering.

The User Manager module is responsible for managing users by supervising the different roles and privileges in order to control access to different functionalities of the Store GE. This module reads and writes to the user model and is contacted by all the modules that are accessible from outside the Store GE, that is, by the Offering, Search and Contracting modules. This module gets user information and roles from the idM interface.

The Contracting module is responsible for managing subscriptions and purchases of the different offerings published in the Store GE. This module will contact different payment gateways, receive payment confirmation, give access to the service and pass on the payment information (CDRs) to the Revenue Sharing System GE. This module will also be responsible for renewing services governed by a subscription payment model. (If service subscription is possible from outside the Store GE, then the consumer will have to explicitly notify the Store GE of subscription renewal via the purchases API.) This module will also be responsible displaying purchase information to users. In case the pricing model comprises pay-per-use models, an external accounting component will provide service use information (SDRs) to the Store GE in order to calculate the amount to be charged. The Store GE accepts no responsibility for the validity of the information offered by the service provider. However, this module will enable users to lodge formal complaints about purchased services. Additionally, the Contracting module is contacted by the Search module when users want to purchase a service that they have discovered in the Store GE, and it contacts the Repository Interface module to get the descriptions of the Repository GE offerings. This module contacts the payment gateway, notify service providers, and sends information on payments to the Revenue Sharing System GE for distribution among stakeholders. Finally, this module contacts the idM interface module, which uses to notify the Identity management GE that a customer has been granted the access to an application due to a purchase of an offering that includes it.

Finally, the Search module is responsible for searching published offerings depending on parameters and filters provided by users. This module reads from the Offering and Resource models in order to get the information required for searches and contacts the Contracting module in order to enable users to purchase an offering that they have discovered.

Data Model

Note firstly that the data model divides the concept of service offering. In order to manage this concept, the Store GE operates with the Offering model that represents the abstract entity of an offering including pricing, legal or service-level information. However, the Store GE also uses the Resource model that represents real components offered, such as an application or a widget.


File:Store_E-R.png
Store GE data model


The figure above shows the overall data model defined in the Store GE as an entity-relationship diagram containing the main entities on which the Store GE is based and the relationships between these entities. Below we detail the contents of these entities and the information that they should each contain.

  • Offering: This model contains information about the offerings registered in the Store GE.
    • Name: This attribute will represent the name that the provider gives to the offering.
    • Version: This attribute will contain the version of the offering.
    • Owner organization: This attribute will contain the name of the organization that owns the offering.
    • State: This attribute will represent the life-cycle state of the offering from the viewpoint of the provider.
    • URL model: This attribute will contain the link to the USDL offering description stored in an instance of the Repository GE.
    • Rating: This attribute will contain the mean score assigned by different users that have given their opinion on the offering.
    • Applications: This attribute will contain information about the Identity Management GE applications included in the offering.
    • TAGs: This attribute will contain a series of tags used to classify the offering.
    • Image: This attribute will contain the graphical image associated with the offering.
    • Related images: This attribute will contain a series of graphical images related to the service, such as screenshots, diagrams, etc.
    • Is open: This attribute will specify whether the offering can be accessed without the need of acquiring it.
    • USDL information: This attribute will contain the same information as the USDL document stored in an instance of the Repository GE and will be used to access the information on the offering and the business model without having to constantly contact the instance of the Repository GE.

Note importantly that the Offering model should contain a unique combination of the Owner Organization, Name and Version attributes, as these three attributes will be used to identify the offering. This assures that two offerings owned by two different organizations will have different names and allows one and the same organization to have two different versions of the same offering. Note that the service provider’s name is not used to identify the offering, as it is the organization that is considered to make the offerings.

  • Resource: This model contains information about the different resources that have been registered in the Store GE to be linked to an offering.
    • Name: This attribute will represent the name that the service provider gives to the resource.
    • Version: This attribute will represent the version of the resource.
    • State: This attribute will contain the state of the resource specifying whether it is active. This attribute will be used mainly if the resource provider decides to delete a resource and this is already part of a published offering or has even purchased by a consumer. In this case, the resource will be simply marked as deleted, because it will have to remain accessible and cannot be removed.
    • Mime type: This attribute specifies the type of the resource to be downloaded.
    • Download link: This attribute will contain the information necessary to access the resource. It will contain the download link.
    • Description: This attribute will contain a resource description.

Note that the resources in the Store GE will be identified using the resource provider name, the Name attribute and the Version attribute. Therefore, the combination of these three elements has to be unique.

  • Resource Type: This model contains information about the different types of resources that can be managed by the Store GE. This model is used in order to allow the Store GE to support the selling of different types of digital assets such as widgets, datasets, etc.
    • Name: This attribute represents the name that the system admin has given to the resource type.
    • Version: This attribute represents the current version of the resource type.
    • Media types: This attribute represents the allowed media types for the different resources of the resource type.
    • Formats: This attribute represents the allowed formats (API or file) for the different resources of the resource type.
  • User: This model will contain the Store GE user information that is not necessarily managed by the Identity Management GE.
    • User Name: This attribute will contain the user name that identifies the user.
    • Name: This attribute will contain the user’s full name.
    • Organizations: This attribute will contain the organizations of which the user is a member.
    • Roles: This attribute will contain the current roles played by the user depending on the current organization.
    • Current organization: This attribute will contain the organization the user is acting on behalf.
    • Default Tax Address: This attribute will contain the default tax address provided by the user.
  • Organization: this model will contain the Store GE organizations information that is not necessarily managed by the Identity Management GE.
    • Name: This attribute will contain the name of the organization.
    • Private: This boolean attribute specifies whether this organization is a private organization, that is, an organization owned by a single user.
    • Default tax address: This attribute will contain the default tax address provided by the organization.
  • Purchase: This relationship will contain information about the purchases made via the Store GE including some attributes.
    • Reference: This attribute will contain the purchase reference and will be used to identify the purchase.
    • Date: This attribute will contain the date on which the purchase was made.
    • State: This attribute will contain the state of the purchase, specifying whether or not payment has been made.
    • Bills: This attribute will contain the different invoice references generated when charging are made.
    • Tax Address: This attribute will contain the effective tax address used by the user that purchases the offering.
    • Contract: This attribute will contain information about the concrete contract that applies to the purchase, including the pricing models, renovation dates, etc.
  • Marketplace: This model will contain the information on the instances of the Marketplace GE in which the instance of the Store GE has been registered for the purpose of providers selecting the Marketplace GE in which their offering is to be published.
    • Name: This attribute will contain the name that the administrator responsible for having registered the instance of the Store GE gives to the instance of the Marketplace GE.
    • Host: This attribute will contain the Endpoint of the instance of the Marketplace GE in which the instance of the Store GE has been registered.
  • Repository: This model will contain information on instances of the Repository GE that have been registered in the instance of the Store GE for the purpose of selecting which instances of the Repository GE are to store the USDL documents that describe the service.
    • Name: This attribute will contain the name that the administrator responsible for having registered the instance of the Repository GE gives to this instance.
    • Host: This attribute will contain the Endpoint of the instance of the Repository GE registered in the instance of the Store GE.
  • RSS: This model will contain information on instances of the Revenue Settlement and Sharing System GE that have been registered in the instance of the Store GE in order to perform the distribution of the generated revenues between the stakeholders of the published offerings.
    • Name: This attribute will contain the name that the administrator responsible for having registered the instance of the RSS GE gives to this instance.
    • Host: This attribute will contain the Endpoint of the instance of the RSS GE registered in the instance of the Store GE
    • Expenditure Limits: This attribute will contain the default expenditure limits registered in the RSS GE instance.
    • Correlation Number: This attribute will contain the current correlation number for CDRs expected by the instance of the RSS GE.
    • Pending CDRs: This attribute will contain a list of CDRs that are pending to be gathered by the RSS GE instance.
  • Review: This model will contain information on reviews made by users about different offerings.
    • Comment: This attribute will contain the comment made by the user about the offering.
    • Date: This attribute will contain the date on which the review was made.
    • Rating value: This attribute will contain the score assigned to the offering by the user.
  • Reply: This model will contain information on replies made by offering owners to reviews.
    • Comment: This attribute will contain the comment made by the user about the review.
    • Date: This attribute will contain the date on which the reply was made.

Offering Life Cycle

In order to specify all the different offering states in the Store GE, it is necessary to show the life cycle of an offering from two different viewpoints: the offering provider and the offering consumer.

Offering life cycle from provider viewpoint

The figure above shows all the possible offering states from the viewpoint of the provider. First, the service provider creates the offering, whose state will be Uploaded. An Uploaded offering is still not up for sale, and is visible only to the user who created it, so the provider can register any number of resources in the Store GE without having to modify an offering that might have been purchased. The information associated with the Uploaded offering is editable, and the USDL document that defines the information about it can be modified. The offering moves to the Bound state when resources are linked to an offering. The offering will be Bound for as long as it is not put up for sale and it is linked with resources. If all the resources of the offering are unlinked, it will return to the Uploaded state. When the provider decides to put the offering up for sale, it moves to the Published state. This is when the Store GE registers the offering in the Marketplace GE specified by the provider. Note that a Published offering is no longer editable, nor is it possible to modify the information of the USDL document, or link or unlink resources. If the service provider wishes to modify information about a Published offering, a new offering has to be created. This means that there might be multiple offerings linked to a given service, both in parallel and over time (in this latter case working like versioning). Finally, the service provider can delete the offering at any time. However, this action will have different effects depending on the state of the offering. If the offering has not yet been put up for sale, that is, it is Uploaded or Bound, the offering is simply removed from the Store GE as it is available to the provider only. If the offering state is Published, it moves to the Deleted state and is no longer visible to future buyers. Note that any buyers that have already purchased the offering would still have access to its resources.

The figure below this paragraph shows all the possible offering states from the viewpoint of the consumer. Published is the first state of an offering from the viewpoint of a consumer. In this state, consumers can view all the information associated with the offering, which they use to decide whether or not to purchase it. An offering that a consumer decides to purchase moves to the Purchased state. This state indicates that the consumer has purchased the offering. If the purchased service requires configuration before use, the consumer will have the option of deciding when to do the configuration. This will move the offering to the Configurable state. Offerings of services that do not require configuration will move directly to the Accessible state. An offering will likewise move to this state after configuration. In the Accessible state, the purchasing process is complete, and the consumer can access or download the resources associated with the offering depending on the type of service that is being offered. Finally, a service that consumers no longer require, for example, a subscription service to which they no longer want to subscribe, will return to the Published state and can be repurchased by a consumer.

Offering life cycle from consumer viewpoint

Charging

The Store GE is responsible for charging customers depending on the pricing model defined in the USDL document that describes the offering. The Store GE supports charging based on three main pricing models:

  • Single payment: Defines a charge that is made once. In this case the Store GE charges the customer at the time of purchasing
  • Subscription: Defines a periodic charge. In this case the Store GE makes the first charge at the time of purchasing and then waits for an explicit renewal.
  • Pay-per-use: Defines a charge that depends on the use that the customer makes of the offered service. In this case the Store GE does not charge the customer at purchasing time, but receives service usage information from an external accounting component included in an SDR document (described below). It is necessary to take into account that different types of pay-per-use models exists. The Store GE supports pay-per-use based on events (i.e. invocations, sessions, etc.), pay-per-use based on time (i.e. seconds, minutes, etc.), and pay-per-use based on quantity (i.e. Megabytes, CPU instructions, etc.).

These pricing models can be arbitrarily combined in the USDL document (as price components) to create complex pricing models. Moreover, pay-per-use models can be specified as price functions that depend on more than one usage parameter. It is also possible to include usage-based discounts using the syntax defined in the Linked USDL specification.

Service detailed record

The Service Detailed Record (SDR) contains information related to the use that the customer has made of a concrete service offered in a purchased service offering. The SDR documents are sent to the Store GE, using the provided push-oriented API, by an external accounting component every time the service is used in order to allow the customer to know the consumption done so far. This document is used by the Store GE to calculate the amount to be charged in pay-per-use models. The SDR contains the following fields:

  • Offering identification: This field must include the needed information to identify the offering that offers the service in use. That includes the organization that owns the offerings, the offering name and the offering version.
  • Customer: The user that is going to be charged.
  • TimeStamp: Date and time in the moment of sending.
  • VariableLabel: Identifier of the usage variable or price component included in the USDL document.
  • Correlation number: Sequence number.
  • RecordType: Type of pay-per-use that has been monitored (i.e. event, time, and quantity).
  • Unit: Unit of the included value (i.e. seconds in a pay-per-use time or Megabytes in a pay-per-use quantity).
  • Value: Use that has been made of the service (i.e. number of seconds, number of invocations, etc.).
  • Additional info: Any info that the accounting component wants to include.

Example Scenarios

This section describes the operation of the Store GE from the viewpoint of users, without taking into account the interactions between different Generic Enablers. To do this, we propose some specific use cases that refer to prospective real interactions of Store GE users from both the Store GE web portal and from other Generic Enablers that use the Store GE RESTful API.


Creating and publishing offerings

This use case describes the process that service providers would enact from when they decide to put a new service up for sale until the service is published in the Marketplace GE instance. To illustrate how the Store GE can be combined with other FIWARE GEs and illustrate the concept of downloadable resources associated to an offering, we will define a use case where the user playing the Provider role has created a new Mashup using the Application Mashup GE. In this case, the offering to be published will have a set of downloadable resources linked to the different Widgets linked to the mashup. Additionally, the Store GE will be accessed from the Web portal provided by the Application Mashup GE.

First, the user will compose the Mashup using the tools provided by the Application Mashup GE. The user will then create a USDL document describing all the relevant information about the service that he or she is going to put up for sale, including basic service information (name, date last modified, etc.), pricing information, terms and conditions of use and service-level information. The user can then create the offering attaching images related to the service such as diagrams or screenshots of the mashup in action, as well as a service icon. Note that at this point the offering has been created but is still not up for sale and is only visible to its creator. The next step will be to register the created resource (Mashup code) within the Store GE. During this step, the provider can either offer a URL from which this resource can be downloaded or upload the resource directly to the Store GE specifying that it is a downloadable resource. The next step will be to link the offering and the resource, thereby identifying the specific code that is being offered. Finally, the user will put the offering up for sale, specifying the instances of the Marketplace GE in which the offering is to be published.

Searching and purchasing offerings

This use case describes the process that a user playing the Customer role would enact as of when he or she searches offerings via the web portal provided by the Store GE to when he or she purchases an offering. In this use case, the user is assumed to be using the Store GE web portal to purchase an offering that requires an initial subscription payment. Additionally, the user is assumed to have rights to purchase offerings for his or her entire organization.

First the user will login to the FIWARE platform. This will identify the user, as well as the organization of which he or she is a member, within the Store GE. The logged in user will access the Store GE web portal and select the advanced search option. This way, he or she will be able to filter the search by the type of resources associated with the offering. The search will return a series of offerings that meet the requested parameters, and the user will select the one that best satisfies his or her needs and preferences. When the user has decided which offering to purchase, he or she will select the option to purchase the offering for the entire organization. The Store GE will then request the information necessary to make the payment (account number, card number, PayPal account, etc.). After payment confirmation, the Store GE will download the transaction invoice and reroute the user to the service provider to get access credentials from the provider. When this process is complete, this offering and its associated resources will be part of the offerings owned by all the users of the organization from where they will be able to download the invoice and get access credentials.

Main Interactions

Interaction diagrams

This section details the main interactions among the different Generic Enablers and Store GE in order to illustrate how the Store GE fits into the existing FIWARE platform architecture and the main functionality that it provides for other Generic Enablers.

Creating an offering

The next figure shows the interactions required to create a new offering within the Store GE.

Creating an offering

It the diagram above can be seen how in a previous step the Store GE retrieves the existing revenue sharing model from the RSS GE. This allows the service provider to choose the revenue sharing model that will be used to distribute the revenues generated by the offering being created. Then, it shows how just one request is required to create a new offering. This request provides the offering information, which will be composed of the USDL description of the offering, as well as a series of images related to the offering and the offering icon. The Store GE receives the request to create the new offering and then requests the Repository GE to store the USDL document, getting a URL that points to the resource and will be used later to access this document and register the offering in the Marketplace GE.

It is also possible to create an offering whose USDL description has been previously uploaded to the Repository GE by the service provider. In that case, the request contains the URL to the USDL description that is used by the Store GE to obtain the offering information. These interactions are shown in the following diagram:

Creating an offering using USDL URL

Adding and linking a resource

The figure below shows the interactions required to register and link a new resource. In this diagram, the user is assumed to be using the Store GE web portal.

Registering and linking a resource

It illustrates that registering and linking a resource to an offering are simple operations composed of a single request. The request to create the resource will include the resource name, version description, resource type and resource access information, which could be an Endpoint for an API access resource, or a download link or the actual resource for a downloadable resource. On the other hand, the request to link the resource to an offering will include first the information identifying the resource, that is, the provider name, the resource name and the resource version and second the information identifying the offering, that is, the organization to which it belongs, the offering name and the offering version.

Publishing an offering

The figure below shows the interactions required to publish an offering that has been created in the Store GE in an instance of a Marketplace GE. In this diagram, the user is assumed to be using the Store GE web portal.

Publishing an offering

It shows how an offering is published using a Store GE request. This request will contain first the information required to identify the offering, that is, the organization to which it belongs, its name and its version. It will also contain a list of instances of the Marketplace GE in which the offering is to be published. These instances will be identified by the name that they were given by the administrator when he or she registered the instance of the Store GE. Finally, the Store GE receives the request to publish the offering and contacts the Marketplace GE Registry & Directory service, which will contain the offering name and the URL of its USDL description stored in an instance of the Repository GE.

Removing an offering

The figure below shows the interactions required to remove an offering created in the Store GE and published in a Marketplace GE. The user is assumed to be using the Store GE web portal.

Removing an offering

It shows how an offering is removed by means of a Store GE request. This request will contain the information required to identify the offering, that is, the organization to which it belongs, its name and its version. The Store GE receives the request to remove the offering and will first contact the instances of the Marketplace GE publishing the offering, instructing them to remove the offering. The offerings are identified in the Marketplace GE by their name only, and this will be the only information that these requests contain. After the offering has been removed from the instances of the Marketplace GE, the Store GE will contact the different instances of the Repository GE (using the URL contained in the USDL document) to remove this description.

Searching the Marketplace GE and purchasing an offering

The figure below shows the interactions that take place when searching the Marketplace GE for offerings and purchasing an offering. These interactions consider that the offering is based on a series of downloadable resources registered in the Store GE and a price plan based on single payments. In the diagram, the search and purchase operations are assumed to be performed from the Application Mashup GE.

File:Get_offering_market.png
Searching the Marketplace GE and purchasing an offering

It shows how the Application Mashup GE sends a request to the Marketplace GE Search & Discovery service, which contains a series of filters to constrain the search. The Marketplace GE will return the available information on a series of offerings, namely the offering name and the URL of the USDL descriptions. The Application Mashup GE will then use the information returned by the search operation to download and visualize the USDL descriptions of the offerings, enabling the user to select an offering. When the user has decided which offering to purchase, the Application Mashup GE sends a request to the Store GE containing the information identifying the offering, that is, the URL of its description (the information available in the Marketplace GE), and the payment information (account number, card number, PayPal account, etc.). The Store GE receives the purchase request and checks with the RSS GE that the customer has enough balance to perform the transaction. Once the Store GE receives the confirmation from the RSS GE, it immediately contacts the respective payment gateway, dealing with the payment. The Store GE receives the payment confirmation and updates the balance of the customer in the RSS GE. Then, contacts and notifies the service provider of the purchase. It uses the resource download links to get the resources. Next, the Store GE sends the purchase invoice, along with the associated resources, to the Application Mashup GE. Finally, the Store GE feeds the RSS GE with a CDR document containing the payment information (see RSS Open Spec). This information is used by the RSS GE to compute the Revenue Sharing.

Searching the Store GE and purchasing an offering

The figure below shows the interactions that take place when searching the Store GE for an offering with subscription resources and purchasing the offering. The scenario assumes that the offering is based on a series of services (there is no need to download components, as they are accessible via API). In this diagram, the user is assumed to be using the Store GE web portal.

Searching the Store GE and purchasing an offering

It shows how to send a Store GE search request, passing a series of parameters to constrain the search. In response, the Store GE will return a list of offerings that satisfy the searching criteria. When the user decides to purchase an offering, a purchase request will be sent to the Store GE including the information necessary to identify the offering, that is, the organization, name and version, and the necessary payment information (account number, card number, PayPal account, etc.). The Store GE receives the purchase request and contacts the Repository GE using the URL of the description of the selected offering to download the USDL document and check the information on offering pricing. Then, the Store GE checks with the RSS GE if the user has enough balance to perform the transaction. Once the Store GE receives the confirmation, it will bill the customer by contacting the respective customer payment gateway, using the previously accessed pricing information. The Store GE receives customer payment confirmation and updates the customer balance in the RSS GE. Next, the Store GE contacts and notifies the service provider that a user or organization now has acquired access to use the application or service APIs associated to the offering resources. Then, the Store GE will send the purchase invoice. Finally, the Store GE feeds the RSS GE with a CDR document containing the payment information.

Feeding the Store GE with accounting information

The figure below shows the interactions that take place when feeding the Store GE with accounting information related to the use of a service whose offering implied a pay-per-use pricing model. This figure shows also the interactions that would take place periodically to charge the customer. It is assumed that the accounting information is provided by an accounting component, which can be any component in charge of monitoring the use of services.

Feeding the Store GE with accounting info

It shows how the Accounting component feeds the Store GE with a SDR document. This SDR document contains the accounting information for an offering. When the SDR is received, the Store GE calculates the charge associated with that document and stores the generated info. Periodically, the Store GE aggregates the charging info and computes the total amount to be charged to a customer. Then, the Store GE bills the customer by contacting the respective customer payment gateway. For making this payment, the Store GE uses the billing information contained in the customer profile. The Store GE receives the billing confirmation and feeds the RSS GE with a CDR document containing the aforementioned billing information, which will be taken into account for payment of providers.

Basic 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 Store GE
HTML5, CSS and JavaScript must be used to fully exploit the brand new Web applications capabilities.


Re-utilised Technologies/Specifications

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