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.ArchitectureDescription.Apps.Marketplace R3 - FIWARE Forge Wiki

FIWARE.ArchitectureDescription.Apps.Marketplace R3

From FIWARE Forge Wiki

Jump to: navigation, search

Contents

FIWARE WIKI editorial remark:
This page corresponds to Release 3 of FIWARE. The latest version associated to the latest Release is linked from FIWARE Architecture

Copyright

  • Copyright © 2014 by SAP

Legal Notice

Please check the following FI-WARE Open Specification Legal Notice (essential patents license) to understand the rights to use this open specification. As all other FI-WARE members, SAP has chosen one of the two FI-WARE license schemes for open specifications.

To illustrate this open specification license from our SAP perspective:

  • SAP provides the specifications of this Generic Enabler 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 (SAP) 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 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/service-business-framework/Marketplace-RI/blob/master/license.txt. You can also obtain the Marketplace GE and Pricing Simulation Decision Support software using the FI-WARE Catalogue at http://catalogue.fi-ware.org/enablers/marketplace-sap-ri

Overview

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 FI-WARE 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.

Some characteristics of the pricing decision process – especially its complex role in regulating economic interactions between autonomous market agents – make it an ideal candidate to be investigated by means of a simulation approach called Agent-Based Modeling and Simulation (ABMS). Using the Pricing Simulator Decision Support feature set of the marketplace GE, simulation experiments based on the ABMS approach can be conducted to support important business decisions, such as selecting an optimal price level or determining a balanced combination of price and product configuration (i.e., offering the right value, in terms of attributes and characteristics of the offered software product or service, for the money customers must spend in acquiring it).


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 FI-WARE 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, Google Android Market, and Nokia Ovi, 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. FI-WARE 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
  • Registry acts as a universal directory of information used for the maintenance, administration, deployment and retrieval of services. It will be used to store information necessary for service run-time execution.
  • 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 & Directory, Offering & Demand, Discovery & Matching, Recommendation, and the Review and Rating component. The optional Pricing Simulator Decision Support feature set of the marketplace GE is also described in this document.

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.

Recommendation

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.

Pricing Support

The optional Pricing Simulator Decision Support feature set of the marketplace GE supports the decision-making processes involved in the pricing choices a service provider in the FI-WARE environment must make for its offerings.

Marketplace Architecture

The Marketplace GE is used by other GEs within the FI-WARE 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. FI-WARE 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 FI-WARE 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 a 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.
  • index - Index of the first offering to be returned.
  • limit - 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.
  • index - Optional - Index of the first offering to be returned.
  • limit - 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.
  • index - Optional - Index of the first offering to be returned.
  • limit - 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.
  • index - Optional - Index of the first store to be returned.
  • limit - 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.
  • index - Index of the first rating to be returned.
  • limit - 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.
  • index - Index of the first reviews to be returned.
  • limit - 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
  • limit - 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
  • limit - 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.
  • limit - Optional - Maximal number of results to be returned.


Pricing Support (optional)

The optional Pricing Simulator Decision Support feature set of the marketplace GE supports service providers using the FI-WARE marketplace to sell its artifacts. A Service Provider can employ the FI-WARE Pricing Simulator to conduct a pricing analysis and to take pricing decisions with regards to the software and services it sells through the FI-WARE Marketplace.

The diagram below shows the sequence of operations required to run a simulation experiment using the FI-WARE Pricing Simulator’s user interface.

Pricing Simulator - Activity Diagram Main Interactions

These steps are described in detail in the following sections.

Attribute Space

The Attribute Space allows the user to describe the characteristics of a software product or service by specifying its attributes. Each attribute can take one of a series of alternative levels. These levels are later on used to define concrete instances (or implementations) of an offering.

Create/Edit Attributes

This functionality allows the user to create and edit the attribute space, i.e., the set of attributes and their respective possible levels. When creating an attribute, the first step is to assign a name to it. Subsequently, the possible attribute levels have to be set using the attribute level fields.

Pricing Simulator - Activity Diagram Edit Attributes

Market Scenario

The market environment consists of economic agents populating the two sides of the market and the entities exchanged by those agents in their economic transactions. The agents are the vendor and its competitors on the supply side, and the customers on the demand side. The entities are product/service offerings sold in the market during the simulation. An offering is a product/service defined through a specific combination of attribute levels and with an attached price.

Supply

Create/Edit own and competitive offerings

The diagram below depicts an exemplary sequence of operations with the Supply component.

Pricing Simulator - Activity Diagram Edit Offerings

Setting a name for the user’s own offering is the first step to specify the supply side of the market. If profit is among the desired decision variables, own offerings should also be characterized in terms of generated costs for the vendor using the appropriate fields to specify the fixed cost per period and the variable cost per user per period of the product/service. Finally, the offering has to be configured by selecting an attribute level for each attribute.

When the user’s own offering has been described, competitors and their offerings can be described as well. In order to do this, the user must add a competitor-agent and give it a name. Then the user can add the competitor’s offerings. The definition of such competitive offerings requires name, price level, and attributes configuration.

Demand

Create/Edit demand

The user has to define the demand side of the market as well, i.e., the market segmentation in terms of customer groups and their respective preference structures. A group of customers with a common preference structure is called a segment. For each segment an identification name and the size (the number of customers it includes) have to be entered by the user. The fundamental characteristic of a customer segment is its preference structure. A segment’s preference structure can be easily configured by clicking on the edit button, which will open a pop-up window with the necessary configuration fields. A segment’s preexistent adoption decision can be specified as well as selecting one among the offerings defined in the market model.


Pricing Simulator - Activity Diagram Edit Demand

In the preference structure an attribute weight for each attribute has to be set. The attribute weight describes how important for that specific user group this attribute is relative to other attributes. Furthermore, for qualitative attributes, a score must be entered for each attribute level. These values describe how different attribute levels rate against each other. For numerical attributes a mathematical function must be specified instead of discrete levels scores. The price has its own weight called price sensitivity.

Pricing Simulator - Activity Diagram Demand Preference

Experiment

Create/Edit an experiment

When the user has defined the attribute space and the market scenario, a simulation experiment can be configured and performed. The user is free to choose the length of the simulated period of time (field “execution length”) and the number of stochastic replications to be conducted in the experiment (field “number of runs”). The user can define an interval of prices (in a range between a minimum and a maximum price) to be evaluated. The price step field allows to set the granularity of the analysis (which will determine how many alternative price levels between the lower and upper bounds will be considered).

Pricing Simulator - Activity Diagram Edit Experiment

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.

Personal tools
Create a book