Hi all, Please find below my notes from our confcall today. Please share with your respective teams. As you see, there will be a number of APs to setup a number of Task Forces, each concentrated in a particular cross-chapter topic (see point on goals and agenda). A mailing list for discussion on the topic will be setup. In addition, a ticket will be created in a Task Force Management tracker we will setup in the "FI-WARE Private" project in FusionForge that has been created. The ticket will point to the archive of the mailing list being created and will help us to follow up progress. Cheers, -- Juanjo 1. Attendees * Cloud Chapter: Alex (IBM) * Data Chapter: Carlos (TID) * IoT Chapter: Denes (NSN) * Apps Chapter: Torsten (SAP), Axel (SAP) * Security Chapter: None * I2ND: Pier (TI), Hans (DT) * Dev Tools: Davide (Engineering) * Exploitation (Juan) 2. Goals and agenda: The main goal of the confcall is to identify architectural topics that will require further discussion involving more than one chapter. An Architecture Task Force will be created for each relevant topic. Concretely, this will mean that: * TID will set up a dedicated mailing list and create a ticket on the Task Force tracker in the FI-WARE private project in FusionForge * Each WPL/WPA will designate who should join from their chapters * The partner who proposed the Task Force (owner of the Task Force) will kick-off the discussion on the mailing list by sending an email which helps as terms of reference * The owner of the Task Force should present conclusions at the joint WPL/WPA meeting that will take place on January 23rd Each WPL/WPA was requested to bring any cross-chapter topic for which he wish to create a Task Force. The following partners brought some views: * Juanjo (TID) * Davide (Engineering) * Torsten (SAP) * Pier (Telecom Italia) 3. Presentation by Juanjo 3.1 Generalize Event Management model being proposed at the level of Things in IoT chapter, applying it to Cloud Monitoring and Security Events Monitoring Despite it is still under discussion, the Event Management Model being proposed at the level of Things in the IoT chapter is rather generic and has been defined so it is consistent with the Event Management model defined within the Data/Context Management Model. This Event Management Model is based on the OMA (Open Mobile Alliance) specs for NGSI Context-Management. In such model, an event leads to generation of a Context Element data structure which includes info about updated values of properties linked to entities defined in the system. An entity maps to the concept of "Thing" in the IoT chapter but there may be other entities in the system (e.g., another application). In FI-WARE, values assigned to properties describing Things will be derived from data gathered from IoT resources, referred as sensors, which run on IoT devices. Associations between Things and IoT resources as well as formulas for mapping values of IoT resources into properties of entities are handled through an IoT Configuration Management GE at the Things Management Layer. However, this concept may be further generalized so that we talk about "Monitoring Agents" or "Monitored Resources". The model would then be able to work for both Cloud Monitoring and Security Events Monitoring. The advantage for this approach would be reuse of components, as well as exhibiting higher coherence. AP: Setup task force to check whether the Events Management Model defined at the level of Things within IoT chapter can be adopted for both Cloud monitoring and Security events monitoring. Mailing list to be created: fiware-monitoring 3.2 Glue middleware There are a number of issues that are related to how interfaces exported by GEs are actually specified and implemented: * first, we have to agree on a common way to specify interfaces exported by GEs ... Should we adopt REST as a minimum common denominator ? Can we define a technology-neutral approach that would allow an interface to be accessible using multiple technologies (REST, WS, optimized binary protocols, ...) and would allow us to overcome that a given technology becomes deprecated ? * second, the most suitable technical solution for some Security issues may need to implement some functions at middleware level * third, APIs usage accountability may require that also some functions be implemented at middleware level if we want to achieve a suitable level of transparency Alex: not sure if we can decide on one API paradigm but he agrees we should support just a limited set Juanjo: is not about choosing one API paradigm but probably define an interface definition language that may abstract us from the limited set of API paradigms we will support (which could then be extended over time). Denes: any decision on middleware should take into account that middleware may need to fit with restrictions about computing resources in IoT devices AP: Setup task force on the matter. Mailing list to be created: fiware-middleware 3.3 Network-aware Cloud Some UC projects have declared the need to be able to declare what SLO (Service Level Objectives) they want to see fulfilled for certain end-to-end scenarios, typically requiring communication between applications running on the Cloud and IoT gateways (cloud proxies) or end users. It would then be up to the Cloud Hosting capabilities in FI-WARE to cope with those SLOs relying on capacities of the underlying network. Despite we will see whether this functionality would easily fit in the roadmap based on available resources, all declare to agree with creation of a Task Force on the matter. It will typically involve partners from the I2ND chapter, Cloud chapter and Apps chapter (since we need to resolve how this sort of SLOs become part of the SLA definition linked to an application) We agree to leave P2P scenarios aside for the time being unless UC projects raise the need to analyze them. AP: Start with a single Task Force involving I2ND, Cloud and Apps chapter members. Mailing list to be created: fiware-network-cloud-SLOs Eventually split into two task forces if needed which may be: - a task force involving Apps (Business Framework) and Cloud chapters, dealing with how to declare SLAs at USDL related to end-to-end SLOs - a task force involving Cloud and I2ND chapter dealing with how to implement SLOs relying on QoS management functions exported by networks 3.4 Semantic Web Infrastructure: Several chapters addressing development of GEs whose implementation relies on Semantic Web technologies. We should go for the selection of a single technology for this (mostly RDF storage and SPARQL support) AP: Setup a Task Force that takes a decision for all the project. Mailing list to be created: fiware-semantic-platform Torsten: Shouldn't we also go for a common decision regarding linked-data GE ? AP: Apps chapter to share info about linked-data technologies being defined in their chapter so that rest of WPAs can evaluate whether it can be used elsewhere (info to be sent to fiware-wpa mailing list for the time being) 3.5 Common Look&Feel in FI-WARE portals AP: Juanjo to launch a thread of discussion on the matter so that we can start discussion on the matter 4. Development Tools by Davide Davide reinforce the need to link some of the developments to be made within the Dev&Tools and those in other chapters. Particularly those that have to do with deployment tools where we need to explore how they integrate (or matches) the development of part of the Cloud portal. He also reinforce the need to make a decision on how interfaces will be specified and what protocols will be supported. Davide take the opportunity to reinforce that other chapter leaders should answer the questionnaire that was distributed by WP9 to all WPLs/WPAs. 5. Presentation by Torsten Despite Torsten didn't have time to present all cross-chapter topics, he made emphasis on the need to push for making services provided by FI-WARE GEs available in the marketplace. This means that they should be defined in USDL. Juanjo: this should allow that a FI-WARE Instance Provider operating a FI-WARE Instance defined around the Marketplace GEs offer third parties the ability to publish their implementation of FI-WARE GEs in other chapters and get paid for their usage by applications. It would also help a FI-WARE Instance Provider operating a FI-WARE Instance that deploys all FI-WARE GEs to establish how it plans to charge for usage of their services by applications. AP: To setup Task Force on discussion about USDL. Mailing list to be created: fiware-usdl As a second major point in his presentation, Torsten put emphasis on the need to close the definition of the GEs supporting Identity Management. We should soon have the APIs of these GEs defined as soon as possible. Juanjo and Pier highlighted this is rather relevant. Juanjo expects that the Security chapter has been able to further refine the vision that they presented in the workshop which took place in November and now could present a detailed Reference Architecture with well-defined APIs. AP: To setup Task Force on discussion about Security Identity Management, Access Control and Data Handling. Mailing list to be created fiware-security-core Unfortunately, there was not time to address other topics to be brought by Torsten. He will distribute his presentation among WPLs/WPAs. 6. Short comments by Pier Pier mentioned that they are already working on how to ensure that cloud-edge proxy supports all capabilities that are needed to host IoT software. AP: We may consider that a Task Force is already in place. We just need to create a dedicated mailing list to discuss on the matter: ------------- Juanjo Hierro Product Development and Innovation (PDI) - Telefonica Digital email: jhierro at tid.es<mailto:jhierro at tid.es> twitter: twitter.com/JuanjoHierro ________________________________ 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/fiware-wpa/attachments/20111220/61039872/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy