Dear Calin, All, please take my apologies for not scheduling the meeting today. I forgot to send the MR in the due time and I was not online today morning to do it on short term. Let¡¯s consolidate the inputs first and discuss next actions in the regular call on Friday. With respect to the GEs in T3.1 (see Calin¡¯s mail below), of course, you can specify GEs where appropriate, but you do not need to do so for each and every component and technology. If you identify a functional component that has the quality to become GE specify it as GE. All the other functional components representing a specific solution (i.e., one of many alternatives with similar functionality but different interfaces, languages, etc.) should be described as examples of composition and mashup technologies integrated into the FI-WARE platform. BR, Andreas From: Calin Curescu [mailto:calin.curescu at ericsson.com] Sent: Dienstag, 21. Juni 2011 10:31 To: Horst.Stein at telekom.de; jsoriano at fi.upm.es; jesus.gorronogoitia at atosresearch.eu; chatelp at gmail.com; Friesen, Andreas; Tim.Jonischkat at paluno.uni-due.de; marco.ughetti at telecomitalia.it; Haller, Stephan; rfernandez at fi.upm.es; Magerkurth, Carsten; :; Andreas.Grothe at telekom.de; 'fiware-apps at lists.fi-ware.eu' Subject: No T3 meeting today 10-12 Dear all, There will be no meeting today 10-12. Andreas talked about the possibility to have one last Friday, but in the end it was not possible to schedule one (I just talked to him). (I sent also to FI-WARE APPS list. Who can tell me the composition of the list?) BR, /Calin From: Calin Curescu Sent: den 20 juni 2011 11:34 To: Calin Curescu; 'Horst.Stein at telekom.de'; 'jsoriano at fi.upm.es'; 'jesus.gorronogoitia at atosresearch.eu'; 'chatelp at gmail.com'; 'andreas.friesen at sap.com'; 'Tim.Jonischkat at paluno.uni-due.de'; 'marco.ughetti at telecomitalia.it'; 'stephan.haller at sap.com'; 'rfernandez at fi.upm.es'; 'carsten.magerkurth at sap.com'; ':'; 'Andreas.Grothe at telekom.de'; Ioannis Fikouras Subject: T3.1 & Generic enablers Dear all, I think we should also have a discussion on the generic enabler relevance. I was thinking about it and I want to pick it up since: a) Creating compositions/mashups are a central part of the FI-WARE influencing all the other parts. b) Out of the definition if GE in the DOW: ¡°¡.the chapter linked to Data/Context Management Services. This chapter may comprise some sort of GE that allows compilation and storage of massive data from disparate sources. Note that this GE may in turn be based on a number of GEs, each specialized in gathering data from a specific source (e.g., data from connected ¨Dthings¡¬, data obtained from user devices, data provided by the user, data exported by applications, etc.)¡. I really don¡¯t see any difference between this and how our aggregation/mediation technologies are structured. BR, /Calin From: Calin Curescu Sent: den 20 juni 2011 08:44 To: Horst.Stein at telekom.de; jsoriano at fi.upm.es; jesus.gorronogoitia at atosresearch.eu; chatelp at gmail.com; andreas.friesen at sap.com; Tim.Jonischkat at paluno.uni-due.de; marco.ughetti at telecomitalia.it; stephan.haller at sap.com; rfernandez at fi.upm.es; carsten.magerkurth at sap.com; :; Andreas.Grothe at telekom.de; Ioannis Fikouras Subject: RE: T3.1 Architecture document Dear all, Please find attached the architecture description document. Please send me your comments by 15.00 today to be merged back in the version I send to Andreas to submit. Best regards, /Calin From: Calin Curescu Sent: den 10 juni 2011 02:22 To: Horst.Stein at telekom.de; jsoriano at fi.upm.es; jesus.gorronogoitia at atosresearch.eu; chatelp at gmail.com; andreas.friesen at sap.com; Tim.Jonischkat at paluno.uni-due.de; marco.ughetti at telecomitalia.it; stephan.haller at sap.com; rfernandez at fi.upm.es; carsten.magerkurth at sap.com; :; Andreas.Grothe at telekom.de; Ioannis Fikouras Subject: T3.1 Architecture meeting summary Dear all, Please find next the summary from today's meeting. I have also updated the architecture image. I also include hare the latest version of the M2 document that we need to edit. All the description up to USDL are part of task 3.1. Since the Sections and subsections were structured only the early input from DT, UPM I made a some new sections from scratch, and the idea is that everybody is editing in the sections that are relevant to them / their assets by mid next week (you might want to decide the deadline with Andreas tomorrow). Obs: the rest of the document is somehow formatted in the description, so we could use a similar approach. Best regards, /Calin T3.1 Architecture meeting summary: FI-WARE task 3.1 Architecture meeting. Participants: Calin Curescu (Ericsson) Horst Stein (DT) Bettina Lehmann (DT) Andreas Grothe (DT) Pierre Chatel (THALES) Andreas Friesen (SAP) Tim Jonischkat (DU) Marco Ughetti (TI) Stephan Haller (SAP) Rafael Fernandez (UPM) Yosu Gorronogoitia (ATOS) - Yosu could not participate in the meeting, but we had a discussion later during the day. - Calin Curescu started to present the architecture for the high components (GEs) in task 3.1, which are the "Aggregator" and the "Mediator" and also the "Channel Maker" from task 3.4. The slides started from the idea that the Channel maker was relevant to the Mashup/Composition theme since important components used in the creation of user-side application gadgets (by mashing up UIs with data transformation and backend service connection) are part of the "Channel Maker" architecture. UPM (the main interested in application creation and mashup) soon made it clear that gadget creation is out of scope, and their main focus is on the application mashup (EzWeb). The "Channel Maker" might become part of an open call. As result of this Calin Will update the slides accordingly. - It was also discussed that while the USDL Registry and Repository can hold and provide the business aspects of services, there is the need for another registry component inside the Aggregator GE to hold the the technical descriptions of the services together with the composition description (i.e. the BPEL process, or the application mashup described in the MDL, or the Ericsson composition skeletons). - The main compontents of the Aggregator are the "Composition Editor" and the "Execution Engine". As already presented in the DoW there are two types of aggregation we address: the composition of backend services and the mashup of front-end applications (gadgets), however both need an editor for the aggregation and a runtime to instatiate it. This also means that these GEs will comprise a number of different complementary components (e.g. like the Compsition Studio (DT), mashup engine (UPM), Composition IDE (Ericsson) or Onyx editor (Atos)). The same is valid for the execution engines (e.g. BPEL orchestraton (DT), mashup container platform (UPM), event-driven orchestration (Ericsson), BPMN/BPEL orchestration (Atos)). - Finally there are three types of mediation functions that can be part of a mediator GE - data mediation (where compatible forms of data can be translated to each oter, e.g. mainly EDI functonality), protocol mediation (that helps service components with APIs exposed by different protocols to communicate, and process mediation - that translates or refines processes to be run in the execution engine). - A discussion started if it is needed to have the mediator as an explicit generic enabler. Pierre Chatel (THALES) explained that their work on the 3 functionality types presented above will result in a lower level library to be used by other enablers (e.g. by an execution engine) for high dynamicity cases, and not in a mediator (or gateway) component. Marco (TI) suggested tha part of the TI enterprise service bus (ESB) could play the mediator role. However it was not clear what functionality the TI mediator could provide and Marco agreed to pepare 1-2 slides detailing their contribution in task 3.1. ATOS is providing a component for the adaptive parametric automation of common modelling tasks at design time, i.e BPMN -> BPEL processes. This seems to fit very much in the process mediator functionality. Ericsson is providing the WebCommunication component that will help compose front end gadgets also across different device/browser boundaries. This amounts to a protocol mediation component. Also Ericsson as part of their composition/orchestration engine provides a multitude of protocol adaptations (REST, SOAP, SIP, RMI, JS, etc.) - SAP works on a Process Modelling and Language Extensions for IoT. This has a lot to do with the Execution/orchestration engine and they will provide a description in that section. - DT in their asset achitecture have a "user management" component however this service fits better the enablers in WP9: Security, privacy, Trust. Other components in DT arch. such as Deployment UI and Dialog Creator represent more generic services that do not have a direct enabler correspondence. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-apps/attachments/20110621/d80a6ce2/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy