Dear friends,
please, take a look at the minutes of the yesterday WPLs/WPAs joint conf
call.
ciao,
Davide
-------- Original Message --------
Subject: [Fiware-wpa] Notes from last joint WPLs/WPAs confcall
Date: Tue, 20 Dec 2011 10:17:32 +0100
From: Juanjo Hierro <jhierro at tid.es>
To: fiware-wpl at lists.fi-ware.eu <fiware-wpl at lists.fi-ware.eu>,
fiware-wpa at lists.fi-ware.eu <fiware-wpa at lists.fi-ware.eu>
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
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/old-fiware-tools/attachments/20111220/10cd2021/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Attached Message Part
URL: <https://lists.fiware.org/private/old-fiware-tools/attachments/20111220/10cd2021/attachment.ksh>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy