From mach at zhaw.ch Fri Sep 19 12:07:53 2014 From: mach at zhaw.ch (Marti Christof (mach)) Date: Fri, 19 Sep 2014 10:07:53 +0000 Subject: [Miwi-middleware] Weekly meeting Message-ID: <713A5ABA-07DE-42C7-8039-147EFED997B9@zhaw.ch> Hi everybody I plan to have a weekly meeting today at 13:00. No agenda yet. Main topics will be how to organise the remaining deliverables and the handover to FI-Core. Christof From mach at zhaw.ch Fri Sep 19 13:19:18 2014 From: mach at zhaw.ch (Christof Marti) Date: Fri, 19 Sep 2014 13:19:18 +0200 Subject: [Miwi-middleware] Weekly meeting In-Reply-To: <55aeb0494ec24fa391477ec02a2dc1c5@SRV-MAIL-001.zhaw.ch> References: <55aeb0494ec24fa391477ec02a2dc1c5@SRV-MAIL-001.zhaw.ch> Message-ID: <8BBA8F0B-8460-4AA7-8AF3-7DD3E3112450@zhaw.ch> Sorry for the delay Here ist the hangout: https://plus.google.com/hangouts/_/gvul3ij4tgtwlkiyyzyosyswpaa?hl=de Christof > On 19.09.2014, at 12:07, Marti Christof (mach) wrote: > > Hi everybody > > I plan to have a weekly meeting today at 13:00. > No agenda yet. Main topics will be how to organise the remaining deliverables and the handover to FI-Core. > > Christof > > > > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware From rubinstein at cs.uni-saarland.de Mon Sep 22 13:09:52 2014 From: rubinstein at cs.uni-saarland.de (Dmitri Rubinstein) Date: Mon, 22 Sep 2014 13:09:52 +0200 Subject: [Miwi-middleware] KIARA/Java on github Message-ID: <54200380.9080701@cs.uni-saarland.de> I just made KIARA/Java v0.1 available on the github: https://github.com/dmrub/kiara-java License: LGPL version 3 Current features: Supported transports: HTTP 1.1, TCP Block Transport Supported protocols: JSON RPC 2.0, JavaObjectStream (Java serialization) JSON RPC 2.0, HTTP 1.1 and TCP Block Transport are compatible to the KIARA C/C++ version. Example applications are in: ./KIARA/src/test/java/de/dfki/kiara/test/AosTest.java Best, Dmitri From JaimeMartin at eprosima.com Mon Sep 22 15:37:59 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Mon, 22 Sep 2014 13:37:59 +0000 Subject: [Miwi-middleware] KIARA/Java on github In-Reply-To: <54200380.9080701@cs.uni-saarland.de> References: <54200380.9080701@cs.uni-saarland.de> Message-ID: <0a36165dba0e4022a13b66c48ea072ee@AM3PR06MB337.eurprd06.prod.outlook.com> Dmitri, we are not going to make the same mistake twice. First we have to define what we want to do, an API that should be externally approved, the different modules, and then start to assign tasks. Don't start just writing code without any design consensus and later try the other parties to follow you. Regards, Jaime. -----Original Message----- From: miwi-middleware-bounces at lists.fi-ware.org [mailto:miwi-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri Rubinstein Sent: lunes, 22 de septiembre de 2014 13:10 To: KIARA Mailing List Subject: [Miwi-middleware] KIARA/Java on github I just made KIARA/Java v0.1 available on the github: https://github.com/dmrub/kiara-java License: LGPL version 3 Current features: Supported transports: HTTP 1.1, TCP Block Transport Supported protocols: JSON RPC 2.0, JavaObjectStream (Java serialization) JSON RPC 2.0, HTTP 1.1 and TCP Block Transport are compatible to the KIARA C/C++ version. Example applications are in: ./KIARA/src/test/java/de/dfki/kiara/test/AosTest.java Best, Dmitri _______________________________________________ Miwi-middleware mailing list Miwi-middleware at lists.fi-ware.org https://lists.fi-ware.org/listinfo/miwi-middleware ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: 09/08/14 Internal Virus Database is out of date. From philipp.slusallek at dfki.de Mon Sep 22 16:06:41 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Mon, 22 Sep 2014 16:06:41 +0200 Subject: [Miwi-middleware] KIARA/Java on github In-Reply-To: <0a36165dba0e4022a13b66c48ea072ee@AM3PR06MB337.eurprd06.prod.outlook.com> References: <54200380.9080701@cs.uni-saarland.de> <0a36165dba0e4022a13b66c48ea072ee@AM3PR06MB337.eurprd06.prod.outlook.com> Message-ID: <54202CF1.20505@dfki.de> Hi Jaime, Java was important for us before and Dmitri has worked on this implementation for quite some time now. we are ualready sing this now for another project. But changing it for better versions is always a good thing and we are very open for it. Please do not blame us for having already done some of the work that is now becoming relevant also for the project as a whole. You/we do not have to use this directly, but I see this as an interesting basis that we can use as a starting point for our discussions. This is why we are making it available for all to look at (and please do so). Having something that is already working and is already compatible with our previous work is (at least from my point of view) a better place to start than a blank page. I hope you and others agree. As in the C/C++ version we are very open to suggestions and alternative interfaces and implementations. So please feel free to suggest those, ideally directly with your implementation. Fortunately, we will not have the C/C++ issues, so we should be in a much better place to collaborate based on comparing each of our concepts and actual implementations of them. I am looking forward to a closer collaboration within FI-Core. BTW, at the Kickoff you have apparently developed a document describing how you (as in KIARA group) would want o work together. We have not been in the loop and so it would be good to get that document, so we are able to comment (and hopefully just agree to it). Best, Philipp Am 22.09.2014 um 15:37 schrieb Jaime Martin Losa: > Dmitri, we are not going to make the same mistake twice. > > First we have to define what we want to do, an API that should be externally approved, the different modules, and then start to assign tasks. > > Don't start just writing code without any design consensus and later try the other parties to follow you. > > Regards, > Jaime. > > > -----Original Message----- > From: miwi-middleware-bounces at lists.fi-ware.org [mailto:miwi-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri Rubinstein > Sent: lunes, 22 de septiembre de 2014 13:10 > To: KIARA Mailing List > Subject: [Miwi-middleware] KIARA/Java on github > > I just made KIARA/Java v0.1 available on the github: > > https://github.com/dmrub/kiara-java > > License: LGPL version 3 > > Current features: > > Supported transports: HTTP 1.1, TCP Block Transport > > Supported protocols: JSON RPC 2.0, JavaObjectStream (Java serialization) > > JSON RPC 2.0, HTTP 1.1 and TCP Block Transport are compatible to the KIARA C/C++ version. > > Example applications are in: > ./KIARA/src/test/java/de/dfki/kiara/test/AosTest.java > > Best, > > Dmitri > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: 09/08/14 Internal Virus Database is out of date. > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From JaimeMartin at eprosima.com Mon Sep 22 16:15:57 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Mon, 22 Sep 2014 14:15:57 +0000 Subject: [Miwi-middleware] KIARA/Java on github In-Reply-To: <54202CF1.20505@dfki.de> References: <54200380.9080701@cs.uni-saarland.de> <0a36165dba0e4022a13b66c48ea072ee@AM3PR06MB337.eurprd06.prod.outlook.com> <54202CF1.20505@dfki.de> Message-ID: Hi Philipp, This time we are going to start with the design, and not with the code, and this design should be externally approved. Yes we should start with a blank page. We didn't developed any document. Basically the Java Idea and the external audit has come from Juanjo. We are working now in a proposal (design, spec) of API. Next Friday meeting, we should start talking about the first design tasks of JAVA KIARA. Our main goal should be the usability, because we need something stable and easy within one year. Regards, Jaime. -----Original Message----- From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] Sent: lunes, 22 de septiembre de 2014 16:07 To: Jaime Martin Losa; Dmitri Rubinstein; KIARA Mailing List Subject: Re: [Miwi-middleware] KIARA/Java on github Hi Jaime, Java was important for us before and Dmitri has worked on this implementation for quite some time now. we are ualready sing this now for another project. But changing it for better versions is always a good thing and we are very open for it. Please do not blame us for having already done some of the work that is now becoming relevant also for the project as a whole. You/we do not have to use this directly, but I see this as an interesting basis that we can use as a starting point for our discussions. This is why we are making it available for all to look at (and please do so). Having something that is already working and is already compatible with our previous work is (at least from my point of view) a better place to start than a blank page. I hope you and others agree. As in the C/C++ version we are very open to suggestions and alternative interfaces and implementations. So please feel free to suggest those, ideally directly with your implementation. Fortunately, we will not have the C/C++ issues, so we should be in a much better place to collaborate based on comparing each of our concepts and actual implementations of them. I am looking forward to a closer collaboration within FI-Core. BTW, at the Kickoff you have apparently developed a document describing how you (as in KIARA group) would want o work together. We have not been in the loop and so it would be good to get that document, so we are able to comment (and hopefully just agree to it). Best, Philipp Am 22.09.2014 um 15:37 schrieb Jaime Martin Losa: > Dmitri, we are not going to make the same mistake twice. > > First we have to define what we want to do, an API that should be externally approved, the different modules, and then start to assign tasks. > > Don't start just writing code without any design consensus and later try the other parties to follow you. > > Regards, > Jaime. > > > -----Original Message----- > From: miwi-middleware-bounces at lists.fi-ware.org > [mailto:miwi-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri > Rubinstein > Sent: lunes, 22 de septiembre de 2014 13:10 > To: KIARA Mailing List > Subject: [Miwi-middleware] KIARA/Java on github > > I just made KIARA/Java v0.1 available on the github: > > https://github.com/dmrub/kiara-java > > License: LGPL version 3 > > Current features: > > Supported transports: HTTP 1.1, TCP Block Transport > > Supported protocols: JSON RPC 2.0, JavaObjectStream (Java > serialization) > > JSON RPC 2.0, HTTP 1.1 and TCP Block Transport are compatible to the KIARA C/C++ version. > > Example applications are in: > ./KIARA/src/test/java/de/dfki/kiara/test/AosTest.java > > Best, > > Dmitri > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: 09/08/14 Internal Virus Database is out of date. > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: 09/08/14 Internal Virus Database is out of date. From thomas.bohnert at zhaw.ch Tue Sep 23 12:19:40 2014 From: thomas.bohnert at zhaw.ch (Thomas Michael Bohnert) Date: Tue, 23 Sep 2014 12:19:40 +0200 Subject: [Miwi-middleware] KIARA/Java on github In-Reply-To: References: <54200380.9080701@cs.uni-saarland.de> <0a36165dba0e4022a13b66c48ea072ee@AM3PR06MB337.eurprd06.prod.outlook.com> <54202CF1.20505@dfki.de> Message-ID: <5421493C.2060909@zhaw.ch> Dear all, Nice to see that there is so much energy behind our proposal to start over with a Java version. If we continue like that there will be soon a very nice product that serves the needs of our primary customers - that is the FIWARE community. About the next steps. First, we need to complete the hand-over from MIWI to I2ND. This includes all the stuff agreed upon during the WPL/WPA meetings, like new mailing lists, etc. But this is mostly admin stuff. One item is the weeky KIARA meeting. This is now linked to Task 1.8.3 and to be taken over by eProsima (Jaime?). That means to prepare agendas in advance, take minutes, record action items, report to the WPA/WPL, and any other task related to the task leadership. Regarding the technical directions to be taken. Agreement is to put ALL existing implementations on hold and to start over with the JAVA version. Starting point is a blank page but we will carefully analyze existing code once we have agreed on the design, i.e. issues first and foremost the KIARA API. About the KIARA API. Here the most important issue is to define an API that meets the expectations of professional software developers. Since we have very good expertises in the team, with a broad spectrum of know-how and experiences we need to find a way to consolidate this into one approach and ultimately specification. One element in achieving this is to consult an external expert that will take a fresh and independent view on things and thus secure a design that meets this requirement. The exact candidate is not yet decided (do you have proposals?) but there is already one person we know about and we currently are contacting. Action items: Jaime - please prepare an agenda for coming Friday meeting, share it at least a day before with the team such that we can add items to the agenda in advance. We will discuss any aspect in next Friday's meeting, that is technical aspects as well as implementation and procedures on task level. Thanks for your contributions and commitment in advance! Christof and Thomas On 09/22/2014 04:15 PM, Jaime Martin Losa wrote: > Hi Philipp, > > This time we are going to start with the design, and not with the code, and this design should be externally approved. Yes we should start with a blank page. > > We didn't developed any document. Basically the Java Idea and the external audit has come from Juanjo. > > We are working now in a proposal (design, spec) of API. Next Friday meeting, we should start talking about the first design tasks of JAVA KIARA. > > Our main goal should be the usability, because we need something stable and easy within one year. > > Regards, > Jaime. > > > -----Original Message----- > From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] > Sent: lunes, 22 de septiembre de 2014 16:07 > To: Jaime Martin Losa; Dmitri Rubinstein; KIARA Mailing List > Subject: Re: [Miwi-middleware] KIARA/Java on github > > Hi Jaime, > > Java was important for us before and Dmitri has worked on this implementation for quite some time now. we are ualready sing this now for another project. But changing it for better versions is always a good thing and we are very open for it. > > Please do not blame us for having already done some of the work that is now becoming relevant also for the project as a whole. > > You/we do not have to use this directly, but I see this as an interesting basis that we can use as a starting point for our discussions. This is why we are making it available for all to look at (and please do so). > > Having something that is already working and is already compatible with our previous work is (at least from my point of view) a better place to start than a blank page. I hope you and others agree. > > As in the C/C++ version we are very open to suggestions and alternative interfaces and implementations. So please feel free to suggest those, ideally directly with your implementation. Fortunately, we will not have the C/C++ issues, so we should be in a much better place to collaborate based on comparing each of our concepts and actual implementations of them. > > I am looking forward to a closer collaboration within FI-Core. > > BTW, at the Kickoff you have apparently developed a document describing how you (as in KIARA group) would want o work together. We have not been in the loop and so it would be good to get that document, so we are able to comment (and hopefully just agree to it). > > > Best, > > Philipp > > > > > Am 22.09.2014 um 15:37 schrieb Jaime Martin Losa: >> Dmitri, we are not going to make the same mistake twice. >> >> First we have to define what we want to do, an API that should be externally approved, the different modules, and then start to assign tasks. >> >> Don't start just writing code without any design consensus and later try the other parties to follow you. >> >> Regards, >> Jaime. >> >> >> -----Original Message----- >> From: miwi-middleware-bounces at lists.fi-ware.org >> [mailto:miwi-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri >> Rubinstein >> Sent: lunes, 22 de septiembre de 2014 13:10 >> To: KIARA Mailing List >> Subject: [Miwi-middleware] KIARA/Java on github >> >> I just made KIARA/Java v0.1 available on the github: >> >> https://github.com/dmrub/kiara-java >> >> License: LGPL version 3 >> >> Current features: >> >> Supported transports: HTTP 1.1, TCP Block Transport >> >> Supported protocols: JSON RPC 2.0, JavaObjectStream (Java >> serialization) >> >> JSON RPC 2.0, HTTP 1.1 and TCP Block Transport are compatible to the KIARA C/C++ version. >> >> Example applications are in: >> ./KIARA/src/test/java/de/dfki/kiara/test/AosTest.java >> >> Best, >> >> Dmitri >> _______________________________________________ >> Miwi-middleware mailing list >> Miwi-middleware at lists.fi-ware.org >> https://lists.fi-ware.org/listinfo/miwi-middleware >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: 09/08/14 Internal Virus Database is out of date. >> _______________________________________________ >> Miwi-middleware mailing list >> Miwi-middleware at lists.fi-ware.org >> https://lists.fi-ware.org/listinfo/miwi-middleware >> > > From philipp.slusallek at dfki.de Tue Sep 23 23:32:49 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Tue, 23 Sep 2014 23:32:49 +0200 Subject: [Miwi-middleware] KIARA/Java on github In-Reply-To: References: <54200380.9080701@cs.uni-saarland.de> <0a36165dba0e4022a13b66c48ea072ee@AM3PR06MB337.eurprd06.prod.outlook.com> <54202CF1.20505@dfki.de> Message-ID: <5421E701.10000@dfki.de> Hi Jaime, all, I my email I was referring to the document that Thomas mentioned in Munich. @Thomas, is the document (which summarizes how you discussed to work together) available anywhere yet? As you know due to my duties as Chapter Lead of Ch. 1.5 I was not able to attend the meetings of Ch. 1.8. So far I have got very little information about what was discussed. Maybe this is were some of the differences come from. First of all, let me say that I fully support to start with the design and its great that you started working on describing yours. Let me assure you that we -- also -- have done a careful design for the C/C++ version already. We have actually presented and explained that design in pretty much detail and multiple times in our previous meetings. So at least for us, I see no reason to throw that away and start with a blank page. Actually, our original C/C++ ideas translated almost directly and without any issues into Java with only minor changes due to language differences. Having a full implementation of the Java design already has helped us verify that these design decisions are actually sound and can be implemented well. In the attached document (mostly be Dmitri) you find a short description and rational of the design used in our current Java implementation. This is a first version of the document. We plan to extend this with more in-depth rational of the design decisions for the external reviewer. But this should be enough for the internal discussions as we have just recently discussed our rationals with you in Madrid. Let me make some remarks, with respect to usability as I expect that to come up in the discussions: First of all, we are assuming that an explicit definition of the remote interfaces in the form of an IDL is useful (some middleware avoids that). I believe we agree on this choice. We could, but consciously do not, generate this IDL implicitly and automatically from the (Java) code as done in some other systems -- mainly for good SW design reasons. However, if we determine that this functionality should (optionally?) be added, this could easily be done through the registerServiceFunction() call (through introspection on the interface object). This is also possible in the C/C++ version. Note that the only differences to a traditional middleware API are steps 2/3 (on the client side). This is the key parts that allow KIARA to use the native data types of the application and adapt its communication layer dynamically. Step 2 could even be made optional, in cases where only a direct mapping from native to IDL data types should be allowed (as in traditional middleware, but KIARA would still allow to adapt dynamically to different protocols even in this case, etc.). Additionally, instead of returning (at run-time) some optimized and generated code through generateClientFunctions(), this could also return a pre-compiled (or cached?) interface function or a function that uses an interpreter to map the native data to the protocol when connecting. Note that the above mechanism is also used for implementing the advanced security features of KIARA, that seem to be largely ignored in this type of discussions. So, I hope that it becomes clear that there are actually few differences and that the existing differences are there are for very good reasons. They enable use to provide the advanced functionality of KIARA that is simply not possible in traditional middleware (at least we have not found better alternatives, yet). Suggestions are welcome! Again, let me make absolutely clear that this is just our idea for the design of a unified Java Middleware API. It just happens to be already implemented as well. But implementations can always be changed as we come up with better alternatives! We would be more than happy to hear about alternative designs and their rational so we can then discuss the pros and cons of each. Best, Philipp Am 22.09.2014 um 16:15 schrieb Jaime Martin Losa: > Hi Philipp, > > This time we are going to start with the design, and not with the code, and this design should be externally approved. Yes we should start with a blank page. > > We didn't developed any document. Basically the Java Idea and the external audit has come from Juanjo. > > We are working now in a proposal (design, spec) of API. Next Friday meeting, we should start talking about the first design tasks of JAVA KIARA. > > Our main goal should be the usability, because we need something stable and easy within one year. > > Regards, > Jaime. > > > -----Original Message----- > From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] > Sent: lunes, 22 de septiembre de 2014 16:07 > To: Jaime Martin Losa; Dmitri Rubinstein; KIARA Mailing List > Subject: Re: [Miwi-middleware] KIARA/Java on github > > Hi Jaime, > > Java was important for us before and Dmitri has worked on this implementation for quite some time now. we are ualready sing this now for another project. But changing it for better versions is always a good thing and we are very open for it. > > Please do not blame us for having already done some of the work that is now becoming relevant also for the project as a whole. > > You/we do not have to use this directly, but I see this as an interesting basis that we can use as a starting point for our discussions. This is why we are making it available for all to look at (and please do so). > > Having something that is already working and is already compatible with our previous work is (at least from my point of view) a better place to start than a blank page. I hope you and others agree. > > As in the C/C++ version we are very open to suggestions and alternative interfaces and implementations. So please feel free to suggest those, ideally directly with your implementation. Fortunately, we will not have the C/C++ issues, so we should be in a much better place to collaborate based on comparing each of our concepts and actual implementations of them. > > I am looking forward to a closer collaboration within FI-Core. > > BTW, at the Kickoff you have apparently developed a document describing how you (as in KIARA group) would want o work together. We have not been in the loop and so it would be good to get that document, so we are able to comment (and hopefully just agree to it). > > > Best, > > Philipp > > > > > Am 22.09.2014 um 15:37 schrieb Jaime Martin Losa: >> Dmitri, we are not going to make the same mistake twice. >> >> First we have to define what we want to do, an API that should be externally approved, the different modules, and then start to assign tasks. >> >> Don't start just writing code without any design consensus and later try the other parties to follow you. >> >> Regards, >> Jaime. >> >> >> -----Original Message----- >> From: miwi-middleware-bounces at lists.fi-ware.org >> [mailto:miwi-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri >> Rubinstein >> Sent: lunes, 22 de septiembre de 2014 13:10 >> To: KIARA Mailing List >> Subject: [Miwi-middleware] KIARA/Java on github >> >> I just made KIARA/Java v0.1 available on the github: >> >> https://github.com/dmrub/kiara-java >> >> License: LGPL version 3 >> >> Current features: >> >> Supported transports: HTTP 1.1, TCP Block Transport >> >> Supported protocols: JSON RPC 2.0, JavaObjectStream (Java >> serialization) >> >> JSON RPC 2.0, HTTP 1.1 and TCP Block Transport are compatible to the KIARA C/C++ version. >> >> Example applications are in: >> ./KIARA/src/test/java/de/dfki/kiara/test/AosTest.java >> >> Best, >> >> Dmitri >> _______________________________________________ >> Miwi-middleware mailing list >> Miwi-middleware at lists.fi-ware.org >> https://lists.fi-ware.org/listinfo/miwi-middleware >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: 09/08/14 Internal Virus Database is out of date. >> _______________________________________________ >> Miwi-middleware mailing list >> Miwi-middleware at lists.fi-ware.org >> https://lists.fi-ware.org/listinfo/miwi-middleware >> > > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- This documents describes design ideas behind the KIARA Java API that was developed by DFKI: https://github.com/dmrub/kiara-java Our starting point was the design of the KIARA/DFKI C/C++ API, but we also took into account features specific to Java. API examples are in KIARA/src/main/java/de/dfki/kiara/example Notes: This API is the result of our internal discussions. We are always open to other ideas and would be happy to consider alternative designs (given suitable suggestions). This API design is driven by the original KIARA ideas about a unified middleware API that -- operates using the native data types of the application, -- supports several different transport mechanisms and protocols, -- supports to negotiate and select a suitable protocol/mechanims at run-time, -- can transfers data directly between the memories of the two application (e.g. by RDMA), -- allows for optimized transformation between the native data and the used protocol formats. This current Java API is designed to support Remote Procedure Call (RPC) pattern, so far. Changes to support PubSub should be minimal and are under consideration now. RDMA-like support might require a small additional API to register instances of data types with the middleware as send/receive buffers. This API is compatible with Java SE version 7 and higher. -- Client -- 1. Opening connection Like in the C++ version we start first with creating context and using it for opening the connection. A URI is used as the universal server address: Context context = Kiara.createContext(); Connection connection = context.openConnection("http://localhost:8080/service"); We assume following IDL in our example: namespace * calc " service calc { i32 add(i32 a, i32 b) float addf(float a, float b) " } After the connection has been opened: 1) An IDL provided by the server under the URL is loaded and parsed 2) The best protocol and transport available by both client and server are selected. 2. Binding Java methods to the IDL As the interface to KIARA will be in terms of the native types of the application, the next step is to bind suitable Java methods (specified/defined through Java interfaces) to the remote service methods provided by the server (and described in the IDL). Later we will invoke the bound Java methods, which will trigger the communication and execute the remote service methods on the server. In the C/C++ API we bind the interface methods to individual functions. Because Java does not support single functions (like .NET delegates or C function pointers), here we bind to methods of a Java interface: 1) User provides Java interface that corresponds to the service that he would like to call: public interface Calc { public int add(int a, int b); public float addFloat(float a, float b); } 2) User uses the generic KIARA class MethodBinding to describe which methods of the interface are bound to which service methods in the IDL provided by the server. MethodBinding binder = new MethodBinding<>(Calc.class) .bind("calc.add", "add") .bind("calc.addf", "addFloat"); The first argument to the bind method is the full name of the service, the second argument is the name of the Java interface method. The third optional variable length argument allows to pass classes in order to identify overloaded interface methods. Parameterizing MethodBinding with the interface type enables KIARA to check whether the passed interface method names are correctly typed. 3. Now the user can generate instance of the interface Calc with bindings registered with MethodBinding class: Calc calc = connection.generateClientFunctions(binder); This operation might throw an exception when the service methods registered through binder are not available in the IDL or when argument or result types are not compatible. All of the above code can easily be hiden in a setup function. Internally our implementation uses java.lang.reflect.Proxy for implementing this. 4. Once the setup it has been performed, the user can now execute remote service methods by calling the generated interface methods: { int result = calc.add(21, 32); System.out.printf("calc.add: result = %d\n", result); } 5. Finally Context and Connection can be closed with the close method: connection.close(); context.close(); A1. Note: Besides the Calc interface the object returned by generateClientFunctions() also implements KIARA's RemoteInterface interface. It can provide additional information about the remote service (e.g. the used connection): RemoteInterface ri = (RemoteInterface) calc; Connection c = ri.getConnection(); -- Server -- 1. Creating the service As in the client we use the C/C++ API as the basis: Context context = Kiara.createContext(); Service service = context.newService(); The service class represents the remote service that is provided by the server. A single server instance can provide multiple services. 2. Specifying the IDL At first user need to define what the service will provide by loading IDL: service.loadServiceIDLFromString("KIARA", "namespace * calc " + "service calc { " + " i32 add(i32 a, i32 b) " + " float addf(float a, float b) " + "} "); 3. Binding the Java class to the IDL Let's assume we are given an implementation of the service as follows: public class CalcImpl { public int add(int a, int b) { return a + b; } public float add(float a, float b) { return a + b; } } Given this implementation, the user can now create an instance of CalcImpl and bind it to the IDL: CalcImpl impl = new CalcImpl(); service.registerServiceFunction("calc.add", impl, "add", Integer.TYPE, Integer.TYPE); service.registerServiceFunction("calc.addf", impl, "addf", Float.TYPE, Float.TYPE); The first argument is the service name, the second argument is the implementation instance, the third argument is the name of the implementing method. The finally arguments provide the types of the arguments. 4. Creating the server. Again this step is similar to the C/C++ API: // Create new server on specified port and host // negotiation document with path: /service Server server = context.newServer("0.0.0.0", port, "/service"); // Register service under the relative URL "/rpc/calc" // and available via "jsonrpc" protocol. // Other options are possible as well. server.addService("/rpc/calc", "jsonrpc", service); // Run server. server.run(); 5. Finally the Context and Server objects can be closed: server.close() context.close() -- Asynchronous API -- What we described before allow us to perform synchronous API calls. However, our API is designed in such a way that no extension is required in order to call methods asynchronously. The user only needs to change signature of the interface by using java.util.concurrent.Future class. For example: public interface Calc { public Future add(int a, int b); public Future addFloat(float a, float b); } Now when we call Calc.add() or Calc.addFloat() methods we will get no immediate results but a future handle. Program execution will continue since we are not waiting for a result. A call to Future.get() will enforce immediate execution and block until result or an error arrives. The only limitation of this approach is that Future type does not support notification of the computation end. We can either block and wait for the result or check if the result is available. As an extension we also support ListenableFuture which provides support for notification callback: https://code.google.com/p/guava-libraries/wiki/ListenableFutureExplained Future-s can be used as argument and result types in both client interfaces and server implementation classes. -------------- next part -------------- A non-text attachment was scrubbed... Name: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From philipp.slusallek at dfki.de Wed Sep 24 06:39:40 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Wed, 24 Sep 2014 06:39:40 +0200 Subject: [Miwi-middleware] KIARA/Java on github In-Reply-To: <5421493C.2060909@zhaw.ch> References: <54200380.9080701@cs.uni-saarland.de> <0a36165dba0e4022a13b66c48ea072ee@AM3PR06MB337.eurprd06.prod.outlook.com> <54202CF1.20505@dfki.de> <5421493C.2060909@zhaw.ch> Message-ID: <54224B0C.2060704@dfki.de> Hi all, Sorry Thomas, for some reason I had not seen your email before I sent mine last night. Thanks for the update. Has the text you sent been agreed upon by Chapter 1.8 at the meeting in Madrid or is this more a summary of the discussions that took place at the meeting? Regarding the external expert: I believe Juanjo himself is probably one of the best experts we could find. If he suggested others, this is probably fine as well. Who is it that you are contacting now? While I very much agree (as I already told you) to focus on the Java version, I disagree strongly that we should stop all activities on the existing implementations. We must at least maintain the current technology and support it where necessary. Let's not forget that there are implementations that make active use of KIARA. They are within FI-WARE (Sync GE, CH. 1.5) as well as running demos within the FI-Content and FITMAN projects that make use of the existing KIARA GEi. Even more uses are planned within the next few months. Abandoning these fully working GEs without any technical reasons for doing so, would be damaging to FIWARE and the GE process. As you state, the Java version (especially if we start from an empty page) will take significant time to become available (you have even talked about one year). This is not acceptable for the existing users of the technology. Additionally, in those projects the C/C++ interface is needed, which would likely take even longer to become available. Also I see no impact whatsoever that the "old" implementationcould have on the new Java API. Once we have agreed on a new API for Java, it should not be too difficult to backport that to the current C/C++ version (at least if we keep that goal in mind during our discussion, which we should do anyway). Given the flexible design of current KIARA implementation, we should even be able to do so without having to abandon the current API and have them coexist for compatibility until existing users had a chance to switch over. Also there should not be any reason that the new Java version and the "old" implementations cannot interoperate, even while they are using different API approaches. So, I see also no reason that the "old" design would limit how we design the new Java API and implementation (which seems something that Jaime is very worried about). So unless someone comes up with solid technical reasons for abandoning the current work (which I cannot see and which have never been presented since we started our working on KIARA), we should refrain from suggesting to waste EU money that has been spend on the current implementations. To be clear, I am perfectly fine is focusing the current development on Java (as we have started some time ago already), I am just opposing to abandon the existing work as your text seems to suggest. Best, Philipp Am 23.09.2014 um 12:19 schrieb Thomas Michael Bohnert: > Dear all, > > Nice to see that there is so much energy behind our proposal to start > over with a Java version. If we continue like that there will be soon a > very nice product that serves the needs of our primary customers - that > is the FIWARE community. > > About the next steps. > > First, we need to complete the hand-over from MIWI to I2ND. This > includes all the stuff agreed upon during the WPL/WPA meetings, like new > mailing lists, etc. But this is mostly admin stuff. > > One item is the weeky KIARA meeting. This is now linked to Task 1.8.3 > and to be taken over by eProsima (Jaime?). That means to prepare agendas > in advance, take minutes, record action items, report to the WPA/WPL, > and any other task related to the task leadership. > > Regarding the technical directions to be taken. Agreement is to put ALL > existing implementations on hold and to start over with the JAVA > version. Starting point is a blank page but we will carefully analyze > existing code once we have agreed on the design, i.e. issues first and > foremost the KIARA API. > > About the KIARA API. Here the most important issue is to define an API > that meets the expectations of professional software developers. Since > we have very good expertises in the team, with a broad spectrum of > know-how and experiences we need to find a way to consolidate this into > one approach and ultimately specification. One element in achieving this > is to consult an external expert that will take a fresh and independent > view on things and thus secure a design that meets this requirement. The > exact candidate is not yet decided (do you have proposals?) but there is > already one person we know about and we currently are contacting. > > Action items: > Jaime - please prepare an agenda for coming Friday meeting, share it at > least a day before with the team such that we can add items to the > agenda in advance. > > We will discuss any aspect in next Friday's meeting, that is technical > aspects as well as implementation and procedures on task level. > > Thanks for your contributions and commitment in advance! > > Christof and Thomas > > On 09/22/2014 04:15 PM, Jaime Martin Losa wrote: >> Hi Philipp, >> >> This time we are going to start with the design, and not with the >> code, and this design should be externally approved. Yes we should >> start with a blank page. >> >> We didn't developed any document. Basically the Java Idea and the >> external audit has come from Juanjo. >> >> We are working now in a proposal (design, spec) of API. Next >> Friday meeting, we should start talking about the first design tasks >> of JAVA KIARA. >> >> Our main goal should be the usability, because we need something >> stable and easy within one year. >> >> Regards, >> Jaime. >> >> >> -----Original Message----- >> From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] >> Sent: lunes, 22 de septiembre de 2014 16:07 >> To: Jaime Martin Losa; Dmitri Rubinstein; KIARA Mailing List >> Subject: Re: [Miwi-middleware] KIARA/Java on github >> >> Hi Jaime, >> >> Java was important for us before and Dmitri has worked on this >> implementation for quite some time now. we are ualready sing this now >> for another project. But changing it for better versions is always a >> good thing and we are very open for it. >> >> Please do not blame us for having already done some of the work that >> is now becoming relevant also for the project as a whole. >> >> You/we do not have to use this directly, but I see this as an >> interesting basis that we can use as a starting point for our >> discussions. This is why we are making it available for all to look at >> (and please do so). >> >> Having something that is already working and is already compatible >> with our previous work is (at least from my point of view) a better >> place to start than a blank page. I hope you and others agree. >> >> As in the C/C++ version we are very open to suggestions and >> alternative interfaces and implementations. So please feel free to >> suggest those, ideally directly with your implementation. Fortunately, >> we will not have the C/C++ issues, so we should be in a much better >> place to collaborate based on comparing each of our concepts and >> actual implementations of them. >> >> I am looking forward to a closer collaboration within FI-Core. >> >> BTW, at the Kickoff you have apparently developed a document >> describing how you (as in KIARA group) would want o work together. We >> have not been in the loop and so it would be good to get that >> document, so we are able to comment (and hopefully just agree to it). >> >> >> Best, >> >> Philipp >> >> >> >> >> Am 22.09.2014 um 15:37 schrieb Jaime Martin Losa: >>> Dmitri, we are not going to make the same mistake twice. >>> >>> First we have to define what we want to do, an API that should be >>> externally approved, the different modules, and then start to assign >>> tasks. >>> >>> Don't start just writing code without any design consensus and >>> later try the other parties to follow you. >>> >>> Regards, >>> Jaime. >>> >>> >>> -----Original Message----- >>> From: miwi-middleware-bounces at lists.fi-ware.org >>> [mailto:miwi-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri >>> Rubinstein >>> Sent: lunes, 22 de septiembre de 2014 13:10 >>> To: KIARA Mailing List >>> Subject: [Miwi-middleware] KIARA/Java on github >>> >>> I just made KIARA/Java v0.1 available on the github: >>> >>> https://github.com/dmrub/kiara-java >>> >>> License: LGPL version 3 >>> >>> Current features: >>> >>> Supported transports: HTTP 1.1, TCP Block Transport >>> >>> Supported protocols: JSON RPC 2.0, JavaObjectStream (Java >>> serialization) >>> >>> JSON RPC 2.0, HTTP 1.1 and TCP Block Transport are compatible to the >>> KIARA C/C++ version. >>> >>> Example applications are in: >>> ./KIARA/src/test/java/de/dfki/kiara/test/AosTest.java >>> >>> Best, >>> >>> Dmitri >>> _______________________________________________ >>> Miwi-middleware mailing list >>> Miwi-middleware at lists.fi-ware.org >>> https://lists.fi-ware.org/listinfo/miwi-middleware >>> >>> ----- >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: >>> 09/08/14 Internal Virus Database is out of date. >>> _______________________________________________ >>> Miwi-middleware mailing list >>> Miwi-middleware at lists.fi-ware.org >>> https://lists.fi-ware.org/listinfo/miwi-middleware >>> >> >> -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From philipp.slusallek at dfki.de Wed Sep 24 16:28:36 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Wed, 24 Sep 2014 16:28:36 +0200 Subject: [Miwi-middleware] KIARA/Java on github In-Reply-To: <54228914.6030608@gmail.com> References: <54200380.9080701@cs.uni-saarland.de> <0a36165dba0e4022a13b66c48ea072ee@AM3PR06MB337.eurprd06.prod.outlook.com> <54202CF1.20505@dfki.de> <5421493C.2060909@zhaw.ch> <54224B0C.2060704@dfki.de> <54228914.6030608@gmail.com> Message-ID: <5422D514.10309@dfki.de> Hi Thomas, I have raised concern regarding the support of current users (within the FI-PPP!) of existing GEis. This is a real question that we face and that that people will certainly approach me with. Why do you have a problem with that very relevant issue? Your write: "Agreement is to put ALL existing implementations on hold". I cannot agree with the statement in this strict form for the above reasons. All I am arguing is that some (smaller) efforts be reserved for support of existing and actively used technology. I also made it clear that I fully support the focus of our work on the Java API as suggested, Just not exclusively. I hope this is fine with all. Best, Philipp Am 24.09.2014 um 11:04 schrieb Thomas Michael Bohnert: > Philipp, > > I will stop this discussion here. It is pointless and a waste of time. > > We are a team and we have to consider the exact context and > organisationl structures and responsibilities. > > As I have said so many times in the past, we all have good reasons why > this is good and this is bad and this is better than this or that. > > But the point now is to stop this waste of time with arguing but to > start something that is first and foremost driven by a joint effort and > team. > > I really hope you can accept this and look forward to your contribution > as a team member. > > Best - Thomas > > > > > On 09/24/2014 06:39 AM, Philipp Slusallek wrote: >> Hi all, >> >> Sorry Thomas, for some reason I had not seen your email before I sent >> mine last night. Thanks for the update. Has the text you sent been >> agreed upon by Chapter 1.8 at the meeting in Madrid or is this more a >> summary of the discussions that took place at the meeting? >> >> >> Regarding the external expert: I believe Juanjo himself is probably one >> of the best experts we could find. If he suggested others, this is >> probably fine as well. Who is it that you are contacting now? >> >> >> While I very much agree (as I already told you) to focus on the Java >> version, I disagree strongly that we should stop all activities on the >> existing implementations. We must at least maintain the current >> technology and support it where necessary. >> >> Let's not forget that there are implementations that make active use of >> KIARA. They are within FI-WARE (Sync GE, CH. 1.5) as well as running >> demos within the FI-Content and FITMAN projects that make use of the >> existing KIARA GEi. Even more uses are planned within the next few >> months. >> >> Abandoning these fully working GEs without any technical reasons for >> doing so, would be damaging to FIWARE and the GE process. As you state, >> the Java version (especially if we start from an empty page) will take >> significant time to become available (you have even talked about one >> year). This is not acceptable for the existing users of the technology. >> Additionally, in those projects the C/C++ interface is needed, which >> would likely take even longer to become available. >> >> Also I see no impact whatsoever that the "old" implementationcould have >> on the new Java API. Once we have agreed on a new API for Java, it >> should not be too difficult to backport that to the current C/C++ >> version (at least if we keep that goal in mind during our discussion, >> which we should do anyway). Given the flexible design of current KIARA >> implementation, we should even be able to do so without having to >> abandon the current API and have them coexist for compatibility until >> existing users had a chance to switch over. >> >> Also there should not be any reason that the new Java version and the >> "old" implementations cannot interoperate, even while they are using >> different API approaches. So, I see also no reason that the "old" design >> would limit how we design the new Java API and implementation (which >> seems something that Jaime is very worried about). >> >> So unless someone comes up with solid technical reasons for abandoning >> the current work (which I cannot see and which have never been presented >> since we started our working on KIARA), we should refrain from >> suggesting to waste EU money that has been spend on the current >> implementations. >> >> To be clear, I am perfectly fine is focusing the current development on >> Java (as we have started some time ago already), I am just opposing to >> abandon the existing work as your text seems to suggest. >> >> >> Best, >> >> Philipp >> >> >> Am 23.09.2014 um 12:19 schrieb Thomas Michael Bohnert: >>> Dear all, >>> >>> Nice to see that there is so much energy behind our proposal to start >>> over with a Java version. If we continue like that there will be soon a >>> very nice product that serves the needs of our primary customers - that >>> is the FIWARE community. >>> >>> About the next steps. >>> >>> First, we need to complete the hand-over from MIWI to I2ND. This >>> includes all the stuff agreed upon during the WPL/WPA meetings, like new >>> mailing lists, etc. But this is mostly admin stuff. >>> >>> One item is the weeky KIARA meeting. This is now linked to Task 1.8.3 >>> and to be taken over by eProsima (Jaime?). That means to prepare agendas >>> in advance, take minutes, record action items, report to the WPA/WPL, >>> and any other task related to the task leadership. >>> >>> Regarding the technical directions to be taken. Agreement is to put ALL >>> existing implementations on hold and to start over with the JAVA >>> version. Starting point is a blank page but we will carefully analyze >>> existing code once we have agreed on the design, i.e. issues first and >>> foremost the KIARA API. >>> >>> About the KIARA API. Here the most important issue is to define an API >>> that meets the expectations of professional software developers. Since >>> we have very good expertises in the team, with a broad spectrum of >>> know-how and experiences we need to find a way to consolidate this into >>> one approach and ultimately specification. One element in achieving this >>> is to consult an external expert that will take a fresh and independent >>> view on things and thus secure a design that meets this requirement. The >>> exact candidate is not yet decided (do you have proposals?) but there is >>> already one person we know about and we currently are contacting. >>> >>> Action items: >>> Jaime - please prepare an agenda for coming Friday meeting, share it at >>> least a day before with the team such that we can add items to the >>> agenda in advance. >>> >>> We will discuss any aspect in next Friday's meeting, that is technical >>> aspects as well as implementation and procedures on task level. >>> >>> Thanks for your contributions and commitment in advance! >>> >>> Christof and Thomas >>> >>> On 09/22/2014 04:15 PM, Jaime Martin Losa wrote: >>>> Hi Philipp, >>>> >>>> This time we are going to start with the design, and not with the >>>> code, and this design should be externally approved. Yes we should >>>> start with a blank page. >>>> >>>> We didn't developed any document. Basically the Java Idea and the >>>> external audit has come from Juanjo. >>>> >>>> We are working now in a proposal (design, spec) of API. Next >>>> Friday meeting, we should start talking about the first design tasks >>>> of JAVA KIARA. >>>> >>>> Our main goal should be the usability, because we need something >>>> stable and easy within one year. >>>> >>>> Regards, >>>> Jaime. >>>> >>>> >>>> -----Original Message----- >>>> From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] >>>> Sent: lunes, 22 de septiembre de 2014 16:07 >>>> To: Jaime Martin Losa; Dmitri Rubinstein; KIARA Mailing List >>>> Subject: Re: [Miwi-middleware] KIARA/Java on github >>>> >>>> Hi Jaime, >>>> >>>> Java was important for us before and Dmitri has worked on this >>>> implementation for quite some time now. we are ualready sing this now >>>> for another project. But changing it for better versions is always a >>>> good thing and we are very open for it. >>>> >>>> Please do not blame us for having already done some of the work that >>>> is now becoming relevant also for the project as a whole. >>>> >>>> You/we do not have to use this directly, but I see this as an >>>> interesting basis that we can use as a starting point for our >>>> discussions. This is why we are making it available for all to look at >>>> (and please do so). >>>> >>>> Having something that is already working and is already compatible >>>> with our previous work is (at least from my point of view) a better >>>> place to start than a blank page. I hope you and others agree. >>>> >>>> As in the C/C++ version we are very open to suggestions and >>>> alternative interfaces and implementations. So please feel free to >>>> suggest those, ideally directly with your implementation. Fortunately, >>>> we will not have the C/C++ issues, so we should be in a much better >>>> place to collaborate based on comparing each of our concepts and >>>> actual implementations of them. >>>> >>>> I am looking forward to a closer collaboration within FI-Core. >>>> >>>> BTW, at the Kickoff you have apparently developed a document >>>> describing how you (as in KIARA group) would want o work together. We >>>> have not been in the loop and so it would be good to get that >>>> document, so we are able to comment (and hopefully just agree to it). >>>> >>>> >>>> Best, >>>> >>>> Philipp >>>> >>>> >>>> >>>> >>>> Am 22.09.2014 um 15:37 schrieb Jaime Martin Losa: >>>>> Dmitri, we are not going to make the same mistake twice. >>>>> >>>>> First we have to define what we want to do, an API that should be >>>>> externally approved, the different modules, and then start to assign >>>>> tasks. >>>>> >>>>> Don't start just writing code without any design consensus and >>>>> later try the other parties to follow you. >>>>> >>>>> Regards, >>>>> Jaime. >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: miwi-middleware-bounces at lists.fi-ware.org >>>>> [mailto:miwi-middleware-bounces at lists.fi-ware.org] On Behalf Of Dmitri >>>>> Rubinstein >>>>> Sent: lunes, 22 de septiembre de 2014 13:10 >>>>> To: KIARA Mailing List >>>>> Subject: [Miwi-middleware] KIARA/Java on github >>>>> >>>>> I just made KIARA/Java v0.1 available on the github: >>>>> >>>>> https://github.com/dmrub/kiara-java >>>>> >>>>> License: LGPL version 3 >>>>> >>>>> Current features: >>>>> >>>>> Supported transports: HTTP 1.1, TCP Block Transport >>>>> >>>>> Supported protocols: JSON RPC 2.0, JavaObjectStream (Java >>>>> serialization) >>>>> >>>>> JSON RPC 2.0, HTTP 1.1 and TCP Block Transport are compatible to the >>>>> KIARA C/C++ version. >>>>> >>>>> Example applications are in: >>>>> ./KIARA/src/test/java/de/dfki/kiara/test/AosTest.java >>>>> >>>>> Best, >>>>> >>>>> Dmitri >>>>> _______________________________________________ >>>>> Miwi-middleware mailing list >>>>> Miwi-middleware at lists.fi-ware.org >>>>> https://lists.fi-ware.org/listinfo/miwi-middleware >>>>> >>>>> ----- >>>>> No virus found in this message. >>>>> Checked by AVG - www.avg.com >>>>> Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: >>>>> 09/08/14 Internal Virus Database is out of date. >>>>> _______________________________________________ >>>>> Miwi-middleware mailing list >>>>> Miwi-middleware at lists.fi-ware.org >>>>> https://lists.fi-ware.org/listinfo/miwi-middleware >>>>> >>>> >>>> >> >> > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From JaimeMartin at eprosima.com Thu Sep 25 08:59:12 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Thu, 25 Sep 2014 06:59:12 +0000 Subject: [Miwi-middleware] KIARA/Java on github In-Reply-To: <5422D514.10309@dfki.de> References: <54200380.9080701@cs.uni-saarland.de> <0a36165dba0e4022a13b66c48ea072ee@AM3PR06MB337.eurprd06.prod.outlook.com> <54202CF1.20505@dfki.de> <5421493C.2060909@zhaw.ch> <54224B0C.2060704@dfki.de> <54228914.6030608@gmail.com> <5422D514.10309@dfki.de> Message-ID: Hi Philipp, We are not going to support the "old" releases of KIARA anymore, neither we are going to promote/recommend their use in the FI-WARE context. What we have already is not going to be the FI-WARE middleware. This is the message I got in the FI-CORE meeting. We need to create a brand new, very easy to use, middleware. To do so we can reuse some of our ideas and code, but it is entirely a new task. In this new task, our FIRST goal is the usability, being the performance and exotic features something we should sacrify if those add complexity to the user. As far I know, we have no users outside of DFKI, and if we have, they are really very few. Those users should migrate to the "new KIARA" as soon we have something usable. Regards, Jaime. -----Original Message----- From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] Sent: mi?rcoles, 24 de septiembre de 2014 16:29 To: Thomas Michael Bohnert; Thomas Michael Bohnert; Jaime Martin Losa; Dmitri Rubinstein; KIARA Mailing List; Garino Pierangelo Subject: Re: [Miwi-middleware] KIARA/Java on github Hi Thomas, I have raised concern regarding the support of current users (within the FI-PPP!) of existing GEis. This is a real question that we face and that that people will certainly approach me with. Why do you have a problem with that very relevant issue? Your write: "Agreement is to put ALL existing implementations on hold". I cannot agree with the statement in this strict form for the above reasons. All I am arguing is that some (smaller) efforts be reserved for support of existing and actively used technology. I also made it clear that I fully support the focus of our work on the Java API as suggested, Just not exclusively. I hope this is fine with all. Best, Philipp Am 24.09.2014 um 11:04 schrieb Thomas Michael Bohnert: > Philipp, > > I will stop this discussion here. It is pointless and a waste of time. > > We are a team and we have to consider the exact context and > organisationl structures and responsibilities. > > As I have said so many times in the past, we all have good reasons why > this is good and this is bad and this is better than this or that. > > But the point now is to stop this waste of time with arguing but to > start something that is first and foremost driven by a joint effort > and team. > > I really hope you can accept this and look forward to your > contribution as a team member. > > Best - Thomas > > > > > On 09/24/2014 06:39 AM, Philipp Slusallek wrote: >> Hi all, >> >> Sorry Thomas, for some reason I had not seen your email before I sent >> mine last night. Thanks for the update. Has the text you sent been >> agreed upon by Chapter 1.8 at the meeting in Madrid or is this more a >> summary of the discussions that took place at the meeting? >> >> >> Regarding the external expert: I believe Juanjo himself is probably >> one of the best experts we could find. If he suggested others, this >> is probably fine as well. Who is it that you are contacting now? >> >> >> While I very much agree (as I already told you) to focus on the Java >> version, I disagree strongly that we should stop all activities on >> the existing implementations. We must at least maintain the current >> technology and support it where necessary. >> >> Let's not forget that there are implementations that make active use >> of KIARA. They are within FI-WARE (Sync GE, CH. 1.5) as well as >> running demos within the FI-Content and FITMAN projects that make use >> of the existing KIARA GEi. Even more uses are planned within the next >> few months. >> >> Abandoning these fully working GEs without any technical reasons for >> doing so, would be damaging to FIWARE and the GE process. As you >> state, the Java version (especially if we start from an empty page) >> will take significant time to become available (you have even talked >> about one year). This is not acceptable for the existing users of the technology. >> Additionally, in those projects the C/C++ interface is needed, which >> would likely take even longer to become available. >> >> Also I see no impact whatsoever that the "old" implementationcould >> have on the new Java API. Once we have agreed on a new API for Java, >> it should not be too difficult to backport that to the current C/C++ >> version (at least if we keep that goal in mind during our discussion, >> which we should do anyway). Given the flexible design of current >> KIARA implementation, we should even be able to do so without having >> to abandon the current API and have them coexist for compatibility >> until existing users had a chance to switch over. >> >> Also there should not be any reason that the new Java version and the >> "old" implementations cannot interoperate, even while they are using >> different API approaches. So, I see also no reason that the "old" >> design would limit how we design the new Java API and implementation >> (which seems something that Jaime is very worried about). >> >> So unless someone comes up with solid technical reasons for >> abandoning the current work (which I cannot see and which have never >> been presented since we started our working on KIARA), we should >> refrain from suggesting to waste EU money that has been spend on the >> current implementations. >> >> To be clear, I am perfectly fine is focusing the current development >> on Java (as we have started some time ago already), I am just >> opposing to abandon the existing work as your text seems to suggest. >> >> >> Best, >> >> Philipp >> >> >> Am 23.09.2014 um 12:19 schrieb Thomas Michael Bohnert: >>> Dear all, >>> >>> Nice to see that there is so much energy behind our proposal to >>> start over with a Java version. If we continue like that there will >>> be soon a very nice product that serves the needs of our primary >>> customers - that is the FIWARE community. >>> >>> About the next steps. >>> >>> First, we need to complete the hand-over from MIWI to I2ND. This >>> includes all the stuff agreed upon during the WPL/WPA meetings, like >>> new mailing lists, etc. But this is mostly admin stuff. >>> >>> One item is the weeky KIARA meeting. This is now linked to Task >>> 1.8.3 and to be taken over by eProsima (Jaime?). That means to >>> prepare agendas in advance, take minutes, record action items, >>> report to the WPA/WPL, and any other task related to the task leadership. >>> >>> Regarding the technical directions to be taken. Agreement is to put >>> ALL existing implementations on hold and to start over with the JAVA >>> version. Starting point is a blank page but we will carefully >>> analyze existing code once we have agreed on the design, i.e. issues >>> first and foremost the KIARA API. >>> >>> About the KIARA API. Here the most important issue is to define an >>> API that meets the expectations of professional software developers. >>> Since we have very good expertises in the team, with a broad >>> spectrum of know-how and experiences we need to find a way to >>> consolidate this into one approach and ultimately specification. One >>> element in achieving this is to consult an external expert that will >>> take a fresh and independent view on things and thus secure a design >>> that meets this requirement. The exact candidate is not yet decided >>> (do you have proposals?) but there is already one person we know about and we currently are contacting. >>> >>> Action items: >>> Jaime - please prepare an agenda for coming Friday meeting, share it >>> at least a day before with the team such that we can add items to >>> the agenda in advance. >>> >>> We will discuss any aspect in next Friday's meeting, that is >>> technical aspects as well as implementation and procedures on task level. >>> >>> Thanks for your contributions and commitment in advance! >>> >>> Christof and Thomas >>> >>> On 09/22/2014 04:15 PM, Jaime Martin Losa wrote: >>>> Hi Philipp, >>>> >>>> This time we are going to start with the design, and not with >>>> the code, and this design should be externally approved. Yes we >>>> should start with a blank page. >>>> >>>> We didn't developed any document. Basically the Java Idea and >>>> the external audit has come from Juanjo. >>>> >>>> We are working now in a proposal (design, spec) of API. Next >>>> Friday meeting, we should start talking about the first design >>>> tasks of JAVA KIARA. >>>> >>>> Our main goal should be the usability, because we need >>>> something stable and easy within one year. >>>> >>>> Regards, >>>> Jaime. >>>> >>>> >>>> -----Original Message----- >>>> From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] >>>> Sent: lunes, 22 de septiembre de 2014 16:07 >>>> To: Jaime Martin Losa; Dmitri Rubinstein; KIARA Mailing List >>>> Subject: Re: [Miwi-middleware] KIARA/Java on github >>>> >>>> Hi Jaime, >>>> >>>> Java was important for us before and Dmitri has worked on this >>>> implementation for quite some time now. we are ualready sing this >>>> now for another project. But changing it for better versions is >>>> always a good thing and we are very open for it. >>>> >>>> Please do not blame us for having already done some of the work >>>> that is now becoming relevant also for the project as a whole. >>>> >>>> You/we do not have to use this directly, but I see this as an >>>> interesting basis that we can use as a starting point for our >>>> discussions. This is why we are making it available for all to look >>>> at (and please do so). >>>> >>>> Having something that is already working and is already compatible >>>> with our previous work is (at least from my point of view) a better >>>> place to start than a blank page. I hope you and others agree. >>>> >>>> As in the C/C++ version we are very open to suggestions and >>>> alternative interfaces and implementations. So please feel free to >>>> suggest those, ideally directly with your implementation. >>>> Fortunately, we will not have the C/C++ issues, so we should be in >>>> a much better place to collaborate based on comparing each of our >>>> concepts and actual implementations of them. >>>> >>>> I am looking forward to a closer collaboration within FI-Core. >>>> >>>> BTW, at the Kickoff you have apparently developed a document >>>> describing how you (as in KIARA group) would want o work together. >>>> We have not been in the loop and so it would be good to get that >>>> document, so we are able to comment (and hopefully just agree to it). >>>> >>>> >>>> Best, >>>> >>>> Philipp >>>> >>>> >>>> >>>> >>>> Am 22.09.2014 um 15:37 schrieb Jaime Martin Losa: >>>>> Dmitri, we are not going to make the same mistake twice. >>>>> >>>>> First we have to define what we want to do, an API that >>>>> should be externally approved, the different modules, and then >>>>> start to assign tasks. >>>>> >>>>> Don't start just writing code without any design consensus >>>>> and later try the other parties to follow you. >>>>> >>>>> Regards, >>>>> Jaime. >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: miwi-middleware-bounces at lists.fi-ware.org >>>>> [mailto:miwi-middleware-bounces at lists.fi-ware.org] On Behalf Of >>>>> Dmitri Rubinstein >>>>> Sent: lunes, 22 de septiembre de 2014 13:10 >>>>> To: KIARA Mailing List >>>>> Subject: [Miwi-middleware] KIARA/Java on github >>>>> >>>>> I just made KIARA/Java v0.1 available on the github: >>>>> >>>>> https://github.com/dmrub/kiara-java >>>>> >>>>> License: LGPL version 3 >>>>> >>>>> Current features: >>>>> >>>>> Supported transports: HTTP 1.1, TCP Block Transport >>>>> >>>>> Supported protocols: JSON RPC 2.0, JavaObjectStream (Java >>>>> serialization) >>>>> >>>>> JSON RPC 2.0, HTTP 1.1 and TCP Block Transport are compatible to >>>>> the KIARA C/C++ version. >>>>> >>>>> Example applications are in: >>>>> ./KIARA/src/test/java/de/dfki/kiara/test/AosTest.java >>>>> >>>>> Best, >>>>> >>>>> Dmitri >>>>> _______________________________________________ >>>>> Miwi-middleware mailing list >>>>> Miwi-middleware at lists.fi-ware.org >>>>> https://lists.fi-ware.org/listinfo/miwi-middleware >>>>> >>>>> ----- >>>>> No virus found in this message. >>>>> Checked by AVG - www.avg.com >>>>> Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: >>>>> 09/08/14 Internal Virus Database is out of date. >>>>> _______________________________________________ >>>>> Miwi-middleware mailing list >>>>> Miwi-middleware at lists.fi-ware.org >>>>> https://lists.fi-ware.org/listinfo/miwi-middleware >>>>> >>>> >>>> >> >> > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- From thomas.bohnert at zhaw.ch Thu Sep 25 09:04:08 2014 From: thomas.bohnert at zhaw.ch (Thomas Michael Bohnert) Date: Thu, 25 Sep 2014 09:04:08 +0200 Subject: [Miwi-middleware] KIARA/Java on github In-Reply-To: References: <54200380.9080701@cs.uni-saarland.de> <0a36165dba0e4022a13b66c48ea072ee@AM3PR06MB337.eurprd06.prod.outlook.com> <54202CF1.20505@dfki.de> <5421493C.2060909@zhaw.ch> <54224B0C.2060704@dfki.de> <54228914.6030608@gmail.com> <5422D514.10309@dfki.de> Message-ID: <5423BE68.5060501@zhaw.ch> HI all, Thanks for your continued support and energy. I really like the spirit here, as it seems that people in the team really care. Jaime, please make sure that the meeting tomorrow is well prepared such that we can start with the clean approach to what is then to become THE KIARA middleware. We will later see if at all, and in case what, needs to be modified, overtaken (concepts, code, etc), reimplemented, completely newly implemented and so on. But for now we start with the programming paradigm and the respective API - in a collaborative manner. And I hope that I can count on a collaborative spirit from the ENTIRE team, ePros, DFKI, ZHAW (in alphabetical order). Cheers, Thomas On 09/25/2014 08:59 AM, Jaime Martin Losa wrote: > Hi Philipp, > > We are not going to support the "old" releases of KIARA anymore, neither we are going to promote/recommend their use in the FI-WARE context. What we have already is not going to be the FI-WARE middleware. This is the message I got in the FI-CORE meeting. > > We need to create a brand new, very easy to use, middleware. To do so we can reuse some of our ideas and code, but it is entirely a new task. > > In this new task, our FIRST goal is the usability, being the performance and exotic features something we should sacrify if those add complexity to the user. > > As far I know, we have no users outside of DFKI, and if we have, they are really very few. Those users should migrate to the "new KIARA" as soon we have something usable. > > Regards, > Jaime. > > > -----Original Message----- > From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] > Sent: mi?rcoles, 24 de septiembre de 2014 16:29 > To: Thomas Michael Bohnert; Thomas Michael Bohnert; Jaime Martin Losa; Dmitri Rubinstein; KIARA Mailing List; Garino Pierangelo > Subject: Re: [Miwi-middleware] KIARA/Java on github > > Hi Thomas, > > I have raised concern regarding the support of current users (within the > FI-PPP!) of existing GEis. This is a real question that we face and that that people will certainly approach me with. Why do you have a problem with that very relevant issue? > > Your write: "Agreement is to put ALL existing implementations on hold". > I cannot agree with the statement in this strict form for the above reasons. All I am arguing is that some (smaller) efforts be reserved for support of existing and actively used technology. > > I also made it clear that I fully support the focus of our work on the Java API as suggested, Just not exclusively. I hope this is fine with all. > > > Best, > > Philipp > > > > > Am 24.09.2014 um 11:04 schrieb Thomas Michael Bohnert: >> Philipp, >> >> I will stop this discussion here. It is pointless and a waste of time. >> >> We are a team and we have to consider the exact context and >> organisationl structures and responsibilities. >> >> As I have said so many times in the past, we all have good reasons why >> this is good and this is bad and this is better than this or that. >> >> But the point now is to stop this waste of time with arguing but to >> start something that is first and foremost driven by a joint effort >> and team. >> >> I really hope you can accept this and look forward to your >> contribution as a team member. >> >> Best - Thomas >> >> >> >> >> On 09/24/2014 06:39 AM, Philipp Slusallek wrote: >>> Hi all, >>> >>> Sorry Thomas, for some reason I had not seen your email before I sent >>> mine last night. Thanks for the update. Has the text you sent been >>> agreed upon by Chapter 1.8 at the meeting in Madrid or is this more a >>> summary of the discussions that took place at the meeting? >>> >>> >>> Regarding the external expert: I believe Juanjo himself is probably >>> one of the best experts we could find. If he suggested others, this >>> is probably fine as well. Who is it that you are contacting now? >>> >>> >>> While I very much agree (as I already told you) to focus on the Java >>> version, I disagree strongly that we should stop all activities on >>> the existing implementations. We must at least maintain the current >>> technology and support it where necessary. >>> >>> Let's not forget that there are implementations that make active use >>> of KIARA. They are within FI-WARE (Sync GE, CH. 1.5) as well as >>> running demos within the FI-Content and FITMAN projects that make use >>> of the existing KIARA GEi. Even more uses are planned within the next >>> few months. >>> >>> Abandoning these fully working GEs without any technical reasons for >>> doing so, would be damaging to FIWARE and the GE process. As you >>> state, the Java version (especially if we start from an empty page) >>> will take significant time to become available (you have even talked >>> about one year). This is not acceptable for the existing users of the technology. >>> Additionally, in those projects the C/C++ interface is needed, which >>> would likely take even longer to become available. >>> >>> Also I see no impact whatsoever that the "old" implementationcould >>> have on the new Java API. Once we have agreed on a new API for Java, >>> it should not be too difficult to backport that to the current C/C++ >>> version (at least if we keep that goal in mind during our discussion, >>> which we should do anyway). Given the flexible design of current >>> KIARA implementation, we should even be able to do so without having >>> to abandon the current API and have them coexist for compatibility >>> until existing users had a chance to switch over. >>> >>> Also there should not be any reason that the new Java version and the >>> "old" implementations cannot interoperate, even while they are using >>> different API approaches. So, I see also no reason that the "old" >>> design would limit how we design the new Java API and implementation >>> (which seems something that Jaime is very worried about). >>> >>> So unless someone comes up with solid technical reasons for >>> abandoning the current work (which I cannot see and which have never >>> been presented since we started our working on KIARA), we should >>> refrain from suggesting to waste EU money that has been spend on the >>> current implementations. >>> >>> To be clear, I am perfectly fine is focusing the current development >>> on Java (as we have started some time ago already), I am just >>> opposing to abandon the existing work as your text seems to suggest. >>> >>> >>> Best, >>> >>> Philipp >>> >>> >>> Am 23.09.2014 um 12:19 schrieb Thomas Michael Bohnert: >>>> Dear all, >>>> >>>> Nice to see that there is so much energy behind our proposal to >>>> start over with a Java version. If we continue like that there will >>>> be soon a very nice product that serves the needs of our primary >>>> customers - that is the FIWARE community. >>>> >>>> About the next steps. >>>> >>>> First, we need to complete the hand-over from MIWI to I2ND. This >>>> includes all the stuff agreed upon during the WPL/WPA meetings, like >>>> new mailing lists, etc. But this is mostly admin stuff. >>>> >>>> One item is the weeky KIARA meeting. This is now linked to Task >>>> 1.8.3 and to be taken over by eProsima (Jaime?). That means to >>>> prepare agendas in advance, take minutes, record action items, >>>> report to the WPA/WPL, and any other task related to the task leadership. >>>> >>>> Regarding the technical directions to be taken. Agreement is to put >>>> ALL existing implementations on hold and to start over with the JAVA >>>> version. Starting point is a blank page but we will carefully >>>> analyze existing code once we have agreed on the design, i.e. issues >>>> first and foremost the KIARA API. >>>> >>>> About the KIARA API. Here the most important issue is to define an >>>> API that meets the expectations of professional software developers. >>>> Since we have very good expertises in the team, with a broad >>>> spectrum of know-how and experiences we need to find a way to >>>> consolidate this into one approach and ultimately specification. One >>>> element in achieving this is to consult an external expert that will >>>> take a fresh and independent view on things and thus secure a design >>>> that meets this requirement. The exact candidate is not yet decided >>>> (do you have proposals?) but there is already one person we know about and we currently are contacting. >>>> >>>> Action items: >>>> Jaime - please prepare an agenda for coming Friday meeting, share it >>>> at least a day before with the team such that we can add items to >>>> the agenda in advance. >>>> >>>> We will discuss any aspect in next Friday's meeting, that is >>>> technical aspects as well as implementation and procedures on task level. >>>> >>>> Thanks for your contributions and commitment in advance! >>>> >>>> Christof and Thomas >>>> >>>> On 09/22/2014 04:15 PM, Jaime Martin Losa wrote: >>>>> Hi Philipp, >>>>> >>>>> This time we are going to start with the design, and not with >>>>> the code, and this design should be externally approved. Yes we >>>>> should start with a blank page. >>>>> >>>>> We didn't developed any document. Basically the Java Idea and >>>>> the external audit has come from Juanjo. >>>>> >>>>> We are working now in a proposal (design, spec) of API. Next >>>>> Friday meeting, we should start talking about the first design >>>>> tasks of JAVA KIARA. >>>>> >>>>> Our main goal should be the usability, because we need >>>>> something stable and easy within one year. >>>>> >>>>> Regards, >>>>> Jaime. >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] >>>>> Sent: lunes, 22 de septiembre de 2014 16:07 >>>>> To: Jaime Martin Losa; Dmitri Rubinstein; KIARA Mailing List >>>>> Subject: Re: [Miwi-middleware] KIARA/Java on github >>>>> >>>>> Hi Jaime, >>>>> >>>>> Java was important for us before and Dmitri has worked on this >>>>> implementation for quite some time now. we are ualready sing this >>>>> now for another project. But changing it for better versions is >>>>> always a good thing and we are very open for it. >>>>> >>>>> Please do not blame us for having already done some of the work >>>>> that is now becoming relevant also for the project as a whole. >>>>> >>>>> You/we do not have to use this directly, but I see this as an >>>>> interesting basis that we can use as a starting point for our >>>>> discussions. This is why we are making it available for all to look >>>>> at (and please do so). >>>>> >>>>> Having something that is already working and is already compatible >>>>> with our previous work is (at least from my point of view) a better >>>>> place to start than a blank page. I hope you and others agree. >>>>> >>>>> As in the C/C++ version we are very open to suggestions and >>>>> alternative interfaces and implementations. So please feel free to >>>>> suggest those, ideally directly with your implementation. >>>>> Fortunately, we will not have the C/C++ issues, so we should be in >>>>> a much better place to collaborate based on comparing each of our >>>>> concepts and actual implementations of them. >>>>> >>>>> I am looking forward to a closer collaboration within FI-Core. >>>>> >>>>> BTW, at the Kickoff you have apparently developed a document >>>>> describing how you (as in KIARA group) would want o work together. >>>>> We have not been in the loop and so it would be good to get that >>>>> document, so we are able to comment (and hopefully just agree to it). >>>>> >>>>> >>>>> Best, >>>>> >>>>> Philipp >>>>> >>>>> >>>>> >>>>> >>>>> Am 22.09.2014 um 15:37 schrieb Jaime Martin Losa: >>>>>> Dmitri, we are not going to make the same mistake twice. >>>>>> >>>>>> First we have to define what we want to do, an API that >>>>>> should be externally approved, the different modules, and then >>>>>> start to assign tasks. >>>>>> >>>>>> Don't start just writing code without any design consensus >>>>>> and later try the other parties to follow you. >>>>>> >>>>>> Regards, >>>>>> Jaime. >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: miwi-middleware-bounces at lists.fi-ware.org >>>>>> [mailto:miwi-middleware-bounces at lists.fi-ware.org] On Behalf Of >>>>>> Dmitri Rubinstein >>>>>> Sent: lunes, 22 de septiembre de 2014 13:10 >>>>>> To: KIARA Mailing List >>>>>> Subject: [Miwi-middleware] KIARA/Java on github >>>>>> >>>>>> I just made KIARA/Java v0.1 available on the github: >>>>>> >>>>>> https://github.com/dmrub/kiara-java >>>>>> >>>>>> License: LGPL version 3 >>>>>> >>>>>> Current features: >>>>>> >>>>>> Supported transports: HTTP 1.1, TCP Block Transport >>>>>> >>>>>> Supported protocols: JSON RPC 2.0, JavaObjectStream (Java >>>>>> serialization) >>>>>> >>>>>> JSON RPC 2.0, HTTP 1.1 and TCP Block Transport are compatible to >>>>>> the KIARA C/C++ version. >>>>>> >>>>>> Example applications are in: >>>>>> ./KIARA/src/test/java/de/dfki/kiara/test/AosTest.java >>>>>> >>>>>> Best, >>>>>> >>>>>> Dmitri >>>>>> _______________________________________________ >>>>>> Miwi-middleware mailing list >>>>>> Miwi-middleware at lists.fi-ware.org >>>>>> https://lists.fi-ware.org/listinfo/miwi-middleware >>>>>> >>>>>> ----- >>>>>> No virus found in this message. >>>>>> Checked by AVG - www.avg.com >>>>>> Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: >>>>>> 09/08/14 Internal Virus Database is out of date. >>>>>> _______________________________________________ >>>>>> Miwi-middleware mailing list >>>>>> Miwi-middleware at lists.fi-ware.org >>>>>> https://lists.fi-ware.org/listinfo/miwi-middleware >>>>>> >>>>> >>>>> >>> >>> >> > > From philipp.slusallek at dfki.de Thu Sep 25 13:15:45 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Thu, 25 Sep 2014 13:15:45 +0200 Subject: [Miwi-middleware] KIARA/Java on github In-Reply-To: References: <54200380.9080701@cs.uni-saarland.de> <0a36165dba0e4022a13b66c48ea072ee@AM3PR06MB337.eurprd06.prod.outlook.com> <54202CF1.20505@dfki.de> <5421493C.2060909@zhaw.ch> <54224B0C.2060704@dfki.de> <54228914.6030608@gmail.com> <5422D514.10309@dfki.de> Message-ID: <5423F961.1070907@dfki.de> Hi, Am 25.09.2014 um 08:59 schrieb Jaime Martin Losa: > As far I know, we have no users outside of DFKI, and if we have, they are really very few. Those users should migrate to the "new KIARA" as soon we have something usable. Just to state the facts here: There are active and committed uses of KIARA within in FI-Core (Ch.1.5), within FI-Content, and FITMAN. They are part of deliverables of those projects. DFKI is involved in those but that does not make any difference to the fact that those projects depend on a released GE in FIWARE for their deliverables. Migration to something that has not even been defined is not an option given the deadlines of those deliverables, sorry. And a Java is not option either. I would appreciate if the partners would acknowledge this issue in the first place and then work with us to resolve them. I am open for other suggestions than those proposed before by me. We should also keep in mind that we have a requirement from the commission to show that our Middleware GEs are being used in several other GEs within one year(!). I do not see how we can fulfill that exclusively with the the suggested clean slate approach or at leats some integration of the new things with the old ones (which are being used already). But let's discuss this in the call tomorrow. It might be easier that way. Best, Philipp > > Regards, > Jaime. > > > -----Original Message----- > From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] > Sent: mi?rcoles, 24 de septiembre de 2014 16:29 > To: Thomas Michael Bohnert; Thomas Michael Bohnert; Jaime Martin Losa; Dmitri Rubinstein; KIARA Mailing List; Garino Pierangelo > Subject: Re: [Miwi-middleware] KIARA/Java on github > > Hi Thomas, > > I have raised concern regarding the support of current users (within the > FI-PPP!) of existing GEis. This is a real question that we face and that that people will certainly approach me with. Why do you have a problem with that very relevant issue? > > Your write: "Agreement is to put ALL existing implementations on hold". > I cannot agree with the statement in this strict form for the above reasons. All I am arguing is that some (smaller) efforts be reserved for support of existing and actively used technology. > > I also made it clear that I fully support the focus of our work on the Java API as suggested, Just not exclusively. I hope this is fine with all. > > > Best, > > Philipp > > > > > Am 24.09.2014 um 11:04 schrieb Thomas Michael Bohnert: >> Philipp, >> >> I will stop this discussion here. It is pointless and a waste of time. >> >> We are a team and we have to consider the exact context and >> organisationl structures and responsibilities. >> >> As I have said so many times in the past, we all have good reasons why >> this is good and this is bad and this is better than this or that. >> >> But the point now is to stop this waste of time with arguing but to >> start something that is first and foremost driven by a joint effort >> and team. >> >> I really hope you can accept this and look forward to your >> contribution as a team member. >> >> Best - Thomas >> >> >> >> >> On 09/24/2014 06:39 AM, Philipp Slusallek wrote: >>> Hi all, >>> >>> Sorry Thomas, for some reason I had not seen your email before I sent >>> mine last night. Thanks for the update. Has the text you sent been >>> agreed upon by Chapter 1.8 at the meeting in Madrid or is this more a >>> summary of the discussions that took place at the meeting? >>> >>> >>> Regarding the external expert: I believe Juanjo himself is probably >>> one of the best experts we could find. If he suggested others, this >>> is probably fine as well. Who is it that you are contacting now? >>> >>> >>> While I very much agree (as I already told you) to focus on the Java >>> version, I disagree strongly that we should stop all activities on >>> the existing implementations. We must at least maintain the current >>> technology and support it where necessary. >>> >>> Let's not forget that there are implementations that make active use >>> of KIARA. They are within FI-WARE (Sync GE, CH. 1.5) as well as >>> running demos within the FI-Content and FITMAN projects that make use >>> of the existing KIARA GEi. Even more uses are planned within the next >>> few months. >>> >>> Abandoning these fully working GEs without any technical reasons for >>> doing so, would be damaging to FIWARE and the GE process. As you >>> state, the Java version (especially if we start from an empty page) >>> will take significant time to become available (you have even talked >>> about one year). This is not acceptable for the existing users of the technology. >>> Additionally, in those projects the C/C++ interface is needed, which >>> would likely take even longer to become available. >>> >>> Also I see no impact whatsoever that the "old" implementationcould >>> have on the new Java API. Once we have agreed on a new API for Java, >>> it should not be too difficult to backport that to the current C/C++ >>> version (at least if we keep that goal in mind during our discussion, >>> which we should do anyway). Given the flexible design of current >>> KIARA implementation, we should even be able to do so without having >>> to abandon the current API and have them coexist for compatibility >>> until existing users had a chance to switch over. >>> >>> Also there should not be any reason that the new Java version and the >>> "old" implementations cannot interoperate, even while they are using >>> different API approaches. So, I see also no reason that the "old" >>> design would limit how we design the new Java API and implementation >>> (which seems something that Jaime is very worried about). >>> >>> So unless someone comes up with solid technical reasons for >>> abandoning the current work (which I cannot see and which have never >>> been presented since we started our working on KIARA), we should >>> refrain from suggesting to waste EU money that has been spend on the >>> current implementations. >>> >>> To be clear, I am perfectly fine is focusing the current development >>> on Java (as we have started some time ago already), I am just >>> opposing to abandon the existing work as your text seems to suggest. >>> >>> >>> Best, >>> >>> Philipp >>> >>> >>> Am 23.09.2014 um 12:19 schrieb Thomas Michael Bohnert: >>>> Dear all, >>>> >>>> Nice to see that there is so much energy behind our proposal to >>>> start over with a Java version. If we continue like that there will >>>> be soon a very nice product that serves the needs of our primary >>>> customers - that is the FIWARE community. >>>> >>>> About the next steps. >>>> >>>> First, we need to complete the hand-over from MIWI to I2ND. This >>>> includes all the stuff agreed upon during the WPL/WPA meetings, like >>>> new mailing lists, etc. But this is mostly admin stuff. >>>> >>>> One item is the weeky KIARA meeting. This is now linked to Task >>>> 1.8.3 and to be taken over by eProsima (Jaime?). That means to >>>> prepare agendas in advance, take minutes, record action items, >>>> report to the WPA/WPL, and any other task related to the task leadership. >>>> >>>> Regarding the technical directions to be taken. Agreement is to put >>>> ALL existing implementations on hold and to start over with the JAVA >>>> version. Starting point is a blank page but we will carefully >>>> analyze existing code once we have agreed on the design, i.e. issues >>>> first and foremost the KIARA API. >>>> >>>> About the KIARA API. Here the most important issue is to define an >>>> API that meets the expectations of professional software developers. >>>> Since we have very good expertises in the team, with a broad >>>> spectrum of know-how and experiences we need to find a way to >>>> consolidate this into one approach and ultimately specification. One >>>> element in achieving this is to consult an external expert that will >>>> take a fresh and independent view on things and thus secure a design >>>> that meets this requirement. The exact candidate is not yet decided >>>> (do you have proposals?) but there is already one person we know about and we currently are contacting. >>>> >>>> Action items: >>>> Jaime - please prepare an agenda for coming Friday meeting, share it >>>> at least a day before with the team such that we can add items to >>>> the agenda in advance. >>>> >>>> We will discuss any aspect in next Friday's meeting, that is >>>> technical aspects as well as implementation and procedures on task level. >>>> >>>> Thanks for your contributions and commitment in advance! >>>> >>>> Christof and Thomas >>>> >>>> On 09/22/2014 04:15 PM, Jaime Martin Losa wrote: >>>>> Hi Philipp, >>>>> >>>>> This time we are going to start with the design, and not with >>>>> the code, and this design should be externally approved. Yes we >>>>> should start with a blank page. >>>>> >>>>> We didn't developed any document. Basically the Java Idea and >>>>> the external audit has come from Juanjo. >>>>> >>>>> We are working now in a proposal (design, spec) of API. Next >>>>> Friday meeting, we should start talking about the first design >>>>> tasks of JAVA KIARA. >>>>> >>>>> Our main goal should be the usability, because we need >>>>> something stable and easy within one year. >>>>> >>>>> Regards, >>>>> Jaime. >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] >>>>> Sent: lunes, 22 de septiembre de 2014 16:07 >>>>> To: Jaime Martin Losa; Dmitri Rubinstein; KIARA Mailing List >>>>> Subject: Re: [Miwi-middleware] KIARA/Java on github >>>>> >>>>> Hi Jaime, >>>>> >>>>> Java was important for us before and Dmitri has worked on this >>>>> implementation for quite some time now. we are ualready sing this >>>>> now for another project. But changing it for better versions is >>>>> always a good thing and we are very open for it. >>>>> >>>>> Please do not blame us for having already done some of the work >>>>> that is now becoming relevant also for the project as a whole. >>>>> >>>>> You/we do not have to use this directly, but I see this as an >>>>> interesting basis that we can use as a starting point for our >>>>> discussions. This is why we are making it available for all to look >>>>> at (and please do so). >>>>> >>>>> Having something that is already working and is already compatible >>>>> with our previous work is (at least from my point of view) a better >>>>> place to start than a blank page. I hope you and others agree. >>>>> >>>>> As in the C/C++ version we are very open to suggestions and >>>>> alternative interfaces and implementations. So please feel free to >>>>> suggest those, ideally directly with your implementation. >>>>> Fortunately, we will not have the C/C++ issues, so we should be in >>>>> a much better place to collaborate based on comparing each of our >>>>> concepts and actual implementations of them. >>>>> >>>>> I am looking forward to a closer collaboration within FI-Core. >>>>> >>>>> BTW, at the Kickoff you have apparently developed a document >>>>> describing how you (as in KIARA group) would want o work together. >>>>> We have not been in the loop and so it would be good to get that >>>>> document, so we are able to comment (and hopefully just agree to it). >>>>> >>>>> >>>>> Best, >>>>> >>>>> Philipp >>>>> >>>>> >>>>> >>>>> >>>>> Am 22.09.2014 um 15:37 schrieb Jaime Martin Losa: >>>>>> Dmitri, we are not going to make the same mistake twice. >>>>>> >>>>>> First we have to define what we want to do, an API that >>>>>> should be externally approved, the different modules, and then >>>>>> start to assign tasks. >>>>>> >>>>>> Don't start just writing code without any design consensus >>>>>> and later try the other parties to follow you. >>>>>> >>>>>> Regards, >>>>>> Jaime. >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: miwi-middleware-bounces at lists.fi-ware.org >>>>>> [mailto:miwi-middleware-bounces at lists.fi-ware.org] On Behalf Of >>>>>> Dmitri Rubinstein >>>>>> Sent: lunes, 22 de septiembre de 2014 13:10 >>>>>> To: KIARA Mailing List >>>>>> Subject: [Miwi-middleware] KIARA/Java on github >>>>>> >>>>>> I just made KIARA/Java v0.1 available on the github: >>>>>> >>>>>> https://github.com/dmrub/kiara-java >>>>>> >>>>>> License: LGPL version 3 >>>>>> >>>>>> Current features: >>>>>> >>>>>> Supported transports: HTTP 1.1, TCP Block Transport >>>>>> >>>>>> Supported protocols: JSON RPC 2.0, JavaObjectStream (Java >>>>>> serialization) >>>>>> >>>>>> JSON RPC 2.0, HTTP 1.1 and TCP Block Transport are compatible to >>>>>> the KIARA C/C++ version. >>>>>> >>>>>> Example applications are in: >>>>>> ./KIARA/src/test/java/de/dfki/kiara/test/AosTest.java >>>>>> >>>>>> Best, >>>>>> >>>>>> Dmitri >>>>>> _______________________________________________ >>>>>> Miwi-middleware mailing list >>>>>> Miwi-middleware at lists.fi-ware.org >>>>>> https://lists.fi-ware.org/listinfo/miwi-middleware >>>>>> >>>>>> ----- >>>>>> No virus found in this message. >>>>>> Checked by AVG - www.avg.com >>>>>> Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: >>>>>> 09/08/14 Internal Virus Database is out of date. >>>>>> _______________________________________________ >>>>>> Miwi-middleware mailing list >>>>>> Miwi-middleware at lists.fi-ware.org >>>>>> https://lists.fi-ware.org/listinfo/miwi-middleware >>>>>> >>>>> >>>>> >>> >>> >> > > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From JaimeMartin at eprosima.com Fri Sep 26 10:57:22 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Fri, 26 Sep 2014 08:57:22 +0000 Subject: [Miwi-middleware] Agenda for today's meeting. Message-ID: Here you have, https://docs.google.com/document/d/1Nwql8FMMIjxF3A0rEXwcFlM733p8p0yLWhEq3URfvhc/edit# Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFD978.A5568F10] The Middleware Experts Phone: + 34 91 804 34 48 / + 34 607 91 37 45 JaimeMartin at eProsima.com www.eProsima.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3800 bytes Desc: image001.png URL: From philipp.slusallek at dfki.de Fri Sep 26 13:00:35 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Fri, 26 Sep 2014 13:00:35 +0200 Subject: [Miwi-middleware] Agenda for today's meeting. In-Reply-To: References: Message-ID: <54254753.5020503@dfki.de> Hi, Has someone set up a Hangout link yet? THe lin kin the document points to a session that seems to be over. Best, Philipp Am 26.09.2014 um 10:57 schrieb Jaime Martin Losa: > Here you have, > > https://docs.google.com/document/d/1Nwql8FMMIjxF3A0rEXwcFlM733p8p0yLWhEq3URfvhc/edit# > > > Regards, > Jaime Martin Losa > CEO > Twitter: @JaimeMartinLosa > > [cid:image001.png at 01CFD978.A5568F10] > The Middleware Experts > > Phone: + 34 91 804 34 48 / > + 34 607 91 37 45 > JaimeMartin at eProsima.com > www.eProsima.com > > > > > > > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From JaimeMartin at eprosima.com Fri Sep 26 13:01:15 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Fri, 26 Sep 2014 11:01:15 +0000 Subject: [Miwi-middleware] Agenda for today's meeting. In-Reply-To: <54254753.5020503@dfki.de> References: <54254753.5020503@dfki.de> Message-ID: <5a709d6ac1574c61afe4794dcf3dfe1d@AM3PR06MB337.eurprd06.prod.outlook.com> Just a minute... Regards, Jaime. -----Original Message----- From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] Sent: viernes, 26 de septiembre de 2014 13:01 To: Jaime Martin Losa; miwi-middleware at lists.fi-ware.eu Subject: Re: [Miwi-middleware] Agenda for today's meeting. Hi, Has someone set up a Hangout link yet? THe lin kin the document points to a session that seems to be over. Best, Philipp Am 26.09.2014 um 10:57 schrieb Jaime Martin Losa: > Here you have, > > https://docs.google.com/document/d/1Nwql8FMMIjxF3A0rEXwcFlM733p8p0yLWh > Eq3URfvhc/edit# > > > Regards, > Jaime Martin Losa > CEO > Twitter: @JaimeMartinLosa > > [cid:image001.png at 01CFD978.A5568F10] > The Middleware Experts > > Phone: + 34 91 804 34 48 / > + 34 607 91 37 45 > JaimeMartin at eProsima.com > www.eProsima.com > > > > > > > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: 09/08/14 Internal Virus Database is out of date. From JaimeMartin at eprosima.com Fri Sep 26 13:02:23 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Fri, 26 Sep 2014 11:02:23 +0000 Subject: [Miwi-middleware] Agenda for today's meeting. In-Reply-To: <5a709d6ac1574c61afe4794dcf3dfe1d@AM3PR06MB337.eurprd06.prod.outlook.com> References: <54254753.5020503@dfki.de> <5a709d6ac1574c61afe4794dcf3dfe1d@AM3PR06MB337.eurprd06.prod.outlook.com> Message-ID: <932e5c558cd54155b44cce5374880138@AM3PR06MB337.eurprd06.prod.outlook.com> https://plus.google.com/hangouts/_/g22tioc2frhrwec7ldw746uu6ua?hl=es Regards, Jaime. -----Original Message----- From: miwi-middleware-bounces at lists.fi-ware.org [mailto:miwi-middleware-bounces at lists.fi-ware.org] On Behalf Of Jaime Martin Losa Sent: viernes, 26 de septiembre de 2014 13:01 To: Philipp Slusallek; miwi-middleware at lists.fi-ware.eu Subject: Re: [Miwi-middleware] Agenda for today's meeting. Just a minute... Regards, Jaime. -----Original Message----- From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] Sent: viernes, 26 de septiembre de 2014 13:01 To: Jaime Martin Losa; miwi-middleware at lists.fi-ware.eu Subject: Re: [Miwi-middleware] Agenda for today's meeting. Hi, Has someone set up a Hangout link yet? THe lin kin the document points to a session that seems to be over. Best, Philipp Am 26.09.2014 um 10:57 schrieb Jaime Martin Losa: > Here you have, > > https://docs.google.com/document/d/1Nwql8FMMIjxF3A0rEXwcFlM733p8p0yLWh > Eq3URfvhc/edit# > > > Regards, > Jaime Martin Losa > CEO > Twitter: @JaimeMartinLosa > > [cid:image001.png at 01CFD978.A5568F10] > The Middleware Experts > > Phone: + 34 91 804 34 48 / > + 34 607 91 37 45 > JaimeMartin at eProsima.com > www.eProsima.com > > > > > > > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: 09/08/14 Internal Virus Database is out of date. _______________________________________________ Miwi-middleware mailing list Miwi-middleware at lists.fi-ware.org https://lists.fi-ware.org/listinfo/miwi-middleware ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: 09/08/14 Internal Virus Database is out of date. From rubinstein at cs.uni-saarland.de Fri Sep 26 14:35:47 2014 From: rubinstein at cs.uni-saarland.de (Dmitri Rubinstein) Date: Fri, 26 Sep 2014 14:35:47 +0200 Subject: [Miwi-middleware] KIARA/DFKI Java Design Document Message-ID: <54255DA3.7010308@cs.uni-saarland.de> Jaime requested me to send this separately. Please note this is a first draft, and I would like to see comments, issues, etc. FYI, in the directory Benchmarks of the kiara-java repository: https://github.com/dmrub/kiara-java/tree/master/Benchmarks you will find user scenario based on http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201004.html implemented with different middlewares: ApacheAxis2 ApacheThrift RMI RabbitMQ Zero ICE Plain Java TCP sockets They are also used for benchmarking. Best, Dmitri -------------- next part -------------- This documents describes design ideas behind the KIARA Java API that was developed by DFKI: https://github.com/dmrub/kiara-java Our starting point was the design of the KIARA/DFKI C/C++ API, but we also took into account features specific to Java. API examples are in KIARA/src/main/java/de/dfki/kiara/example Notes: This API is the result of our internal discussions. We are always open to other ideas and would be happy to consider alternative designs (given suitable suggestions). This API design is driven by the original KIARA ideas about a unified middleware API that -- operates using the native data types of the application, -- supports several different transport mechanisms and protocols, -- supports to negotiate and select a suitable protocol/mechanims at run-time, -- can transfers data directly between the memories of the two application (e.g. by RDMA), -- allows for optimized transformation between the native data and the used protocol formats. This current Java API is designed to support Remote Procedure Call (RPC) pattern, so far. Changes to support PubSub should be minimal and are under consideration now. RDMA-like support might require a small additional API to register instances of data types with the middleware as send/receive buffers. This API is compatible with Java SE version 7 and higher. -- Client -- 1. Opening connection Like in the C++ version we start first with creating context and using it for opening the connection. A URI is used as the universal server address: Context context = Kiara.createContext(); Connection connection = context.openConnection("http://localhost:8080/service"); We assume following IDL in our example: namespace * calc " service calc { i32 add(i32 a, i32 b) float addf(float a, float b) " } After the connection has been opened: 1) An IDL provided by the server under the URL is loaded and parsed 2) The best protocol and transport available by both client and server are selected. 2. Binding Java methods to the IDL As the interface to KIARA will be in terms of the native types of the application, the next step is to bind suitable Java methods (specified/defined through Java interfaces) to the remote service methods provided by the server (and described in the IDL). Later we will invoke the bound Java methods, which will trigger the communication and execute the remote service methods on the server. In the C/C++ API we bind the interface methods to individual functions. Because Java does not support single functions (like .NET delegates or C function pointers), here we bind to methods of a Java interface: 1) User provides Java interface that corresponds to the service that he would like to call: public interface Calc { public int add(int a, int b); public float addFloat(float a, float b); } 2) User uses the generic KIARA class MethodBinding to describe which methods of the interface are bound to which service methods in the IDL provided by the server. MethodBinding binder = new MethodBinding<>(Calc.class) .bind("calc.add", "add") .bind("calc.addf", "addFloat"); The first argument to the bind method is the full name of the service, the second argument is the name of the Java interface method. The third optional variable length argument allows to pass classes in order to identify overloaded interface methods. Parameterizing MethodBinding with the interface type enables KIARA to check whether the passed interface method names are correctly typed. 3. Now the user can generate instance of the interface Calc with bindings registered with MethodBinding class: Calc calc = connection.generateClientFunctions(binder); This operation might throw an exception when the service methods registered through binder are not available in the IDL or when argument or result types are not compatible. All of the above code can easily be hiden in a setup function. Internally our implementation uses java.lang.reflect.Proxy for implementing this. 4. Once the setup it has been performed, the user can now execute remote service methods by calling the generated interface methods: { int result = calc.add(21, 32); System.out.printf("calc.add: result = %d\n", result); } 5. Finally Context and Connection can be closed with the close method: connection.close(); context.close(); A1. Note: Besides the Calc interface the object returned by generateClientFunctions() also implements KIARA's RemoteInterface interface. It can provide additional information about the remote service (e.g. the used connection): RemoteInterface ri = (RemoteInterface) calc; Connection c = ri.getConnection(); -- Server -- 1. Creating the service As in the client we use the C/C++ API as the basis: Context context = Kiara.createContext(); Service service = context.newService(); The service class represents the remote service that is provided by the server. A single server instance can provide multiple services. 2. Specifying the IDL At first user need to define what the service will provide by loading IDL: service.loadServiceIDLFromString("KIARA", "namespace * calc " + "service calc { " + " i32 add(i32 a, i32 b) " + " float addf(float a, float b) " + "} "); 3. Binding the Java class to the IDL Let's assume we are given an implementation of the service as follows: public class CalcImpl { public int add(int a, int b) { return a + b; } public float add(float a, float b) { return a + b; } } Given this implementation, the user can now create an instance of CalcImpl and bind it to the IDL: CalcImpl impl = new CalcImpl(); service.registerServiceFunction("calc.add", impl, "add", Integer.TYPE, Integer.TYPE); service.registerServiceFunction("calc.addf", impl, "addf", Float.TYPE, Float.TYPE); The first argument is the service name, the second argument is the implementation instance, the third argument is the name of the implementing method. The finally arguments provide the types of the arguments. 4. Creating the server. Again this step is similar to the C/C++ API: // Create new server on specified port and host // negotiation document with path: /service Server server = context.newServer("0.0.0.0", port, "/service"); // Register service under the relative URL "/rpc/calc" // and available via "jsonrpc" protocol. // Other options are possible as well. server.addService("/rpc/calc", "jsonrpc", service); // Run server. server.run(); 5. Finally the Context and Server objects can be closed: server.close() context.close() -- Asynchronous API -- What we described before allow us to perform synchronous API calls. However, our API is designed in such a way that no extension is required in order to call methods asynchronously. The user only needs to change signature of the interface by using java.util.concurrent.Future class. For example: public interface Calc { public Future add(int a, int b); public Future addFloat(float a, float b); } Now when we call Calc.add() or Calc.addFloat() methods we will get no immediate results but a future handle. Program execution will continue since we are not waiting for a result. A call to Future.get() will enforce immediate execution and block until result or an error arrives. The only limitation of this approach is that Future type does not support notification of the computation end. We can either block and wait for the result or check if the result is available. As an extension we also support ListenableFuture which provides support for notification callback: https://code.google.com/p/guava-libraries/wiki/ListenableFutureExplained Future-s can be used as argument and result types in both client interfaces and server implementation classes. From rubinstein at cs.uni-saarland.de Sun Sep 28 12:44:35 2014 From: rubinstein at cs.uni-saarland.de (Dmitri Rubinstein) Date: Sun, 28 Sep 2014 12:44:35 +0200 Subject: [Miwi-middleware] KIARA/DFKI Java Design Document Revised Message-ID: <5427E693.6050000@cs.uni-saarland.de> In the attachment is a revised KIARA/DFKI Java Design Document. Comments are as usually welcome. Best, Dmitri -------------- next part -------------- KIARA Java-API Proposal (Draft, Version 0.3, September 29th 2014) by Dmitri Rubinstein und Philipp Slusallek The following document described a scalable API approach for the Java binding of our KIARA middleware. It is a proposal and subject to change. Specifically this is not a formal definition yet but instead describes our approach for the purpose of early internal discussions about other suggestions. Upfront let us define some terminology that we are using. Instead of "static" and "dynamic" we are using the term "IDL-derived" and "application-derived" to distinguis between the API used in the current version of KIARA and the traditional ones used in other middleware. Note that both cases are static in the sense that they define a fixed mapping of some data static type to a message at compile time. The mapping cannot be changed during run time. This is in contrast to a truely dynamic API where a request can be programmatically constructed. We might want to add this eventually (as discussed already before) and should therefore reserve the name dynamic for that case. These terms apply to the API used to send data via the middleware as well as to the management interface for setting up the communication. It can also be used to describe interface functions and the data types used in the process. Our goal was to design an API that is *scalable*, where simple thing can be done with a simple API but where advanced functionality is also available with the same identical base API but they might require the use of some additional API calls. Due to the original KIARA API design being flexible and generic, the addition of the IDL-derived API has actually been pretty straight forward and integrates well with the existing KIARA API as shown below. Since we want to move fast and are now focusing on the design of a simple (traditional) API for RPC-style communication, we compare in this document three API versions: i) The current Thrift API (Java) as an expample for a traditional middleware API (IDL-derived), ii) Our proposed simple IDL-derived KIARA API (called static previously) iii) And our current KIARA-API using the application-derived approach as described before. We hope that it shows nicely how the case (iii), which we have advocated since the beginnng, is a natural extension of the traditional API approach and actually integrates nicely with it. We also show that there is hardly any difference between a traditional API (Thrift in this case) and the new IDL-derived variant of the KIARA API. So there should be no reason to perfer the one over the other. We argue for the now proposed API as it is part of athe scalable API design that enables us to also expose in a straight forward way the much more powerful API that we have used in KIARA so far. We also shows that the traditional API can simply be seen as an API where the programmer does not have native types (yet) to be used in the middleware comunication or simply prefers to let these types be defined by the middleware (for whatever reason). There are no *conceptual differences* in the API between the IDL and application derived approaches. This is actually an important point as it makes it almost trivial to switch between the two approaches. This might happen for example as the internal data types of an application change (e.g. during refactoring) while the external API should stay the same (or vice versa). In that case, the developer can simply declare the new internal data types to the middleware, define the mapping for the new types (simple), and go on as if nothing has ever happened. 1. IDL definition We proposed to use the Thrift IDL as also suggested by Jaime before. The current KIARA IDL is almost identical to the Thrift version with a few additions (mainly for annotations). For the following comparison we use the example from the middleware comparison at http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201004.html. We use this example as we have used the exact same example also for our benchmarks, testing, and perfromance comparisons of our KIARA implementation with a significant number of other middleware implementations (see Dmitri's email from Friday). Here are data types used (appreviated): struct MarketDataEntry { ... } struct MarketData { ... } struct RelatedSym { ... } struct QuoteRequest { ... } service Benchmark { MarketData sendMarketData(1:MarketData marketData); QuoteRequest sendQuoteRequest(1:QuoteRequest quoteRequest); } 2. Preparation of Data Types a) Thrift Thrift requires an IDL to source code generation pass at compile time, which will produce following files: Benchmark.java - synchronous and asynchronous interfaces MarketData.java - class representing struct MarketData MarketDataEntry.java - class representing struct MarketDataEntry QuoteRequest.java - class representing struct QuoteRequest RelatedSym.java - class representing struct RelatedSym b) KIARA (IDL-derived API) The KIARA API can use the same IDL-derived API approach. This requires the same generation of stubs and skeletons. We can probably completely reuse the Thrift code generation here. However, as shown below, the user will not instantiate these types and API functions directly but requests them via the KIARA API, which will automatically take care of instantiation and initialization of that code. We argue that this is actually a cleaner approach from a SW-Engineering point of view than the traditional way. The differences to Thrift are minimal. c) KIARA (application-derived API) This KIARA API does not require any code generation at compile time, however users need to define an interface they want to use for the communication. This step is usually quite simple, since the user can use data types that are already used in the application. In the example below we are using data types that have a 1:1 relationship with the IDL that will be used. More complex mappings are possible as shown in our C/C++ version of the API but are not yet implemented for Java. So the developer simply defines an interface in terms of native data structures as follows: public static interface Benchmark { public MarketData sendMarketData(MarketData marketData); public QuoteRequest sendQuoteRequest(QuoteRequest quoteRequest); } 3. Client: Opening connection and making a call The following code described the basic API calls that a client has to do to establish a connection to a service and use it. a) Thrift Thrift requires an explicit instantiation of transport and protocol layers. This enforces that the application has to explicitly manage these aspects in all cases. TTransport transport = new TSocket(host, 9090); TProtocol protocol = new TBinaryProtocol(transport); // Benchmark.Client is a stub generated by the Thrift IDL compiler Benchmark.Client client = new Benchmark.Client(protocol); transport.open(); // Make a call client.sendQuoteRequest(Util.createQuoteRequestData()); Note, that there is no security here. Any security has to be managed explicitly by the application and would make setting up the connection *significantly* more complex (managing certificates, agreeing on common security mechanisms to be used on both sides, setting up the security mechanism, etc.) b) KIARA (IDL-derived API) KIARA requires no explicit instantiation, but only the URI of the server. Since the data at this URL describes the service to be used, KIARA is able to derive the best connection details (transport mechanism and transport protocol) automatically (negotiation). Note that a similar step is required anyway to properly handle security between the two peers. However, KIARA can handle this internally based on security policies defined by the application through either the IDL or via the API (not shown here yet, but already in the C/C++ version). This negotiation is only done once during setup of the connection and can be influenced by the applications (also not shown here). Context context = Kiara.createContext(); Connection connection = context.openConnection("http://localhost:8080/benchmarkService"); // Note that Connection.getServiceInterface() is a generic // method, it uses Class.forName() to dynamically load the // IDL-derived and precompiled class Benchmark.Stub Benchmark Benchmark client = connection.getServiceInterface(Benchmark.class); // A call to the remote service then looks exactly as in Thrift client.sendQuoteRequest(Util.createQuoteRequestData()); c) KIARA Client (application-derived API) Context context = Kiara.createContext(); Connection connection = context.openConnection("http://localhost:8080/service"); // In the case of 1:1 mapping the API actually looks identical to // the case with the IDL-derived API. // Note: The type Benchmark is the one defined by the application // (not the middleware) in step 2c above. Benchmark client = connection.getServiceInterface(Benchmark.class); // A call is done in the same way as in Thrift client.sendQuoteRequest(Util.createQuoteRequestData()); Note that making a call (which is really the critical aspect of the API as this is what is used throughout the application code) is absolutely identical across both the KIARA and Thrift APIs. The only differences are in the opening of a connection and requesting the stub to be used. Extension: In case that a mapping is needed between the application-defined types and the IDL types we can additionally provide such a mapping before requesting the interface. Below we show a simple case of an 1:1 mapping explicitly given through the API (more complex cases can be defined and are implemented already in the C/C++ version of KIARA). // Because Benchmark interface is defined by the user, // we need to tell KIARA how to bind its methods to IDL methods MethodBinding binder = new MethodBinding<>(Benchmark.class) .bind("benchmark.sendMarketData", "sendMarketData") .bind("benchmark.sendQuoteRequest", "sendQuoteRequest"); // In this step we get the stub implementation generated by KIARA Benchmark client = connection.getServiceInterface(binder); As shown this simply requires a single new API call that established the mapping between API and IDL data types and interfaces. It is only required if complex mapping are required (see example above). As part of the BMBF project ARVIDA we are aurrently defining semantic API descriptions that would even allow us to derive these mapping from the additional semantic information automatically. This will require only a few changes to the extended API described here. 4. Server: Defining the service to be called a) Thrift Again Thrift requires explicit instantiation of transport and protocol layers: // BenchmarkHandler is a skeleton generated by the Thrift IDL compiler // and implemented by the user BenchmarkHandler handler = new BenchmarkHandler(); Benchmark.Processor processor = new Benchmark.Processor(handler); TServerTransport serverTransport = new TServerSocket(9090); TServer server = new TSimpleServer(new Args(serverTransport).processor(processor)); server.serve(); b) KIARA (IDL-derived API) In the IDL-defined API server initialization is straight forward. Common initialization code: Context context = Kiara.createContext(); Service service = context.newService(); Defining the service then is trivial and actually even simple than with Thrift. // BenchmarkImpl skeleton is generated by the IDL compiler // and then implemented by the user in a derived class BenchmarkImpl benchmarkImpl = new BenchmarkUserImpl(); // Since mapping is known to the KIARA, registration is simple service.register(benchmarkImpl); KIARA automatically handles all negotiations of transport mechanisms, transport protocols, and security mechanisms based on information provided to it (not shown here yet). By default it offers all options on all network interfaces and chooses the most appropriate one supported by both peers at runtime. Final server construction and execution, which is same in both KIARA cases (IDL- and application-derived): // Create a server and register service, with the default setting Server server = context.newServer("benchmarkService"); server.addService(service); server.run(); This sets up a basic KIARA server on the local machine. It provides the service descriptions of all added services (in JSON) via an embedded HTTP server using the given name as the local base URL. By default this server listens on all network interfaces using port 8080. Adding a new service makes that available via the server as well. By default it listens on a separate port that is advertised via the service description of the server. These default policies can be also be overridden if needed: Server server = context.newServer("0.0.0.0", port, "benchmarkService"); server.addService("tcp://0.0.0.0:53212", protocol, service); c) KIARA (application-derived API) Again the IDL- and application derived APIs are very similar. The main difference is that in the application-derived approach, the stubs and skeletons are derived from the IDL, which is also made available to the remote clients as part of the setup. Thus, the IDL must be declared to KIARA first. // The following step is unique to the app-derived KIARA since it // generates stubs and skeletons at the runtime based on the IDL, // which is defined here (or possible through a file, network, or // such) service.loadServiceIDLFromString(KIARA_IDL, "namespace * benchmark" + "..."); Optionally, we could also generate the IDL from the interface of an application defined type directly. This is much simpler of course but has the danger that it implicitly changes the IDL whenever the internal interfaces might change. At some point this is an issue of taste and a trade-off between development speed and interface stability. Note, that the API allow to annotate the interface in a suitable way (not shown here yet for simplicity). // Generate service IDL from interfaces service.generateIDLFromInterface(Benchmark.class); Once the IDL is defined we can simply instantiate and register the service implementation with KIARA. This is as simple as it gets: // BenchmarkUserImpl is an implementation of the Benchmark // interface as defined by the user BenchmarkUserImpl benchmarkImpl = new BenchmarkUserImpl(); // In case of a 1:1 mapping between the IDL and the // application-specific service implementation we can // simply register the service directly service.registerService(benchmarkImpl); In case a mapping between the IDL and the application data types/interfaces in necessary, this can *optionally* be provided as well by registering each service function separately: // We need to register BenchmarkUserImpl methods with IDL methods // for correct dispatch. We register the services individually as not // all services may need to be proided here service.registerServiceFunction( "benchmark.sendMarketData", benchmarkUserImpl, "sendMarketData"); service.registerServiceFunction( "benchmark.sendQuoteRequest", benchmarkUserImpl, "sendQuoteRequest"); 5. Advanced mapping for the IDL-generated KIARA API IDL-derived approaches normally have a single fixed mapping from the IDL to specific data types of a given language (Java here). We propose to allow to specify variants of this mapping when compiling the IDL to Java code. Such a 'mapping' document would define how to map generic data types that can be used in the Thrift IDL to a selection of specific but compatible data types in Java, e.g.: Thrift IDL Java ------------------------- list -> Collection or List or T[] set -> Set or Collection or List or T[] map -> Map or List> where the KeyValuePair class is defined by the user Additionally, in an exteneded version this approach could also be used to map IDL tapes to essentially arbitrary application data types. This would be similar to the mappings defined in the Java API (see above) but would be compiled into the "static" stubs and skeletons. Essentially, this would be an intermediate form where the mapping between IDL and application types is predefined at compile time. The stubs and skeletons can then be generated in advance. This has not been worked out in detail yet, but look slike an interesting option. For the simple case, one of the ways to achieve this is to provide text templates of some form, e.g.: list<$T> = List<$T> where $NAME at the left side corresponds to the IDL type and on the right side to the application type. For example: list<$T> = $T[] set<$T> = Set<$T> map<$K,$V> = List> TODO: Adding of elements to the array, list, set, and map is a different operation, which would require templates as well. Possibly the best approach is to use template engine like Apache Velocity Templates which could drive the code generator: http://www.onjava.com/pub/a/onjava/2004/05/05/cg-vel1.html From philipp.slusallek at dfki.de Sun Sep 28 13:35:16 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Sun, 28 Sep 2014 13:35:16 +0200 Subject: [Miwi-middleware] KIARA/DFKI Java Design Document Revised In-Reply-To: <5427E693.6050000@cs.uni-saarland.de> References: <5427E693.6050000@cs.uni-saarland.de> Message-ID: <5427F274.9070609@dfki.de> Hi, Thanks Dmitri! We had a discussion after our call on Friday and refined out ideas about the "IDL-derived" API (see email for an explanation for using that term). Dmitri has worked out all the details and came up with a great approach: After a quick iteration, we now provide our view on the upcoming Java-API to all. Please have a look and provide feedback and comments! I believe that we have found a nice way of integrating the IDL-derived API such that it is almost identical to traditional middleware API where the API is derived from the IDL (which we called "static" before). Specifically, we compare our proposed API directly to Thrift and point out why it is equally simple (actually simpler), but more powerful and more scalable. I am really like the approach about how well it compares to traditional designs but allows for going well beyond those. We had discussed this "static" API before with Jaime in our meetings and thought that it would work out well, but this is the first time we worked through all (most?) of the details. There is certainly room for improvements or alternative implementations, though. We would like to hear your input as well as look at and compare this with your proposals as planned Extensions: Scalability: By adding some new calls we can extend/scale the API to also support the application-derived API that we contributed to the core of KIARA in the original proposal. As you can see its fits nicely with the IDL-derived API, which is a good thing. Security: We have not included our thoughts on security yet (as discussed) but they can be nicely integrated and then offer significantly better and fully automatic security features. We are happy to present those ideas later, when appropriate. Asynchronous and threads: There are a number of other extensions that we have in mind regarding threading, asynchronous calls, and object references that we have excluded. they should be easily added to what we have now. Again we are happy to discuss those, when you want. Finally a last aspect: This API design can be transferred to C/C++ with some small changes. the same simplicity of the base API and scalability applies there. It then avoid some of the (internal) complexity at the cost of a more static behavior. But we then offer both. Best, Philipp P.S.: Off the record (as we are only discussing API design for now): The proposed API can be implemented pretty quickly given our current Java version. In case someone wants to already evaluate that option and see if they agree or not agree on our implementation choices, feel free to look at and comment the code from Dmitri. Since it is Java and we are not (yet) doing the runtime compilation it should be nicely readable and understandable. We are very much open to suggestion to improve that code base where necessary. It is certainly not as well optimzed as the C/C++ code yet. Jaime: I would still be highly interested in the joint uKIARA implementation and us jointly developing this. As we discussed in Madrid, as a research institute we cannot maintain and support our KIARA the code forever. And particularly for industry customers having a commercial support option is really interesting, if not mandatory. It would be nice if we may be able find better agreement along those lines. With the "static" API we might now have a good basis for that, where you can offer a good basis version that you are familiar with and we can add all the fancy thing on top of that (including security) that is critical to us and that you might eventually also be interested and confident in. Note that our Java code is already interoperable with the C/C++ version of KIARA as as well as the C# and JS versions. Am 28.09.2014 um 12:44 schrieb Dmitri Rubinstein: > In the attachment is a revised KIARA/DFKI Java Design Document. Comments > are as usually welcome. > > Best, > > Dmitri > > > > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From Dmitri.Rubinstein at dfki.de Sun Sep 28 12:43:55 2014 From: Dmitri.Rubinstein at dfki.de (Dmitri Rubinstein) Date: Sun, 28 Sep 2014 12:43:55 +0200 Subject: [Miwi-middleware] KIARA/DFKI Java Design Document Revised Message-ID: <5427E66B.6010808@dfki.de> In the attachment is a revised KIARA/DFKI Java Design Document. Comments are as usually welcome. Best, Dmitri -------------- next part -------------- KIARA Java-API Proposal (Draft, Version 0.3, September 29th 2014) by Dmitri Rubinstein und Philipp Slusallek The following document described a scalable API approach for the Java binding of our KIARA middleware. It is a proposal and subject to change. Specifically this is not a formal definition yet but instead describes our approach for the purpose of early internal discussions about other suggestions. Upfront let us define some terminology that we are using. Instead of "static" and "dynamic" we are using the term "IDL-derived" and "application-derived" to distinguis between the API used in the current version of KIARA and the traditional ones used in other middleware. Note that both cases are static in the sense that they define a fixed mapping of some data static type to a message at compile time. The mapping cannot be changed during run time. This is in contrast to a truely dynamic API where a request can be programmatically constructed. We might want to add this eventually (as discussed already before) and should therefore reserve the name dynamic for that case. These terms apply to the API used to send data via the middleware as well as to the management interface for setting up the communication. It can also be used to describe interface functions and the data types used in the process. Our goal was to design an API that is *scalable*, where simple thing can be done with a simple API but where advanced functionality is also available with the same identical base API but they might require the use of some additional API calls. Due to the original KIARA API design being flexible and generic, the addition of the IDL-derived API has actually been pretty straight forward and integrates well with the existing KIARA API as shown below. Since we want to move fast and are now focusing on the design of a simple (traditional) API for RPC-style communication, we compare in this document three API versions: i) The current Thrift API (Java) as an expample for a traditional middleware API (IDL-derived), ii) Our proposed simple IDL-derived KIARA API (called static previously) iii) And our current KIARA-API using the application-derived approach as described before. We hope that it shows nicely how the case (iii), which we have advocated since the beginnng, is a natural extension of the traditional API approach and actually integrates nicely with it. We also show that there is hardly any difference between a traditional API (Thrift in this case) and the new IDL-derived variant of the KIARA API. So there should be no reason to perfer the one over the other. We argue for the now proposed API as it is part of athe scalable API design that enables us to also expose in a straight forward way the much more powerful API that we have used in KIARA so far. We also shows that the traditional API can simply be seen as an API where the programmer does not have native types (yet) to be used in the middleware comunication or simply prefers to let these types be defined by the middleware (for whatever reason). There are no *conceptual differences* in the API between the IDL and application derived approaches. This is actually an important point as it makes it almost trivial to switch between the two approaches. This might happen for example as the internal data types of an application change (e.g. during refactoring) while the external API should stay the same (or vice versa). In that case, the developer can simply declare the new internal data types to the middleware, define the mapping for the new types (simple), and go on as if nothing has ever happened. 1. IDL definition We proposed to use the Thrift IDL as also suggested by Jaime before. The current KIARA IDL is almost identical to the Thrift version with a few additions (mainly for annotations). For the following comparison we use the example from the middleware comparison at http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201004.html. We use this example as we have used the exact same example also for our benchmarks, testing, and perfromance comparisons of our KIARA implementation with a significant number of other middleware implementations (see Dmitri's email from Friday). Here are data types used (appreviated): struct MarketDataEntry { ... } struct MarketData { ... } struct RelatedSym { ... } struct QuoteRequest { ... } service Benchmark { MarketData sendMarketData(1:MarketData marketData); QuoteRequest sendQuoteRequest(1:QuoteRequest quoteRequest); } 2. Preparation of Data Types a) Thrift Thrift requires an IDL to source code generation pass at compile time, which will produce following files: Benchmark.java - synchronous and asynchronous interfaces MarketData.java - class representing struct MarketData MarketDataEntry.java - class representing struct MarketDataEntry QuoteRequest.java - class representing struct QuoteRequest RelatedSym.java - class representing struct RelatedSym b) KIARA (IDL-derived API) The KIARA API can use the same IDL-derived API approach. This requires the same generation of stubs and skeletons. We can probably completely reuse the Thrift code generation here. However, as shown below, the user will not instantiate these types and API functions directly but requests them via the KIARA API, which will automatically take care of instantiation and initialization of that code. We argue that this is actually a cleaner approach from a SW-Engineering point of view than the traditional way. The differences to Thrift are minimal. c) KIARA (application-derived API) This KIARA API does not require any code generation at compile time, however users need to define an interface they want to use for the communication. This step is usually quite simple, since the user can use data types that are already used in the application. In the example below we are using data types that have a 1:1 relationship with the IDL that will be used. More complex mappings are possible as shown in our C/C++ version of the API but are not yet implemented for Java. So the developer simply defines an interface in terms of native data structures as follows: public static interface Benchmark { public MarketData sendMarketData(MarketData marketData); public QuoteRequest sendQuoteRequest(QuoteRequest quoteRequest); } 3. Client: Opening connection and making a call The following code described the basic API calls that a client has to do to establish a connection to a service and use it. a) Thrift Thrift requires an explicit instantiation of transport and protocol layers. This enforces that the application has to explicitly manage these aspects in all cases. TTransport transport = new TSocket(host, 9090); TProtocol protocol = new TBinaryProtocol(transport); // Benchmark.Client is a stub generated by the Thrift IDL compiler Benchmark.Client client = new Benchmark.Client(protocol); transport.open(); // Make a call client.sendQuoteRequest(Util.createQuoteRequestData()); Note, that there is no security here. Any security has to be managed explicitly by the application and would make setting up the connection *significantly* more complex (managing certificates, agreeing on common security mechanisms to be used on both sides, setting up the security mechanism, etc.) b) KIARA (IDL-derived API) KIARA requires no explicit instantiation, but only the URI of the server. Since the data at this URL describes the service to be used, KIARA is able to derive the best connection details (transport mechanism and transport protocol) automatically (negotiation). Note that a similar step is required anyway to properly handle security between the two peers. However, KIARA can handle this internally based on security policies defined by the application through either the IDL or via the API (not shown here yet, but already in the C/C++ version). This negotiation is only done once during setup of the connection and can be influenced by the applications (also not shown here). Context context = Kiara.createContext(); Connection connection = context.openConnection("http://localhost:8080/benchmarkService"); // Note that Connection.getServiceInterface() is a generic // method, it uses Class.forName() to dynamically load the // IDL-derived and precompiled class Benchmark.Stub Benchmark Benchmark client = connection.getServiceInterface(Benchmark.class); // A call to the remote service then looks exactly as in Thrift client.sendQuoteRequest(Util.createQuoteRequestData()); c) KIARA Client (application-derived API) Context context = Kiara.createContext(); Connection connection = context.openConnection("http://localhost:8080/service"); // In the case of 1:1 mapping the API actually looks identical to // the case with the IDL-derived API. // Note: The type Benchmark is the one defined by the application // (not the middleware) in step 2c above. Benchmark client = connection.getServiceInterface(Benchmark.class); // A call is done in the same way as in Thrift client.sendQuoteRequest(Util.createQuoteRequestData()); Note that making a call (which is really the critical aspect of the API as this is what is used throughout the application code) is absolutely identical across both the KIARA and Thrift APIs. The only differences are in the opening of a connection and requesting the stub to be used. Extension: In case that a mapping is needed between the application-defined types and the IDL types we can additionally provide such a mapping before requesting the interface. Below we show a simple case of an 1:1 mapping explicitly given through the API (more complex cases can be defined and are implemented already in the C/C++ version of KIARA). // Because Benchmark interface is defined by the user, // we need to tell KIARA how to bind its methods to IDL methods MethodBinding binder = new MethodBinding<>(Benchmark.class) .bind("benchmark.sendMarketData", "sendMarketData") .bind("benchmark.sendQuoteRequest", "sendQuoteRequest"); // In this step we get the stub implementation generated by KIARA Benchmark client = connection.getServiceInterface(binder); As shown this simply requires a single new API call that established the mapping between API and IDL data types and interfaces. It is only required if complex mapping are required (see example above). As part of the BMBF project ARVIDA we are aurrently defining semantic API descriptions that would even allow us to derive these mapping from the additional semantic information automatically. This will require only a few changes to the extended API described here. 4. Server: Defining the service to be called a) Thrift Again Thrift requires explicit instantiation of transport and protocol layers: // BenchmarkHandler is a skeleton generated by the Thrift IDL compiler // and implemented by the user BenchmarkHandler handler = new BenchmarkHandler(); Benchmark.Processor processor = new Benchmark.Processor(handler); TServerTransport serverTransport = new TServerSocket(9090); TServer server = new TSimpleServer(new Args(serverTransport).processor(processor)); server.serve(); b) KIARA (IDL-derived API) In the IDL-defined API server initialization is straight forward. Common initialization code: Context context = Kiara.createContext(); Service service = context.newService(); Defining the service then is trivial and actually even simple than with Thrift. // BenchmarkImpl skeleton is generated by the IDL compiler // and then implemented by the user in a derived class BenchmarkImpl benchmarkImpl = new BenchmarkUserImpl(); // Since mapping is known to the KIARA, registration is simple service.register(benchmarkImpl); KIARA automatically handles all negotiations of transport mechanisms, transport protocols, and security mechanisms based on information provided to it (not shown here yet). By default it offers all options on all network interfaces and chooses the most appropriate one supported by both peers at runtime. Final server construction and execution, which is same in both KIARA cases (IDL- and application-derived): // Create a server and register service, with the default setting Server server = context.newServer("benchmarkService"); server.addService(service); server.run(); This sets up a basic KIARA server on the local machine. It provides the service descriptions of all added services (in JSON) via an embedded HTTP server using the given name as the local base URL. By default this server listens on all network interfaces using port 8080. Adding a new service makes that available via the server as well. By default it listens on a separate port that is advertised via the service description of the server. These default policies can be also be overridden if needed: Server server = context.newServer("0.0.0.0", port, "benchmarkService"); server.addService("tcp://0.0.0.0:53212", protocol, service); c) KIARA (application-derived API) Again the IDL- and application derived APIs are very similar. The main difference is that in the application-derived approach, the stubs and skeletons are derived from the IDL, which is also made available to the remote clients as part of the setup. Thus, the IDL must be declared to KIARA first. // The following step is unique to the app-derived KIARA since it // generates stubs and skeletons at the runtime based on the IDL, // which is defined here (or possible through a file, network, or // such) service.loadServiceIDLFromString(KIARA_IDL, "namespace * benchmark" + "..."); Optionally, we could also generate the IDL from the interface of an application defined type directly. This is much simpler of course but has the danger that it implicitly changes the IDL whenever the internal interfaces might change. At some point this is an issue of taste and a trade-off between development speed and interface stability. Note, that the API allow to annotate the interface in a suitable way (not shown here yet for simplicity). // Generate service IDL from interfaces service.generateIDLFromInterface(Benchmark.class); Once the IDL is defined we can simply instantiate and register the service implementation with KIARA. This is as simple as it gets: // BenchmarkUserImpl is an implementation of the Benchmark // interface as defined by the user BenchmarkUserImpl benchmarkImpl = new BenchmarkUserImpl(); // In case of a 1:1 mapping between the IDL and the // application-specific service implementation we can // simply register the service directly service.registerService(benchmarkImpl); In case a mapping between the IDL and the application data types/interfaces in necessary, this can *optionally* be provided as well by registering each service function separately: // We need to register BenchmarkUserImpl methods with IDL methods // for correct dispatch. We register the services individually as not // all services may need to be proided here service.registerServiceFunction( "benchmark.sendMarketData", benchmarkUserImpl, "sendMarketData"); service.registerServiceFunction( "benchmark.sendQuoteRequest", benchmarkUserImpl, "sendQuoteRequest"); 5. Advanced mapping for the IDL-generated KIARA API IDL-derived approaches normally have a single fixed mapping from the IDL to specific data types of a given language (Java here). We propose to allow to specify variants of this mapping when compiling the IDL to Java code. Such a 'mapping' document would define how to map generic data types that can be used in the Thrift IDL to a selection of specific but compatible data types in Java, e.g.: Thrift IDL Java ------------------------- list -> Collection or List or T[] set -> Set or Collection or List or T[] map -> Map or List> where the KeyValuePair class is defined by the user Additionally, in an exteneded version this approach could also be used to map IDL tapes to essentially arbitrary application data types. This would be similar to the mappings defined in the Java API (see above) but would be compiled into the "static" stubs and skeletons. Essentially, this would be an intermediate form where the mapping between IDL and application types is predefined at compile time. The stubs and skeletons can then be generated in advance. This has not been worked out in detail yet, but look slike an interesting option. For the simple case, one of the ways to achieve this is to provide text templates of some form, e.g.: list<$T> = List<$T> where $NAME at the left side corresponds to the IDL type and on the right side to the application type. For example: list<$T> = $T[] set<$T> = Set<$T> map<$K,$V> = List> TODO: Adding of elements to the array, list, set, and map is a different operation, which would require templates as well. Possibly the best approach is to use template engine like Apache Velocity Templates which could drive the code generator: http://www.onjava.com/pub/a/onjava/2004/05/05/cg-vel1.html From JaimeMartin at eprosima.com Mon Sep 29 15:28:18 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Mon, 29 Sep 2014 13:28:18 +0000 Subject: [Miwi-middleware] API Spec Template Message-ID: <4b675ee6cc0d40709bb4c653be17d937@AMSPR06MB344.eurprd06.prod.outlook.com> Hi all, Here I send you an example of a simple API OMG Spec. Our second submission for RPC over DDS. The first step is to define a set of high level requirements, what they call RFP (Request For Proposal) in which they define the scope of the problem to solve. This should really be our first step to write together in the same direction. We (eProsima) are studing the problem, and I will say a RFP later today, but as a guide, remember: 1.- RPC Static API from and IDL. 2.- Java oriented. 3.- Keep it simple for the first release. Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFDBF9.8E707CB0] The Middleware Experts Phone: + 34 91 804 34 48 / + 34 607 91 37 45 JaimeMartin at eProsima.com www.eProsima.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3800 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: eProsima Revised Submission OMG RFP 12-06-29 RPCDDS.odt Type: application/octet-stream Size: 102339 bytes Desc: eProsima Revised Submission OMG RFP 12-06-29 RPCDDS.odt URL: From JaimeMartin at eprosima.com Mon Sep 29 17:35:18 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Mon, 29 Sep 2014 15:35:18 +0000 Subject: [Miwi-middleware] KIARA/DFKI Java Design Document Revised In-Reply-To: <5427F274.9070609@dfki.de> References: <5427E693.6050000@cs.uni-saarland.de> <5427F274.9070609@dfki.de> Message-ID: Hi Philipp, Some quick points: 1.- When I said something similar to Thrift, I am not proposing to use the Thrift IDL as you say in your document, but just the simple approach they use. As a matter of fact, I would prefer something based on the OMG IDL adding some modern types. 2.- I send you the current and probably almost final status of our submission for RPC over DDS standard. In this submission we made a big effort to convince RTI and Prismtech to keep the function call stype API as simple as possible, and you will see several similarities with the thrift API (see 8.10.2.2.1). 3.- We will start the implementation from Zero. As you know we have also Tons of code, and our own version of a Thrift-like RPC middleware, our RPC over TCP, already on our Git hub, and ready to be released. We are not going to use your code as a base. First, let's design, and later perhaps we could re-use some ideas and code. 4.- It is not the new API should adapt to our current developments, but the other way around. 5.- About the commercial support: In order to support this new KIARA release afterwards, we need something near to our current specifications, or somehow compatible, and practical. The dynamic or "application derived API", cannot be the central piece of the product in order to make it successful. For me it is an interesting idea, and we implemented our interpreter: http://www.eprosima.com/index.php/es/products-all/eprosima-dynamic-fast-buffers But it cannot be the main actor in our new KIARA release if we want a big adoption. Most of the developers do not know about middleware, and for most of them, dynamic typing is a very advanced feature. Regards, Jaime. -----Original Message----- From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] Sent: domingo, 28 de septiembre de 2014 13:35 To: Dmitri Rubinstein; KIARA Mailing List; Jaime Martin Losa Subject: Re: [Miwi-middleware] KIARA/DFKI Java Design Document Revised Hi, Thanks Dmitri! We had a discussion after our call on Friday and refined out ideas about the "IDL-derived" API (see email for an explanation for using that term). Dmitri has worked out all the details and came up with a great approach: After a quick iteration, we now provide our view on the upcoming Java-API to all. Please have a look and provide feedback and comments! I believe that we have found a nice way of integrating the IDL-derived API such that it is almost identical to traditional middleware API where the API is derived from the IDL (which we called "static" before). Specifically, we compare our proposed API directly to Thrift and point out why it is equally simple (actually simpler), but more powerful and more scalable. I am really like the approach about how well it compares to traditional designs but allows for going well beyond those. We had discussed this "static" API before with Jaime in our meetings and thought that it would work out well, but this is the first time we worked through all (most?) of the details. There is certainly room for improvements or alternative implementations, though. We would like to hear your input as well as look at and compare this with your proposals as planned Extensions: Scalability: By adding some new calls we can extend/scale the API to also support the application-derived API that we contributed to the core of KIARA in the original proposal. As you can see its fits nicely with the IDL-derived API, which is a good thing. Security: We have not included our thoughts on security yet (as discussed) but they can be nicely integrated and then offer significantly better and fully automatic security features. We are happy to present those ideas later, when appropriate. Asynchronous and threads: There are a number of other extensions that we have in mind regarding threading, asynchronous calls, and object references that we have excluded. they should be easily added to what we have now. Again we are happy to discuss those, when you want. Finally a last aspect: This API design can be transferred to C/C++ with some small changes. the same simplicity of the base API and scalability applies there. It then avoid some of the (internal) complexity at the cost of a more static behavior. But we then offer both. Best, Philipp P.S.: Off the record (as we are only discussing API design for now): The proposed API can be implemented pretty quickly given our current Java version. In case someone wants to already evaluate that option and see if they agree or not agree on our implementation choices, feel free to look at and comment the code from Dmitri. Since it is Java and we are not (yet) doing the runtime compilation it should be nicely readable and understandable. We are very much open to suggestion to improve that code base where necessary. It is certainly not as well optimzed as the C/C++ code yet. Jaime: I would still be highly interested in the joint uKIARA implementation and us jointly developing this. As we discussed in Madrid, as a research institute we cannot maintain and support our KIARA the code forever. And particularly for industry customers having a commercial support option is really interesting, if not mandatory. It would be nice if we may be able find better agreement along those lines. With the "static" API we might now have a good basis for that, where you can offer a good basis version that you are familiar with and we can add all the fancy thing on top of that (including security) that is critical to us and that you might eventually also be interested and confident in. Note that our Java code is already interoperable with the C/C++ version of KIARA as as well as the C# and JS versions. Am 28.09.2014 um 12:44 schrieb Dmitri Rubinstein: > In the attachment is a revised KIARA/DFKI Java Design Document. > Comments are as usually welcome. > > Best, > > Dmitri > > > > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4765 / Virus Database: 4015/8172 - Release Date: 09/08/14 Internal Virus Database is out of date. -------------- next part -------------- A non-text attachment was scrubbed... Name: RPC-over-DDS-RTI-submission-v5-sut.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 487803 bytes Desc: RPC-over-DDS-RTI-submission-v5-sut.docx URL: From JaimeMartin at eprosima.com Mon Sep 29 18:43:36 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Mon, 29 Sep 2014 16:43:36 +0000 Subject: [Miwi-middleware] NEW KIARA RFP Message-ID: <91bd4e1d8e524dfdb2402c44203ca48f@AMSPR06MB344.eurprd06.prod.outlook.com> Hi All, Here you have a non-very formal Request For Proposal, let me know if you are ok with this. Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFDC15.486ADAA0] The Middleware Experts Phone: + 34 91 804 34 48 / + 34 607 91 37 45 JaimeMartin at eProsima.com www.eProsima.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3800 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NEW KIARA RPC Request For Proposal.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 9671 bytes Desc: NEW KIARA RPC Request For Proposal.docx URL: From JaimeMartin at eprosima.com Mon Sep 29 18:55:06 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Mon, 29 Sep 2014 16:55:06 +0000 Subject: [Miwi-middleware] Tomorrow morning meeting: 9.00 am Message-ID: Hi All, To discuss the RFP let's have a hang out at 9.00 am, to follow all the same direction in our submissions. Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFDC16.5600FBD0] The Middleware Experts Phone: + 34 91 804 34 48 / + 34 607 91 37 45 JaimeMartin at eProsima.com www.eProsima.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3800 bytes Desc: image001.png URL: From JaimeMartin at eprosima.com Mon Sep 29 18:56:35 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Mon, 29 Sep 2014 16:56:35 +0000 Subject: [Miwi-middleware] NEW KIARA RFP Meeting Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1484 bytes Desc: not available URL: From philipp.slusallek at dfki.de Tue Sep 30 07:27:07 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Tue, 30 Sep 2014 07:27:07 +0200 Subject: [Miwi-middleware] KIARA/DFKI Java Design Document Revised In-Reply-To: References: <5427E693.6050000@cs.uni-saarland.de> <5427F274.9070609@dfki.de> Message-ID: <542A3F2B.2080204@dfki.de> Hi, As a basis for our discussion this morning and as documentation, I am summarizing our thoughts on your mail suggestion. Am 29.09.2014 um 17:35 schrieb Jaime Martin Losa: > 1.- When I said something similar to Thrift, I am not proposing to > use the Thrift IDL as you say in your document, but just the simple > approach they use. As a matter of fact, I would prefer something > based on the OMG IDL adding some modern types. First of all, the exact choice of IDL is probably not that important as long as basic requirements are met (as listed in your document from yesterday). Technically, they are essentially all describing the same thing -- just with different syntax and the effect on the user is minimal. There are a few important requirements that we need to fulfill in order to ensure that we have a powerful enough syntax to express QoS, security-related, or other necessary annotations. See our IDL specification for details. Dmitri can answer any questions in that regard. As you have seen we have proposed a Thrift-based IDL as it is widely known and used. This is also what we proposed to use in our original KIARA proposal. It is also what all our previous work in C/C++ and Java is based on, so there is much we can leverage from there. I am very open to add another IDL. We have always argued that the exact choice of IDL does not really matter and our KIARA version is already designed to support multiple IDLs. For the IDL-derived version of the API that we are focusing on now it is very easy to implement multiple IDLs as all that needs to be done is adding a new IDL compiler that generates the necessary stubs and skeletons. The Thrift-based IDL support is already available from us and we are willing to make any necessary changes to it to support whatever design we come up with. This will require minimal efforts on our side. We are happy to contribute to another (CORBA-based) IDL should we decide to go that route. I see no reason whatsoever for switching IDL completely mid project and abandon and throw away all the existing work on the Thrift-based IDL. Such a suggestion should better come with pretty good arguments. > 2.- I send you the current and probably almost final status of our > submission for RPC over DDS standard. In this submission we made a > big effort to convince RTI and Prismtech to keep the function call > stype API as simple as possible, and you will see several > similarities with the thrift API (see 8.10.2.2.1). Thanks for the spec. I assume that you are sending this because you are suggesting that we use this API? Please clarify. If that is your suggestion, please let us know how you expect to support the scalable and extensible API that we agreed on targeting in our last call. Please see our API suggestion for an example and for the type of extension that we should be supporting in the planned next steps. We will analyze your suggestion (assuming that is what it is) and come back with comments. At first sight, there seem to be many DDS-specific aspects in this spec (no wonder). It seems useful to completely avoid such dependencies as we want to be able to support multiple transport mechanisms and protocols going forward. If this is your suggestion for an API, can you please propose how such dependencies can be removed? Please make sure that you also carefully analyze also our suggestion and provide your feedback as the basis for our discussions. > 3.- We will start the implementation from Zero. As you know we have > also Tons of code, and our own version of a Thrift-like RPC > middleware, our RPC over TCP, already on our Git hub, and ready to be > released. We are not going to use your code as a base. First, let's > design, and later perhaps we could re-use some ideas and code. As you saw, I clearly and carefully separated my API discussion from the implementation discussion. I fully agree that we are focusing on the API discussion. However, we also have to keep in mind that we not only need a working version really soon, but also need to meet the POs requirement of showing adoption by GEs within one year. So the aspect of reusing code that is available (yours or ours) must be taken into account at some point. > 4.- It is not the new API should adapt to our current developments, > but the other way around. I perfectly agree. This is why we have made clear suggestions for an API that is very close to Thrift (as well as other IDL-based APIs), actually simplifying it at some places and while allowing advanced functionality to be made available (scalability). The latter point is essential. Designing an API that cannot support the advanced functionality would need very good reasons to be acceptable. Note, that this functionality is already available. We just need ways to expose it. I see no point in simply implementing something that is already available multiple times in Java (there are (too) many RPC schemes available already, particularly in Java as you know). > 5.- About the commercial support: In order to support this new KIARA > release afterwards, we need something near to our current > specifications, or somehow compatible, and practical. The dynamic or > "application derived API", cannot be the central piece of the product > in order to make it successful. For me it is an interesting idea, and > we implemented our interpreter: > > http://www.eprosima.com/index.php/es/products-all/eprosima-dynamic-fast-buffers > > But it cannot be the main actor in our new KIARA release if we want > a big adoption. Most of the developers do not know about middleware, > and for most of them, dynamic typing is a very advanced feature. This is why we suggested a scalable API that in its base version is very close to all static RPC mechanisms but can be scaled to more advanced functionality. Please have a look at our proposal and comment on why this is not compatible or practical. I would be more than happy to discuss improvements of our proposal in whatever direction you think it would be necessary for being more compatible and practical. As an alternative, please provide suggestions as how to make your proposal scalable in the sense that we have described it. We will do the same. Talk to you later. Best, Philipp > > > Regards, > Jaime. > > > -----Original Message----- > From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] > Sent: domingo, 28 de septiembre de 2014 13:35 > To: Dmitri Rubinstein; KIARA Mailing List; Jaime Martin Losa > Subject: Re: [Miwi-middleware] KIARA/DFKI Java Design Document Revised > > Hi, > > Thanks Dmitri! We had a discussion after our call on Friday and refined out ideas about the "IDL-derived" API (see email for an explanation for using that term). Dmitri has worked out all the details and came up with a great approach: After a quick iteration, we now provide our view on the upcoming Java-API to all. > > Please have a look and provide feedback and comments! > > I believe that we have found a nice way of integrating the IDL-derived API such that it is almost identical to traditional middleware API where the API is derived from the IDL (which we called "static" before). > > Specifically, we compare our proposed API directly to Thrift and point out why it is equally simple (actually simpler), but more powerful and more scalable. > > I am really like the approach about how well it compares to traditional designs but allows for going well beyond those. We had discussed this "static" API before with Jaime in our meetings and thought that it would work out well, but this is the first time we worked through all (most?) of the details. > > There is certainly room for improvements or alternative implementations, though. We would like to hear your input as well as look at and compare this with your proposals as planned > > > Extensions: > > Scalability: By adding some new calls we can extend/scale the API to also support the application-derived API that we contributed to the core of KIARA in the original proposal. As you can see its fits nicely with the IDL-derived API, which is a good thing. > > Security: We have not included our thoughts on security yet (as > discussed) but they can be nicely integrated and then offer significantly better and fully automatic security features. We are happy to present those ideas later, when appropriate. > > Asynchronous and threads: There are a number of other extensions that we have in mind regarding threading, asynchronous calls, and object references that we have excluded. they should be easily added to what we have now. Again we are happy to discuss those, when you want. > > Finally a last aspect: This API design can be transferred to C/C++ with some small changes. the same simplicity of the base API and scalability applies there. It then avoid some of the (internal) complexity at the cost of a more static behavior. But we then offer both. > > > Best, > > Philipp > > > P.S.: Off the record (as we are only discussing API design for now): The proposed API can be implemented pretty quickly given our current Java version. In case someone wants to already evaluate that option and see if they agree or not agree on our implementation choices, feel free to look at and comment the code from Dmitri. Since it is Java and we are not (yet) doing the runtime compilation it should be nicely readable and understandable. We are very much open to suggestion to improve that code base where necessary. It is certainly not as well optimzed as the C/C++ code yet. > > Jaime: I would still be highly interested in the joint uKIARA implementation and us jointly developing this. As we discussed in Madrid, as a research institute we cannot maintain and support our KIARA the code forever. And particularly for industry customers having a commercial support option is really interesting, if not mandatory. It would be nice if we may be able find better agreement along those lines. > > With the "static" API we might now have a good basis for that, where you can offer a good basis version that you are familiar with and we can add all the fancy thing on top of that (including security) that is critical to us and that you might eventually also be interested and confident in. > Note that our Java code is already interoperable with the C/C++ version of KIARA as as well as the C# and JS versions. > > > > Am 28.09.2014 um 12:44 schrieb Dmitri Rubinstein: >> In the attachment is a revised KIARA/DFKI Java Design Document. >> Comments are as usually welcome. >> >> Best, >> >> Dmitri >> >> >> >> _______________________________________________ >> Miwi-middleware mailing list >> Miwi-middleware at lists.fi-ware.org >> https://lists.fi-ware.org/listinfo/miwi-middleware >> > > -- ------------------------------------------------------------------------- Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: From JaimeMartin at eprosima.com Tue Sep 30 08:59:03 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Tue, 30 Sep 2014 06:59:03 +0000 Subject: [Miwi-middleware] hang out link Message-ID: https://plus.google.com/hangouts/_/grgcq4jfxketqft66fyche7no4a?hl=es Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFDC8C.C9031BB0] The Middleware Experts Phone: + 34 91 804 34 48 / + 34 607 91 37 45 JaimeMartin at eProsima.com www.eProsima.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3800 bytes Desc: image001.png URL: From mach at zhaw.ch Tue Sep 30 09:01:13 2014 From: mach at zhaw.ch (Christof Marti) Date: Tue, 30 Sep 2014 09:01:13 +0200 Subject: [Miwi-middleware] KIARA/DFKI Java Design Document Revised In-Reply-To: <673c08ac6f864caca4f07babff577d9d@SRV-MAIL-001.zhaw.ch> References: <5427E693.6050000@cs.uni-saarland.de> <5427F274.9070609@dfki.de> <673c08ac6f864caca4f07babff577d9d@SRV-MAIL-001.zhaw.ch> Message-ID: <1F79965F-B092-4C84-B9B9-5FAFC0076264@zhaw.ch> Hi everybody Nice to see that there are already as detailed proposals. Our approach was to start with the user experience we would like to have. The best experience so far was the usage of Spring REST-WS, which allows a very simple definition and usage of REST-Services. Main difference is, that we also have to deal with the IDL. It comes quite close to the DFKI application derived approach. Maybe with a bit more extensive usage of Annotations instead of function calls to do the IDL-mappings. On lower levels I would propose also to look at the ServiceAdapter and Template Interfaces Spring provides for many different messaging technologies like (REST, JMS, AMQP, WebSocket, ...). We do less care about the IDL and IDL-Stubs/Skeletons generation (first incarnation). My final idea is, that this mapping is done at startup-time (using proxy-Objects, as it is done in many Java Frameworks, ...).This might not be the API for the first release but for sure the goal to approach in the final release. Attached the document describing the brief staring point and other Key-points. Best regards Christof > On 30.09.2014, at 07:27, Philipp Slusallek wrote: > > Hi, > > As a basis for our discussion this morning and as documentation, I am > summarizing our thoughts on your mail suggestion. > > Am 29.09.2014 um 17:35 schrieb Jaime Martin Losa: >> 1.- When I said something similar to Thrift, I am not proposing to >> use the Thrift IDL as you say in your document, but just the simple >> approach they use. As a matter of fact, I would prefer something >> based on the OMG IDL adding some modern types. > > First of all, the exact choice of IDL is probably not that important as > long as basic requirements are met (as listed in your document from > yesterday). Technically, they are essentially all describing the same > thing -- just with different syntax and the effect on the user is minimal. > > There are a few important requirements that we need to fulfill in order > to ensure that we have a powerful enough syntax to express QoS, > security-related, or other necessary annotations. See our IDL > specification for details. Dmitri can answer any questions in that regard. > > As you have seen we have proposed a Thrift-based IDL as it is widely > known and used. This is also what we proposed to use in our original > KIARA proposal. It is also what all our previous work in C/C++ and Java > is based on, so there is much we can leverage from there. > > I am very open to add another IDL. We have always argued that the exact > choice of IDL does not really matter and our KIARA version is already > designed to support multiple IDLs. > > For the IDL-derived version of the API that we are focusing on now it is > very easy to implement multiple IDLs as all that needs to be done is > adding a new IDL compiler that generates the necessary stubs and > skeletons. The Thrift-based IDL support is already available from us and > we are willing to make any necessary changes to it to support whatever > design we come up with. This will require minimal efforts on our side. > We are happy to contribute to another (CORBA-based) IDL should we decide > to go that route. > > I see no reason whatsoever for switching IDL completely mid project and > abandon and throw away all the existing work on the Thrift-based IDL. > Such a suggestion should better come with pretty good arguments. > > >> 2.- I send you the current and probably almost final status of our >> submission for RPC over DDS standard. In this submission we made a >> big effort to convince RTI and Prismtech to keep the function call >> stype API as simple as possible, and you will see several >> similarities with the thrift API (see 8.10.2.2.1). > > Thanks for the spec. I assume that you are sending this because you are > suggesting that we use this API? Please clarify. > > If that is your suggestion, please let us know how you expect to support > the scalable and extensible API that we agreed on targeting in our last > call. Please see our API suggestion for an example and for the type of > extension that we should be supporting in the planned next steps. > > We will analyze your suggestion (assuming that is what it is) and come > back with comments. At first sight, there seem to be many DDS-specific > aspects in this spec (no wonder). It seems useful to completely avoid > such dependencies as we want to be able to support multiple transport > mechanisms and protocols going forward. If this is your suggestion for > an API, can you please propose how such dependencies can be removed? > > Please make sure that you also carefully analyze also our suggestion and > provide your feedback as the basis for our discussions. > > >> 3.- We will start the implementation from Zero. As you know we have >> also Tons of code, and our own version of a Thrift-like RPC >> middleware, our RPC over TCP, already on our Git hub, and ready to be >> released. We are not going to use your code as a base. First, let's >> design, and later perhaps we could re-use some ideas and code. > > As you saw, I clearly and carefully separated my API discussion from the > implementation discussion. > > I fully agree that we are focusing on the API discussion. However, we > also have to keep in mind that we not only need a working version really > soon, but also need to meet the POs requirement of showing adoption by > GEs within one year. So the aspect of reusing code that is available > (yours or ours) must be taken into account at some point. > > >> 4.- It is not the new API should adapt to our current developments, >> but the other way around. > > I perfectly agree. This is why we have made clear suggestions for an API > that is very close to Thrift (as well as other IDL-based APIs), actually > simplifying it at some places and while allowing advanced functionality > to be made available (scalability). > > The latter point is essential. Designing an API that cannot support the > advanced functionality would need very good reasons to be acceptable. > > Note, that this functionality is already available. We just need ways to > expose it. I see no point in simply implementing something that is > already available multiple times in Java (there are (too) many RPC > schemes available already, particularly in Java as you know). > > >> 5.- About the commercial support: In order to support this new KIARA >> release afterwards, we need something near to our current >> specifications, or somehow compatible, and practical. The dynamic or >> "application derived API", cannot be the central piece of the product >> in order to make it successful. For me it is an interesting idea, and >> we implemented our interpreter: >> >> http://www.eprosima.com/index.php/es/products-all/eprosima-dynamic-fast-buffers >> >> But it cannot be the main actor in our new KIARA release if we want >> a big adoption. Most of the developers do not know about middleware, >> and for most of them, dynamic typing is a very advanced feature. > > This is why we suggested a scalable API that in its base version is very > close to all static RPC mechanisms but can be scaled to more advanced > functionality. > > Please have a look at our proposal and comment on why this is not > compatible or practical. > > I would be more than happy to discuss improvements of our proposal in > whatever direction you think it would be necessary for being more > compatible and practical. > > As an alternative, please provide suggestions as how to make your > proposal scalable in the sense that we have described it. We will do the > same. > > Talk to you later. > > > Best, > > Philipp > > >> >> >> Regards, >> Jaime. >> >> >> -----Original Message----- >> From: Philipp Slusallek [mailto:philipp.slusallek at dfki.de] >> Sent: domingo, 28 de septiembre de 2014 13:35 >> To: Dmitri Rubinstein; KIARA Mailing List; Jaime Martin Losa >> Subject: Re: [Miwi-middleware] KIARA/DFKI Java Design Document Revised >> >> Hi, >> >> Thanks Dmitri! We had a discussion after our call on Friday and refined out ideas about the "IDL-derived" API (see email for an explanation for using that term). Dmitri has worked out all the details and came up with a great approach: After a quick iteration, we now provide our view on the upcoming Java-API to all. >> >> Please have a look and provide feedback and comments! >> >> I believe that we have found a nice way of integrating the IDL-derived API such that it is almost identical to traditional middleware API where the API is derived from the IDL (which we called "static" before). >> >> Specifically, we compare our proposed API directly to Thrift and point out why it is equally simple (actually simpler), but more powerful and more scalable. >> >> I am really like the approach about how well it compares to traditional designs but allows for going well beyond those. We had discussed this "static" API before with Jaime in our meetings and thought that it would work out well, but this is the first time we worked through all (most?) of the details. >> >> There is certainly room for improvements or alternative implementations, though. We would like to hear your input as well as look at and compare this with your proposals as planned >> >> >> Extensions: >> >> Scalability: By adding some new calls we can extend/scale the API to also support the application-derived API that we contributed to the core of KIARA in the original proposal. As you can see its fits nicely with the IDL-derived API, which is a good thing. >> >> Security: We have not included our thoughts on security yet (as >> discussed) but they can be nicely integrated and then offer significantly better and fully automatic security features. We are happy to present those ideas later, when appropriate. >> >> Asynchronous and threads: There are a number of other extensions that we have in mind regarding threading, asynchronous calls, and object references that we have excluded. they should be easily added to what we have now. Again we are happy to discuss those, when you want. >> >> Finally a last aspect: This API design can be transferred to C/C++ with some small changes. the same simplicity of the base API and scalability applies there. It then avoid some of the (internal) complexity at the cost of a more static behavior. But we then offer both. >> >> >> Best, >> >> Philipp >> >> >> P.S.: Off the record (as we are only discussing API design for now): The proposed API can be implemented pretty quickly given our current Java version. In case someone wants to already evaluate that option and see if they agree or not agree on our implementation choices, feel free to look at and comment the code from Dmitri. Since it is Java and we are not (yet) doing the runtime compilation it should be nicely readable and understandable. We are very much open to suggestion to improve that code base where necessary. It is certainly not as well optimzed as the C/C++ code yet. >> >> Jaime: I would still be highly interested in the joint uKIARA implementation and us jointly developing this. As we discussed in Madrid, as a research institute we cannot maintain and support our KIARA the code forever. And particularly for industry customers having a commercial support option is really interesting, if not mandatory. It would be nice if we may be able find better agreement along those lines. >> >> With the "static" API we might now have a good basis for that, where you can offer a good basis version that you are familiar with and we can add all the fancy thing on top of that (including security) that is critical to us and that you might eventually also be interested and confident in. >> Note that our Java code is already interoperable with the C/C++ version of KIARA as as well as the C# and JS versions. >> >> >> >> Am 28.09.2014 um 12:44 schrieb Dmitri Rubinstein: >>> In the attachment is a revised KIARA/DFKI Java Design Document. >>> Comments are as usually welcome. >>> >>> Best, >>> >>> Dmitri >>> >>> >>> >>> _______________________________________________ >>> Miwi-middleware mailing list >>> Miwi-middleware at lists.fi-ware.org >>> https://lists.fi-ware.org/listinfo/miwi-middleware >>> >> >> > > > -- > > ------------------------------------------------------------------------- > Deutsches Forschungszentrum f?r K?nstliche Intelligenz (DFKI) GmbH > Trippstadter Strasse 122, D-67663 Kaiserslautern > > Gesch?ftsf?hrung: > Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) > Dr. Walter Olthoff > Vorsitzender des Aufsichtsrats: > Prof. Dr. h.c. Hans A. Aukes > > Sitz der Gesellschaft: Kaiserslautern (HRB 2313) > USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 > --------------------------------------------------------------------------- > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: JavaAPI-basicIdeas_mach.txt URL: From JaimeMartin at eprosima.com Tue Sep 30 10:04:27 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Tue, 30 Sep 2014 08:04:27 +0000 Subject: [Miwi-middleware] New KIARA RFP Meeting Message-ID: <43ecaca7040c4cafa868ccea7cea45dc@AMSPR06MB344.eurprd06.prod.outlook.com> Actions: - Send Wednesday a code example of how the proxies and skeletons could look - Send Friday the non-very formal submissions, to be discussed next week to compose a joint submission. Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFDC95.EBB92150] The Middleware Experts Phone: + 34 91 804 34 48 / + 34 607 91 37 45 JaimeMartin at eProsima.com www.eProsima.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3800 bytes Desc: image001.png URL: