Hi all, Who is maintaining the Apps/Srv Chapter wiki? We (Sandro and myself) reviewed the content and found that there is duplicate content on the wiki - see below. http://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Architecture_of_Applications_and_Services_Ecosystem_and_Delivery_Framework -- snip from the wiki -- Use cases The FI-WARE platform consists of a number of Generic Enablers, which can be used to build a concrete FI-WARE instance. Different FI-WARE instances might differ from each other because of the concrete selection of GEs and their customization. Also additional domain-specific enablers as well as proprietary enablers may be added. The following generic scenario diagrams show how the GE of the Apps Chapter are typically used in a sample Use Case. We provide scenario diagrams from the perspective of a Service Provider providing services and from the perspective of a Consumer buying and executing services. Materialization of the architecture linked to the Apps chapter has followed an Agile methodology so that each of these usage scenarios have been mapped into Themes. The functionality to be supported by each of the FI-WARE GEs involved in a Theme is described in more detail in the corresponding Epics. You may refer to the description of the FI-WARE Agile Methodology to learn more about how Agile concepts are being used in the materialization of the FI-WARE vision. *The following is duplicated below* The first Theme describes the end-to-end process associated with the Service provider creating an offering and it shows the interaction of a number of generic enablers from the Apps chapter. The first step for the service provider, once s/he has chosen a service s/he wants to commercialize, is to define the Business Model for the new offering. In this task the service provider could create a new business model or instantiate a predefined one from a template using the Business Elements Model Editor and Simulator (BEMES) toolkit. Then the service provider could use the simulation tool that is part of the BEMES toolkit in order to check its adequacy. The Business Model will be stored in the repository by the Business Elements Model Editor that is part of the BEMES toolkit. The Business Model associated to a service will contain both the description of the pricing as well as the revenue share model (in this latter case, in a way that can be processed by the Revenue Share Engine). Once the Business Model has been chosen, the next task implies creating the Linked USDL description for the service offering, by using the USDL editor and storing it in the Repository. Then, the Service Provider creates the skeleton of the offering in the Store, including the name and version that will be used to identify the offering in the Store, as well as the link of the USDL that describes both the service and its Business Model. When the Store receives the request to create an offering, it downloads the USDL description from the Repository. In the next step, the Service Provider registers the resources and binds them to the offering. Once the service offering has been created, the next step for the Service Provider is to publish it in order to make the service offering available to potential customers. The Service Provider should choose the Store, where the offering will be available. Finally, the Store publishes the service offering in the Marketplace, and notifies the Revenue Sharing System that a new offering has been published, which downloads the revenue sharing model (which is part of the chosen business model) from the Repository. *And here goes the same again* The first Theme describes the end-to-end process associated to the Service provider creating an offering and it shows the interaction of a number of generic enablers from the Apps chapter. The first step for the service provider, once s/he has chosen a service s/he wants to commercialize, is to define the Business Model for the new offering. In this task the service provider could create a new business model or instantiate a predefined one from a template using the Business Elements & Models Execution and Simulation (BEMES) toolkit. Then the service provider could use the simulation tool provided by BEMES in order to check its adequacy. The Business Model will be stored in the repository by the BEMES tool. The Business Model associated to an application/service will contain both the description of the pricing as well as the revenue share model (in this latter case, in a way that can be processed by the Revenue Share Engine). Once the Business Model has been chosen, the next task implies creating the Linked USDL description for the service offering, by using the USDL editor and storing it in the Repository. Then, the service provider creates the offering skeleton in the Store, including the name and version that will be used to identify the offering in the Store, as well as the link of the USDL that describes both the service and its Business Model. When the Store receives the request to create an offering, it downloads the USDL description from the Repository. In the next step, the service provider registers the resources and binds them to the offering. Once the service offering has been created, the next step for the service provider is to publish it in order to make the service offering available to potential customers. The service provider should choose the target marketplace, where the offering will be searchable. Finally, the Store publishes the service offering in the chosen Marketplace, and notifies the Revenue Sharing System that a new offering has been published, which downloads the revenue sharing model (which is part of the chosen business model) from the Repository. --- snip --- -- Thomas Michael Bohnert (TMB) Head of Service Engineering (ICCLab, SPLab) Zurich University of Applied Sciences eMail: thomas.bohnert at zhaw.ch mobile: +41791758136 web: www.cloudcomp.ch, tmb.nginet.de twitter: tmbohnert skype: tbohnert
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy