[Fiware-apps] [Fiware-chapter-architects] Duplicate content on the FIWARE wiki - Apps/Srv Chapter

[Javier Soriano (FI-UPM)]

Hi Thomas,

Thank you very much for the notice. We will fix it asap.

Best regards,
Javier

2014-11-23 21:04 GMT+01:00 Thomas Michael Bohnert <thomas.bohnert at zhaw.ch>:

> 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
> _______________________________________________
> Fiware-chapter-architects mailing list
> Fiware-chapter-architects at lists.fi-ware.org
> https://lists.fi-ware.org/listinfo/fiware-chapter-architects
>



--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-apps/attachments/20141123/cfd00688/attachment.html>