Dear Colleagues,
Please check Juanjo's email with respect to the sections that concern your GE and address the issues raised in there.
Thank and best regards,
Uwe
From: Juanjo Hierro [mailto:jhierro at tid.es]
Sent: Mittwoch, 25. Juli 2012 09:08
To: Leidig, Torsten; Riss, Uwe
Cc: Miguel Carrillo; jhierro >> "Juan J. Hierro"
Subject: Comments on Features linked to GEs in the Apps Chapter
Dear Uwe and Torsten,
Please find my comments regarding revision/addition of Features linked to GEs in the Apps Chapter. If there is anything you disagree with and wish to discuss, I'm happy to.
Please forward this to the people of your team involved so that they can start working on a revised version of the Features addressing the comments.
Cheers,
-- Juanjo
1. General Comments
Please check the General Comments for all chapters that have been sent. Several of those comments apply to your chapter. We will try to point here where they specifically apply to your chapter but don't miss to carry out a revision yourself.
I have left USDL apart because I do not consider it a GE itself.
2. Service Repository
Taking a look at the User Stories derived from the single defined Feature that you provide ( FIWARE.FEATURE.Apps.USDL.BasicRepositoryService<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.USDL.BasicRepositoryService>) , we would get an enough complete overview of the functionality that the GE supports. Please consider implementing any of the suggested solutions described in the email on General Comments sent to all chapter leaders (section 1.4), particularly that of cloning User Stories as Features. If you go for keeping the existing Feature, certainly the Goal description doesn't follow the guidelines we defined long time ago (see Project Handbook, https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/How_to_upload_the_full_description_of_backlog_entries_to_the_Wiki).
Assuming that you have defined Features that are 1:1 linked to User Stories, I believe you have to review the description of FIWARE.STORY.Apps.Repository.RepositorySearch<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.STORY.Apps.Repository.RepositorySearch> to clarify what do you mean by "OpenSearch" ("... The search functionality should be described by OpenSearch.")
It is not clear what is the difference between FIWARE.STORY.Apps.Repository.ListServiceDescriptions<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.STORY.Apps.Repository.ListServiceDescriptions> and FIWARE.STORY.Apps.Repository.RepositorySearch<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.STORY.Apps.Repository.RepositorySearch> looking at their description, which means that they probably should be refined.
3. Registry
There are no Features linked to this GE. Most probably because we would be in a situation similar to Service Repository. Please consider implementing any of the suggested solutions described in the email on General Comments sent to all chapter leaders (section 1.4), particularly that of cloning User Stories as Features.
4. Marketplace
Generally speaking, Goal description didn't follow the guidelines defined long time ago (again, see established guidelines)
FIWARE.FEATURE.Apps.Marketplace.FulltextSearch<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Marketplace.FulltextSearch> Feature: It would be nice to describe how keywords are created/assigned/linked to services. Minor suggestion ... Shouldn't the feature be identified as "KeywordSearch" or "TextKeywordSearch" rather than "FulltextSearch" ?
FIWARE.FEATURE.Apps.Marketplace.StoreManagement<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Marketplace.StoreManagement> Feature: I would suggest to elaborate in the description how are Stores going to be registered ... Is it about registering the URL linked to a Store against which users/applications will be able to issue requests linked to the Store API ?
FIWARE.FEATURE.Apps.Marketplace.OfferingManagement<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Marketplace.OfferingManagement> Feature: Little is said about Offerings in the description as to be able to rightfully label this as a Feature. Are we providing enough level of detail as to understand this could be implemented in the course of a single minor Release (i.e., three months) ? One of the things I would expect to see is a high-level description of what an Offering would be ... what attributes it would have, etc
FIWARE.FEATURE.Apps.Marketplace.UserManagement<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Marketplace.UserManagement> Feature: typo saying "rolse" instead of "role". Seems like the description was a copy&paste of the description of the FIWARE.FEATURE.Apps.Marketplace.OfferingManagement<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Marketplace.OfferingManagement> Feature ...
5. Store
I wonder then what we are going to deliver here for the first Release once it is clear that Ericsson won't deliver the eStore ... My understanding was that the gap was going to be covered by the UPM ... but I don't know what's the status and it seems you haven't updated the backlog in this respect ... Could you elaborate on the matter ?
6. Revenue Sharing
FIWARE.FEATURE.Apps.RSSS.RSSModelManagement<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.RSSS.RSSModelManagement> Feature:
* On one hand it is said that "Revenue Sharing must support the management of revenue sharing models." but on the other hand, it is said that "Just percentage algorithm is supported." It is unclear what we mean when we say "just" ... Does it mean that we are ONLY going to support models defined based on percentage algorithms now and forever, or that we are going to support only percentage algorithms in the second major release (when this GE is planned to be delivered for the first time) but this may be extended in future releases ? If it is the first case, then I would avoid saying "just" and say something like "each revenue sharing model will map into an algorithm for calculating revenues among involved parties", for example. If it is the second case, then I would suggest defining an Epic that has to maps to the need to support the manage of multiple revenue sharing models in general (we can indeed identify it as FIWARE.FEATURE.Apps.RSSS.RSSModelManagement) and then use the current Feature to elaborate on the management of revenue sharing models using percentage algorithms, changing the Id accordingly (to FIWARE.FEATURE.Apps.RSSS.RSSModelManagement.FixedPercentageRSSModels, for example)
* Notwithstanding the above, I believe that the description of the this Feature should be enriched:
* If each Revenue Sharing Model maps into an algorithm that establishes what is the % of the revenues that is assigned to each party, then I would clearly say so.
* I would explain that the User will have means to provision/register the algorithm assigned to each model
* I would elaborate on what kind of algorithms will be supported. Looking at the definition of the FIWARE.STORY.Apps.RSSS.FlexibleRSSAlgorithmProvision<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.STORY.Apps.RSSS.FlexibleRSSAlgorithmProvision> User Story later on, it seems like the will be algorithms that will establish a % that gets fixed over time but there will be also algorithms that enable to change these % dynamically
FIWARE.FEATURE.Apps.RSSS.CDRsReception<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.RSSS.CDRsReception> Feature: It would be worth explaining (in the description) what short of mechanisms are going to be supported for CDRs Reception. Is it going to be through an API that enables to submit CDRs in real time on an individual basis ? Are we going to allow submission of CDRs using files ? We don't need to enter in the details of course (signature of operations, format of files) but give an overall description of what mechanisms are going to be supported.
FIWARE.FEATURE.Apps.RSSS.RSSCalculation<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.RSSS.RSSCalculation> Feature:
* It would be worth describing (in the description) whether calculation takes place in batches or recalculation is performed real-time in parallel to reception of CDRs. Also whether "hot" updates of algorithms definitions is going to be supported or not: are we going to have operations to "pause" calculation for a given number of commercialized services because we have changed the way revenue share is calculated or should we stop the complete system ? things like that.
* I wonder whether this Features shouldn't be merged with the FIWARE.FEATURE.Apps.RSSS.RSSCalcAggrBased<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.RSSS.RSSCalcAggrBased>. I would keep them separate if we are going to support different methods of calculation (e.g., both based on batch calculation but also incremental). But if it is always incremental, why don't merging them.
FIWARE.FEATURE.Apps.RSSS.FlexibleRSSAlgorithms<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.RSSS.FlexibleRSSAlgorithms> Feature: I would try to elaborate here what is going to be possible or not. Maybe this depends on what the BM&BE GE will provide because that GE is the one that would provide tools to define the different algorithms based on, for example, defined templates. If so, it would be worth mentioning it.
FIWARE.FEATURE.Apps.RSSS.CDRAggregations<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.RSSS.CDRAggregations>: It seems like the goal from the previous Feature has been copied&pasted here. The description seems to be appropriate but the goal doesn't.
FIWARE.FEATURE.Apps.RSSS.Vouchers<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.RSSS.Vouchers> Feature: It had to read the description several times to get a relatively clear view of the Feature. I would suggest some editorial changes that maybe would improve the understanding:
The RSS will calculate the RS taking usage of vouchers into account. There will be no RS generated when the user of an application/service acquires a voucher, only the uses of the voucher will generate incomes for the providers of the application/services. RSS will calculate a cost per usage by dividing the cost of the voucher by the total number of uses it contains. As the cost of the voucher might change every time it is renewed, the RSS will store each new acquisition price and establish a relationship between every voucher usage and the corresponding acquisition.
(note: shouldn't 'a cost' marked in red be replaced by 'the total revenue (to be shared)' ?)
Last but not least, if some User Stories were derived as a result of elaborating the Features, it would be nice to reflect that relationship in the Id as we have adopted as convention in many other GEs. If, for example, FIWARE.STORY.Apps.RSSS.FlexibleRSSAlgorithmProvision<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.STORY.Apps.RSSS.FlexibleRSSAlgorithmProvision> is related to FIWARE.FEATURE.Apps.RSSS.RSSModelManagement, then identify it as FIWARE.FEATURE.Apps.RSSS.RSSModelManagement.FlexibleRSSAlgorithmProvision.
7. Composition
I will treat this in a separate email.
8. Mediator
Description of the following Mediator features are rather poor. I wonder whether a minimal peer review by someone else (WP Leader ?) has been passed:
* FIWARE.FEATURE.Apps.Mediation.SemanticDataMediation<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.SemanticDataMediation>
* FIWARE.FEATURE.Apps.Mediation.AdvancedSemanticDataMediation<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.AdvancedSemanticDataMediation>
* FIWARE.FEATURE.Apps.Mediation.RunTimeProcessModelling<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.RunTimeProcessModelling>
* FIWARE.FEATURE.Apps.Mediation.BPMN20CompliantFileGeneration<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.BPMN20CompliantFileGeneration>
* FIWARE.FEATURE.Apps.Mediation.BPEL1.2CompliantFileGeneration<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.BPEL1.2CompliantFileGeneration>
One may think that a better clue of what is being described could be obtained after reading the description of the Architecture of the Mediator GE (part of FI-WARE Architecture and Open Specifications), however this is not the case. As an example, you simply try to search for the words 'semantic', 'BPMN' or 'BPEL' in the wiki page linked to description of the Architecture of the Mediator GE. Therefore, it is almost imposible to get a clue of what these features are about. Of course, the text provided as Goal or description doesn't help at all:
* FIWARE.FEATURE.Apps.Mediation.SemanticDataMediation<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.SemanticDataMediation>: DataFlow Mediation based on semantic exact matching and subsuption (Goal) Data mapping of elements in the I/O that are similar (Description)
* FIWARE.FEATURE.Apps.Mediation.AdvancedSemanticDataMediation<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.AdvancedSemanticDataMediation>: DataFlow Mediation based on semantic plugin and intersection (Goal) Advanced data mapping of elements in the I/O that ara not exactly matched. (Description)
* FIWARE.FEATURE.Apps.Mediation.RunTimeProcessModelling<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.RunTimeProcessModelling>: DataFlow Mediation based on semantic plugin and interseaction (Goal, same as previous Feature but now with typo) Advanced data mapping of elements in the I/O that ara not exactly matched (Description, same as previous)
* FIWARE.FEATURE.Apps.Mediation.BPMN20CompliantFileGeneration<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.BPMN20CompliantFileGeneration>: Get a BPMN2.0 fully compliant file (Goal, one quickly ask himself 'for what ?') Completing BPMN2.0 file (Description)
* FIWARE.FEATURE.Apps.Mediation.BPEL1.2CompliantFileGeneration<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.BPEL1.2CompliantFileGeneration>: Get a BPEL1.2 fully compliant file (Goal, one quickly ask himself 'for what ?') Completing BPMN2.0 file (Description)
One misses Features that somehow may align with description of the Architecture of the GE ... e.g., ability to create and manage the lifecycle of Mediation Tasks, Dynamic Mediation Tasks ... the ability to create chains of mediation tasks ... the provision of proxies and endpoints ... but nothing is there.
One can intuitively understand what kind of functionality may be supported by the Mediator GE when reviewing the following Features:
* FIWARE.FEATURE.Apps.Mediation.ProtocolMediation.SOAP2REST<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.ProtocolMediation.SOAP2REST>
* FIWARE.FEATURE.Apps.Mediation.ProtocolMediation.SOAP2POX<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.ProtocolMediation.SOAP2POX>
* FIWARE.FEATURE.Apps.Mediation.ProtocolMediation.TCP2HTTP<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.ProtocolMediation.TCP2HTTP>
However, all kind of questions come to my mind when trying to understand how this may work. Is it a WSDL generated in the case of the SOAP2REST or SOAP2POX cases ? How is it generated ? Is there a tool that generates the code of a mediation task based on description of a particular REST API (i.e., a different mediation task is generated per REST interface) ? Or are we talking about some sort of generic mediation task that processes configuration data generated per particular REST API ? How is the description of a REST API provided ? (all of us know that there is nothing like a WSDL in REST) They should be answered somewhere ... if in the Architecture wiki page, then you should at least include a reference (link) in the description here.
The owners of this GE responsible of the Features above have to seriously revise description of Features for this GE because it is a clear candidate for rejection.
Regarding the FIWARE.FEATURE.Apps.Mediation.ProtocolMediation.Security<https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.FEATURE.Apps.Mediation.ProtocolMediation.Security> Feature, it is more or less clear what it does despite its usage will be rather limited, given the fact that most of the APIs provided by GEs in FI-WARE are REST.
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Dr. Uwe Riss
Senior Researcher, Internet Applications & Services | SAP Research Karlsruhe
SAP AG | Vincenz-Priessnitz-Str. 1 | 76131 Karlsruhe | Germany
T +49 6227 7-70212 | F +49 6227 78-26158 | M +49 151 16810936 | mailto: uwe.riss at sap.com<mailto:uwe.riss at sap.com>
www.sap.com<http://www.sap.com/>
Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx
Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtuemlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdruecklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-apps/attachments/20120725/dec9075a/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy