Dear colleagues, Please find enclosed, if you read bottom-up: * A message sent by the Safecity UC project providing initial feedback on our FI-WARE High-level Description draft * My initial response to their comments WPLs/WPAs of the Cloud, Data/Context Management, I2ND and Security Chapters are entitled to: * Review the comments from Safecity (see attached document) * Review my response and confirm they are Ok or comment on them I believe it is worth answering quickly to this first set of comments to demostrate responsiveness to UC projects inputs. Please try to provide your feedback asap, tomorrow noon at the latest. Thanks and best regards, -- Juanjo -------- Original Message -------- Subject: Re: [FI-PPP AB] SafeCity initial feedback on the High Level Description document Date: Wed, 27 Jul 2011 06:07:24 +0200 From: Juanjo Hierro <jhierro at tid.es><mailto:jhierro at tid.es> To: ab at fi-ppp.eu<mailto:ab at fi-ppp.eu> <ab at fi-ppp.eu><mailto:ab at fi-ppp.eu> CC: safecity-ptc at hi-research.eu<mailto:safecity-ptc at hi-research.eu> <safecity-ptc at hi-research.eu><mailto:safecity-ptc at hi-research.eu> Hi Peretz and Roberto, Thanks very much for your input. We promise to come back with a more detailed response later once we analyze your input document together with experts from the Cloud, Data/Context Management, I2ND and Security teams. However, let me share with you a very quick response to your comments just on my own (therefore you cannot take it as definitive): 1. On the issue about private Clouds: There is nothing in the definition of FI-WARE that prevents you to setup your own private Cloud or, more specifically, your own virtual infrastructure on the Cloud where your applications are only accessible through private, dedicated, connections. Remember that a fundamental concept in FI-WARE is that there is not "single universal FI-WARE Instance" as such. A trial in phase 2 may setup its own dedicated FI-WARE instance, although it's true that several trials may agree to share a FI-WARE Instance. As a security measure, for example, you may decide to setup your own FI-WARE Cloud Hosting Instance were you plan to host just your applications. You may also, share a FI-WARE Cloud Hosting Instance with other trials, but configure your IaaS virtual infrastructure so that your applications hosted there are only accessible through dedicated VPN connections, for example. It is up to a trial in phase 2 to decide what is the FI-WARE Instance(s) it is going to rely on and, as a consequence, who is going to play the roles of FI-WARE Instance Providers in the trial. In addition, it is up to the FI-WARE Instance Provider to determine how a given FI-WARE Instance is setup and configured. Besides, it is up to the Application Provider to decide what sort of virtual infrastructure it wants to setup to host its applications. As an example, you may setup in your trial a FI-WARE Instance that includes Cloud Hosting capabilities and allows to setup virtual hosting infrastructures that host applications only available through VPNs or even more private/dedicated connections. All concepts regarding FI-WARE Instances, FI-WARE Instance Providers, etc were defined in the "FI-WARE Overall Vision" chapter. Nevertheless, your comment raise the fact that some of the explanations we have provided are not that clear and that is what really matters (like when you compare Quality of Experience vs Quality of Service :-) We were finishing integration of the official deliverable and expecting to get it done by today, a little bit late compared to what it was expected, but I believe that is worth trying to introduce the necessary changes that may clarify this matter. Of course, we will not be able to solve all the questions. We plan to continuously enhance the description, as comments like yours arrive and are handled. I take the opportunity to clarify that the kind of advanced features we described in the Cloud Hosting and the I2ND chapters related to dynamic management of network resources are mostly oriented to go beyond existing Cloud hosting services in order to take the most of available network resources, being able to use spare network resources (capacity) when they exist. Currently, you can setup a VPN to your application hosted in the Cloud, but your connection has a established bandwidth and doesn't change so dynamically. As a consequence, if your application is not using the whole bandwith during a certain period of time, another application you may own cannot use the spare bandwith and increase its VPN bandwidth during the period (both VPNs may have been setup through the same physical, private communication line). Essentially, we are trying to have more dynamic solutions here and translate the same kind of concepts used in current Clouds regarding management of computing resources to network resources. But this is something that goes beyond your most critical need, which would be that of creating private Clouds or, more specifically, Clouds accessible through virtual private connections. There, I can assure you that you would get your requirement fulfilled as explained above. I believe it was inherent in the description of the Cloud Hosting chapter since we describe there that VPNs, etc may be part of the IaaS virtual infrastructure you may define for your application (this is referred as the IaaS Service Manifest). However, it seems like we just need to state that more explicitly because apparently you derived that setting up private Clouds where applications are accessible through dedicated virtual private connections was not possible, and that is wrong. 2. On the issue about multi-media analysis: As you explain in your document, there are multiple ways to solve an scenario like the one you describe. But precisely that is the point. FI-WARE is a general purpose platform, therefore, it doesn't dictate neither how a particular FI-WARE Instance has to be setup for a particular trial, nor how applications will be designed to use that FI-WARE Instance. We follow here a fundamental principle in design of general-purpose platforms: if you take many decisions on behalf of the application designer and provider, you will end up taking the worst ones. The two possible solutions you describe for your scenario can be programmend to run on FI-WARE Instances. Both. It is up to you to decide what is the one that better suites your needs. I have to say that you mention in your document that while the two solutions are valid, the second one would be safer (although less efficient). I have to comment that it really depends on how you decide to setup your FI-WARE Instance: * You may decide that your application will be hosted in a dedicated FI-WARE Instance. Therefore, there is no risk that third-party applications can access information gathered by your application. As such, there is nothing that prevents you to set up your own FI-WARE Instance hosting the multimedia analysis GE, together with the DB of faces, and your own application in a safe way. Again, the point is that this would be up to you. Note that, in addition, you would be able to setup the Security Monitoring GE in that FI-WARE instance, which may help you to monitor and handle any security attack that you may receive. But this would go in addition. * A slight variation of the previous configuration would be that of keeping your application in a shared FI-WARE Instance supporting Cloud Hosting capabilities, then configuring your virtual hosting infrastructure so that resources (computing, storage, network) are not shared with those from other applications (in other words, you setup your own VDC, and establish a number of RA-SLOs establishing restrictions such as your software/data is never going to run on a server node where third party applications may be co-located to run). Of course, this option is more risky than the previous, because the more isolated your resources are, the safer. But should be safe anyway. And again, the point is that this would be up to you. Same comment regarding benefits of the Security monitoring capabilities would apply here. The second solution would probably be the best one if you decide to run the multimedia analysis GE in a FI-WARE Instance and you don't want to setup restriction on whether your application can be reallocated together with those from others. In this solution, you have decided to adopt a design decision that allows to take advantage of sharing resources in a FI-WARE Instance, but still be safe. Again, it is up to you to go for this option and FI-WARE should not preclude you to do that. 3. Bottom-line: There are many decisions that you should leave on the hands of application provider or the application developer when you design a general-purpose platform. Otherwise, you are doing things wrong and you are going to fail. We have tried to follow this principle as much as possible, not only in the design of GEs and the Reference Architecture of each of the FI-WARE chapters but also introducing the concept of FI-WARE Instances that can be federated (or not, depends on the decision of a particular FI-WARE Instance Provider). That's why there is no concept of single, universal FI-WARE Instance (like google.com) where all Future Internet applications would be hosted. The ability to create dedicated FI-WARE Instances, and even use multiple FI-WARE chapter instances, where some might be shared while others won't in a kind of hybrid solution, brings the greatest flexibility to be able to cope with the needs of almost all applications. Needs that we cannot predict in advance. We may have decided that all data/context elements interchanged through the Publish/Subscribe Broker GE or processed through the Complex Event Processing GE should comply to a particular XML document format we may dictate a standard in FI-WARE. That had made our lifes easier at the implementation phase as you may imagine. But this had been a wrong decission because many applications wish to be free to decide what concrete format to use. Therefore, we decided that data/context elements can follow any format a given application may decide to adopt and that the Data/Context Management GEs should be able to cope with any of them, without this meaning that you pay a performance penalty. This is the kind of design decisions we believe we also have to adopt at the level of GEs, in addition to the principles about FI-WARE Instances and federation of FI-WARE Instances. BTW, I'm almost positive that the Complex Event Processing or the Publish/Subscribe Broker GEs are some of the GEs that would be rather useful for the kind of applications you need to design in Safecity (and I'm almost positive that they will be useful for most of the UC projects because they are truly generic). I guess you will have to deal with events and the need to process them or broadcast them to target applications or users. I would like to learn why you find the multimedia analysis GE useful but not these other two. UC projects should provide a rationale why they plan to use a specific enabler in those cases there is a GE provided by FI-WARE that already serves their needs. Otherwise, this would go against the spirit of the FI-PPP program. Best regards, -- Juanjo On 26/07/11 11:01, Peretz Gurel wrote: Dear FI-PPP AB partners, The attached short document is an initial feedback (at a high level) by SafeCity about the FI-WARE High Level Description document that was presented during the last FI-PPP AB meeting on July 11-12 in Madrid. We have already raised these concerns during the meeting. After the FI-PPP AB meeting we met with one of SafeCity end users (Madrid Police) and they have confirmed the concerns we had. The attached document is not replacing SafeCity requirements for Generic Enablers that will be provided in the required backlog format in due time. However, it is very important for us to understand the direction that FI-WARE is taking, particularly in regard to communications and security, as this has direct impact on SafeCity. Best regards, Peretz Gurel and Roberto Gavazzi SafeCity ________________________________ 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/fiware-wpl/attachments/20110728/29917378/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Safecity feedback V1.doc Type: application/msword Size: 3558400 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-wpl/attachments/20110728/29917378/attachment.doc> -------------- next part -------------- A non-text attachment was scrubbed... Name: jhierro.vcf Type: text/x-vcard Size: 429 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-wpl/attachments/20110728/29917378/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy