Dear WP3 Partners,
There are still issues with the Chapter Backlog as outlined by Juanjo below. Please revisit the specific parts and make the changes if possible or answer to Juanjos questions/demand.
Best regards,
Torsten
From: Juanjo Hierro [mailto:jhierro at tid.es]
Sent: Monday, July 30, 2012 12:38 AM
To: Leidig, Torsten; Riss, Uwe
Cc: Juanjo Hierro; Miguel Carrillo
Subject: Re: Comments on Features linked to GEs in the Apps Chapter
Hi,
Please find between lines my revision on how comments have been addressed.
There are some comments regarding Features of some GEs that have not been addressed at all. I always believe that when someone takes some time to carry out a peer review of your stuff, you should at least provide a reaction to his comments. Ignoring peer reviews may well justify some rejection of person*months, at least those you should have devoted to respond to that peer review (either rejecting comments with some rationale or incorporating changes based on comments) ... despite they may be minor. I would like to hear your opinion.
Best regards,
-- Juanjo
On 25/07/12 09:08, Juanjo Hierro wrote:
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).
I still believe that referring to a single feature in the Technical Roadmap deliverable will look awful but you apparently disagree ...
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.")
This comment has not been addressed. Still a stakeholder (e.g., a UC project) won't understand what you refer to when you talk about "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.
Not clear whether this comment was addressed looking at the history, but reading what is there, I believe the difference is more or less clear.
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.
Not addressed.
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" ?
Not addressed, though not critical. Did you disagree ?
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 ?
Addressed.
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
Addressed
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 ...
Addressed
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 ?
This is still not clear to me ... but let's handle that separately
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.
Pablo sent me a report on how the different comments were addressed, so I actually consider them addressed
7. Composition
First of all, I wanted to clarify whether we are using some sort of convention for ids ... In a first approach it seems like the id of any Feature that applies to the Composition Editor, no matter whether it applies to masup of UI gadgets, composition of backend services using BPM standards or composition of backend services using the ECE platform, is preceded by a 'C3' prefix ... This to distinguish them from Features like FIWARE.FEATURE.Apps.CompositionEditor.CreateUIOrientedServiceComposition which are specific of UI gadgets mashups. However, later I read some features that I would say are also common to all three paradigms ... shouldn't their ids be preceded by a 'C3' ? I'm talking about:
FIWARE.FEATURE.Apps.CompositionEditor.SemanticFeatured
FIWARE.FEATURE.Apps.CompositionEditor.TaskSemanticAnnotation
FIWARE.FEATURE.Apps.CompositionEditor.PublishCompositionToUSDLRepository (this one I'm not pretty sure
FIWARE.FEATURE.Apps.CompositionEditor.C3BasicSearchUSDLService Feature: I guess it would be worth mentioning whether a given Composition Editor will be able to federate the services in multiple distributed USDL Repositories. I guess it would be nice to support it. Since I guess this will not be supported for the first release, I would go for splitting it into two Features or one Feature and an Epic, the former referring to access to a concrete USDL Repository (i.e., ability to connect to a single one) and the later linked to an extension of future releases to support federation.
Not addressed.
FIWARE.FEATURE.Apps.CompositionEditor.IoTBPMNExtensions Feature: Is this still in place ? I'm not pretty sure so I preferred to ask :-) If still applies, I definitively would like to see a description of what those sort of extensions would be. Note that if we have classified this as a Feature, is because we bet it can be implemented in the course of 3 Sprints, so it should be already designed/discussed to enough level of detail as to be able to assume such estimation ... If not, then it should be an Epic (and even though in a higher level, it should still give some clue about what sort of extensions we are talking about)
Not addressed.
FIWARE.FEATURE.Apps.CompositionEditor.CreateUIOrientedServiceComposition Feature: I would rename this Feature so that the relationship with the previous FIWARE.FEATURE.Apps.ExecutionEngine.SupportEventDrivenGadgetExecution feature becomes more evident. I have changed the Goal to enhance the fact that we target end users that can design mashups without programming skills. I would also enhance the existing description to highlight the relationship. My suggested description:
End users can create new applications, also referred as mashups, by wiring UI components called widgets/gadgets searched and selected from a catalog. Those gadgets can communicate between themselves at runtime based on the Event-driven Gadget communication mechanism supported by the Execution Engine. End users can also import mashups defined by other users as whole, either from the catalog or from a mashup description file in MDL. Imported mashups can be enhanced by adding new gadgets from the catalog that may be wired together with the gadgets in the original mashup. Last but not least, the user can store the resulting composite app in the catalog for reuse.
Note that this description is large enough so that we may have split this Feature into several, but I can live keeping just one, provided the description is complete.
Addressed.
FIWARE.FEATURE.Apps.ExecutionEngine.SupportPushDrivenWiring Feature: I may be wrong, but the description sounds very much like the description of the FIWARE.FEATURE.Apps.ExecutionEngine.SupportEventDrivenGadgetExecution feature ... and it doesn't highlight so clearly what the Feature really is about: supporting push communication with gadgets running on a client browser from the server. My suggested id, goal and description.
Id: FIWARE.FEATURE.Apps.ExecutionEngine.SupportPushCommunicationToClientGadgetsFromServers
Goal: Applications and Services running at the backend should be able to push data to gadgets running at browser clients
Description: Certain applications may require that backend services be able to push data into Gadgets that are part of a mashup application running on a client browser. This requires both an html5 javascript pub/sub API in the client side, and the corresponding server side pub/sub API. It also requires a pub/sub middleware to be plugged in the Execution Engine (i.e. a plugin architecture in the Execution Engine)
Apparently not addressed.
FIWARE.FEATURE.Apps.CompositionEditor.SemanticFeatured Feature: The description of this features should be clearly enhanced. It should elaborate on why we believe it's useful to introduce semantics and, besides, what semantics are we going to typically exploit in an environment like the one proposed.
Addressed.
FIWARE.FEATURE.Apps.CompositionEditor.TaskSemanticAnnotation Feature: same as previous. Please provide more info.
Addressed
FIWARE.FEATURE.Apps.CompositionEditor.CreateComposition Feature: I would rename this as FIWARE.FEATURE.Apps.CompositionEditor.CreateBPMComposition to distinguish it from the compositions based on the DT asset ...
Regarding the following Features, I would label the kind of composition supported some way to make it clear that we are not talking about any sort of composition (kind of meta-feature applicable to all composition paradigms supported) but the kind of composition based on the DT asset, which is what they are as far as I understand.
FIWARE.FEATURE.Apps.CompositionEditor.Compose
FIWARE.FEATURE.Apps.CompositionEditor.Install
FIWARE.FEATURE.Apps.CompositionEditor.Test
Not addressed.
FIWARE.FEATURE.Apps.CompositionEditor.ECE-CreateComposition Feature: I would change the goal so that it says "Creation of an ECE-based Service Composition" for the same reasons I gave with my last comment regarding DT's service composition technology. In the description, I would bind an URL to "... The tool is using Ericsson Composition Editor constructs ..." which points to descriptive documentation of that components of Ericsson's product
FIWARE.FEATURE.Apps.ExecutionEngine.ECE-ExecuteComposition Feature: I would change the goal so that it says "Execution of an ECE-based Service Composition" for the same reasons. In the description, I would bind an URL to "...Given a composition description in the Ericsson Composition Format, provide ..." which points to descriptive documentation of the format
Not addressed
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.
As far as I understand, none of the comments have been addressed ... I would like to understand what your position is on this, overall taking into accout that this was a clear candidate for rejection ...
________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-apps/attachments/20120730/036f80bc/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy