Hi, We will start 09:45am sharp. I would rather encourage you to read the message below in the 15mins between 09:30am and 09:45am. This will save us some time during the confcall. Carlos had distributed the dial-in and webex bridge details Cheers, -- Juanjo -------- Original Message -------- Subject: [Fiware-wpl] IMPORTANT TO SYNC: FI-WARE First Open Call Date: Fri, 23 Dec 2011 08:25:30 +0100 From: Juanjo Hierro <jhierro at tid.es><mailto:jhierro at tid.es> To: fiware-wpl at lists.fi-ware.eu<mailto:fiware-wpl at lists.fi-ware.eu> <fiware-wpl at lists.fi-ware.eu><mailto:fiware-wpl at lists.fi-ware.eu>, fiware-wpa at lists.fi-ware.eu<mailto:fiware-wpa at lists.fi-ware.eu> <fiware-wpa at lists.fi-ware.eu><mailto:fiware-wpa at lists.fi-ware.eu> Hi all, This is to report to you about the decisions taken regarding topics for the first Open Call in FI-WARE. Please share this info with your respective teams. Going through a sequence of three intensive dedicated confcalls, the FI-PPP AB has came to an agreement on how to handle the higher priority topics raised by the UC projects as well as what will be the topics to be addressed in the first Open Call (a number of topics proposed by FI-WARE have been incorporated in the analysis in respect to this last point). You can get a wrap-up of this exercise summarizing the agreements reached looking at the sheet titled "Wrapup" in the following shared Google docs spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AqGGeaQGro3fdHFLUXozQU9lem5rWVRBeS02czJmNlE&hl=en_US#gid=1 As you will see, only two topics will be addressed in the first Open Call. Following the advice of our PO, Arian Zwegers, we have decided to split the original first Open Call into two Open Calls, therefore having a total of three Open Calls overall. We have also decided to go for a very short list of topics in this first Open Call. This is because: * Again, following our PO advice, we have to take the opportunity of this Open Call to learn about how to manage the Open Call process so it's better to make it a "small trial" * We had to face the challenge of describing in detail and in collaboration with the UC projects what we will ask for in the description of this first Open Call, which has to be issued by end of January 2012. We have little time/resources to do this for too many topics, overall taking into account that we need to face a number of deliverables by end of January. In addition, many of the high-priority topics that both UC projects and ourselves have in our list (some of them shared) are still described in a too high-level so clearly there is a need to work on further refining them as to distill the actual features we want to support in FI-WARE. This is something that makes sense to afford during Q1 of 2012. Regarding the two particular topics selected for the first Open Call, let me elaborate a bit on them: * Middleware for efficient and QoS/Security-aware invocation of services as well as exchange of messages. There were several UC projects that were asking for this, not just for implementing communication between different parts of the application but for invoking services exposed to applications by the FI-WARE GEs. Therefore, we will have to go for it definitively. However, I see here the opportunity to drive what has to be developed in a way it can become useful in FI-WARE to help a) solving some of the issues we had identified during our Security workshop on November that have to do with managing access control through credentials when handling requests to services, b) dealing with several accountability and traceability issues and c) enabling a technology-neutral definition of GE interfaces. I will elaborate more on what I believe we may push into the definition of requirements for such middleware in the "Glue Middleware" Task Force we agreed to launch in our last joint WPLs/WPAs follow-up confcall. * Business Models and Business Elements (BM & BE) Definition and Simulation This is leveraged in a request made by UC projects to have means for simulating how costs of deploying a given application on top of FI-WARE (not only hosting service costs but costs derived from using other FI-WARE GE services or even third-party application services) could be simulated. Here, I found the opportunity to map this to our critical need to address the development of a BM & BE definition support component in the context of the first Open Call since this will be a base component of the Business Framework Reference Architecture for which an asset hadn't been identified. On the other hand, from my point of view, merging the two things together makes a lot of sense because any party that is able to contribute a product that implements this sort of simulation (which is the ultimate need expressed by the UC projects) may have probably implemented its own tools for defining the basic BM & BE on which simulation is based. Therefore, it makes sense to me to go and adapt our basic BM & BE Model to the one such potential new partner may bring. Regarding the rest of topics some of you had proposed, they where discussed and we agreed that they may go for the second call after their functional description is further defined, which is something that should happen during Q1 2012. Regarding the rest of topics raised by the UC projects, I would like to highlight the following: * Augmented Reality and 3D User Interfaces were brought to the table. Fair enough, these topics are clearly something we were not covering but have to do a lot with the kind of User Experiences someone would expect to see supported in Future Internet Applications. Therefore, I find it rather suitable to cover them through Open Calls which may attract rather specialized partners on the topics. In my view, this may probably lead to definition of a Working Package on User Interface support where, BTW, we may explore whether multi-device and multi-channel access to applications (currently in WP3 and somehow lacking of support) may be collocated. * Many UC projects are looking for means in the platform that will enable them to assure certain QoS at infrastructure level not just at centralized Data Centers but end-to-end. This had been mapped into a number of requests assigned to the I2ND chapter. UC projects do not expect to manage QoS at communication level from the application themselves (other than through the basic middleware targeted in the 1st Open Call). What they expect is to be able to select, configure and contract the SLA linked to an application at configuration&deployment time. SLAs that I see would be expressed in terms of a number of SLOs (Service Level Objectives). In words of one UC project: What would be very nice to have is a service which I can ask: "I need connectivity from A to B", and the service will answer "OK, you have 10 possible paths, price is such, characteristics of connection are such". If this is done properly, my application can then choose the "most reliable", "least expensive", or "most secure" path (and this will be seutp automatically). Next thing would be monitoring to see if the promised characteristics were really delivered (otherwise I don't pay...) I agree this has to be a functionality that has to be provided by FI-WARE but will require a close coordination between the Cloud, I2ND and Apps (Business Framework) chapter, so let's really assign this a high priority in our discussions. BTW, this clearly matches one of the cross-chapter Task Forces we identified during our last joint WPLs/WPAs confcall (Network-aware Cloud Task Force) * Many UC projects also have requirements for distributing their applications partly in the centralized Data Centers and partly in cloud proxies at the network-edge. Many of them wish to see the concept of cloud-proxy generalized as to cover smartphones and other smart but small devices. This comes along the need to be able to describe this distributed taxonomy at the time applications are configured and deployed on FI-WARE as well as the need to define means for handling failures in communication between the Data Center clouds and cloud proxies (periodic synchronizations and the like). This doesn't come as something new to us, but confirms the need to afford the definition of the necessary components at the Cloud chapter that can deal with this and prepare this as a subject for the second Open Call. * Another common requirements have to do with a) being able to assign a level of certainty/trust to data being managed by the application and b) being able to manage access and views to data depending on credentials of the user on behalf of whom an application is trying to get access to data. Both requirements are clearly generic and probably useful for many applications but we agreed we have to explore to what extend this lead to definition and development (through an Open Call) of enablers that can really qualify as generic and go beyond those defined in the Data/Context Management chapter. * Several UC projects also expressed the need for several kind of "data-stream-oriented" GEs. For instance, the notion of Publish/Subscribe but linked to streams rather than to atomic data units. Again, this seems to be something generic and useful enough for many applications but we agreed we have to explore to what extend this lead to definition and development (through an Open Call) of enablers that can really qualify as generic and go beyond those defined in the Data/Context Management chapter. * Rest of requirements were about topics I believe most probably are already in our roadmap or should not be a big issue to include in our roadmap. We agreed to follow them during Q1 2012 as to confirm this or not. Hope this long summary gives you a clear picture. Next steps will mean working on the detailed development of Epics that will be published as part of the first Open Call and will provide an enough detailed description of what we are looking for there. In addition, setting up a number of Task Forces on the topics above, involving UC projects, where we will address identification of Features. Such features will either enrich our current FI-WARE backlog (because we find they would fit within the roadmap of already identified GEs) or will be used for describing what will be requested in the second Open Call. More details will follow in the first weeks of January. I take advantage of this email to wish you all a very nice Christmas and a Happy New Year. Cheers, ------------- 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 ________________________________ 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-data/attachments/20111223/828e1084/attachment.html> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001..txt URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20111223/828e1084/attachment.txt>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy