From RicardoGonzalez at eprosima.com Wed Oct 1 11:31:52 2014 From: RicardoGonzalez at eprosima.com (Ricardo Gonzalez Moreno) Date: Wed, 1 Oct 2014 09:31:52 +0000 Subject: [Miwi-middleware] KIARA example for Java Message-ID: <1412155911.4677.8.camel@ricardodesktop> Hi all, As it was proposed, yesterday I wrote an example. It is fully functional and contains a client and a server that implement the following IDL: service Calculator { long add(long param1, long param2); long subtract(long param1, long param2); }; This example shows a possible future API, although the naming is not final. I tried to make it simple and user-friendly. This API is very easy to implement, and I developed a complete working example within one day. To develop a client application, the user should select the network transport and the serialization mechanism. Then he has to create the proxy to connect to the remote service. // Create custom transport, serializer and the proxy. ProxyTransport transport = new TCPProxyTransport("127.0.0.1",8080); Serializer ser = new Cdr(); CalculatorProxy proxy= new CalculatorProxy(ser, transport); After these steps, he can call the remote methods. // Call 'add' method. ret = proxy.add(param1, param2); To develop a server application, the user should select the network transport and the serialization mechanism. Then he has to invoke a server instance. ServerTransport transport = new TCPServerTransport(8080); Serializer serializer = new Cdr(); Server server = new Server(serializer, transport); After these steps, he can add his servants and run the server. Servant servant = new CalculatorServantExample(); server.addService(servant); server.serve(); This source code the user has to write is located in the directory 'user_src'. Also this example contains source code that should be generated by a IDL compiler. It is located in the folder 'gen_src'. The KIARA core source code is located in 'kiara_src'. You can see the code is pretty straightforward and just 20-30 lines of generated code do all the necessary tasks. This example can be compiled using 'ant', although I already provide the bytecode. The archive contains two bash script to execute the client (clientexample.sh) and the server (serverexample.sh) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kiara_java.tar.gz Type: application/x-compressed-tar Size: 18487 bytes Desc: kiara_java.tar.gz URL: From rubinstein at cs.uni-saarland.de Wed Oct 1 14:13:21 2014 From: rubinstein at cs.uni-saarland.de (Dmitri Rubinstein) Date: Wed, 01 Oct 2014 14:13:21 +0200 Subject: [Miwi-middleware] KIARA example for Java In-Reply-To: <1412155911.4677.8.camel@ricardodesktop> References: <1412155911.4677.8.camel@ricardodesktop> Message-ID: <542BEFE1.70002@cs.uni-saarland.de> Hi, I modified your code to show the DFKI approach. Currently it is just for the client, quick and dirty. Our application example is pretty like yours just we start with this (see ClientExampleDFKI.java): Context context = Kiara.createContext(); Connection connection = context.openConnection("tcp://127.0.0.1:8080"); Calculator proxy = connection.getServiceInterface(Calculator.class); The magic is in getServiceInterface: public T getServiceInterface(Class interfaceClass) throws Exception { String proxyClassName = interfaceClass.getName()+"Proxy"; Class proxyClass = Class.forName(proxyClassName); if (!interfaceClass.isAssignableFrom(proxyClass)) throw new RuntimeException("Proxy class "+proxyClass+" does not implement interface "+interfaceClass); Constructor proxyConstr = proxyClass.getConstructor(Serializer.class, ProxyTransport.class); proxyConstr.setAccessible(true); return interfaceClass.cast(proxyConstr.newInstance(serializer, transport)); } So mostly our API is just a higher abstraction level. Since I am not familiar with Ant and Eclipse is not automatically imports it I recreated project with Maven. Maven is also the de facto standard for Java and is directly supported by main IDEs (Eclipse, NetBeans, IntelliJ). You need to install Maven and then run "mvn install" in kiara_java_mod directory to build everything. "mvn clean" will do a cleanup. Archive also includes Eclipse project and .git repository so you can track my changes. Shell scripts for running example are included as well. Best, Dmitri On 10/01/14 11:31, Ricardo Gonzalez Moreno wrote: > Hi all, > > As it was proposed, yesterday I wrote an example. It is fully functional > and contains a client and a server that implement the following IDL: > > *service* Calculator > { > long add(long param1, long param2); > > long subtract(long param1, long param2); > }; > > > This example shows a possible future API, although the naming is not > final. I tried to make it simple and user-friendly. This API is very > easy to implement, and I developed a complete working example within one > day. > > To develop a client application, the user should select the network > transport and the serialization mechanism. Then he has to create the > proxy to connect to the remote service. > > /// Create custom transport, serializer and the proxy./ > ProxyTransport transport = *new *TCPProxyTransport("127.0.0.1",8080); > Serializer ser = *new *Cdr(); > CalculatorProxy *proxy*= *new *CalculatorProxy(ser, transport); > > > After these steps, he can call the remote methods. > > > /// Call 'add' method./ > ret = *proxy*.add(param1, param2); > > > To develop a server application, the user should select the network > transport and the serialization mechanism. Then he has to invoke a > server instance. > > ServerTransport transport = *new* TCPServerTransport(8080); > Serializer serializer = *new* Cdr(); > Server server = *new* Server(serializer, transport); > > > After these steps, he can add his servants and run the server. > > Servant *servant* = *new* CalculatorServantExample(); > server.addService(*servant*); > server.serve(); > > > This source code the user has to write is located in the directory > 'user_src'. > Also this example contains source code that should be generated by a IDL > compiler. It is located in the folder 'gen_src'. The KIARA core source > code is located in 'kiara_src'. You can see the code is pretty > straightforward and just 20-30 lines of generated code do all the > necessary tasks. > > This example can be compiled using 'ant', although I already provide the > bytecode. The archive contains two bash script to execute the client > (clientexample.sh) and the server (serverexample.sh) > > > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > -------------- next part -------------- A non-text attachment was scrubbed... Name: kiara_java_mod_2014-10-01.tar.gz Type: application/gzip Size: 49522 bytes Desc: not available URL: From rubinstein at cs.uni-saarland.de Wed Oct 1 17:01:45 2014 From: rubinstein at cs.uni-saarland.de (Dmitri Rubinstein) Date: Wed, 01 Oct 2014 17:01:45 +0200 Subject: [Miwi-middleware] KIARA example for Java In-Reply-To: <542BEFE1.70002@cs.uni-saarland.de> References: <1412155911.4677.8.camel@ricardodesktop> <542BEFE1.70002@cs.uni-saarland.de> Message-ID: <542C1759.304@cs.uni-saarland.de> Hi, I extended again the example with the DFKI Server API design (see ServerExampleDFKI.java): Context context = Kiara.createContext(); Service service = context.newService(); Servant servant = new CalculatorServantExample(); service.register(servant); // Create server without negotiation Server server = context.newServer(); // Add service waiting on TCP with CDR serialization server.addService("tcp://0.0.0.0:8080", "cdr", service); server.addService("tcp://0.0.0.0:9090", "cdr", service); server.run(); The only difference to our proposal (v0.3) is that context provides newServer() method without arguments. Server created in such a way will run no negotiation service waiting on http, thus negotiation is disabled and you need to know on which host and port which protocol/transport combination is running. Also in my example I run the same service on two ports simultaneously. Best, Dmitri On 10/01/14 14:13, Dmitri Rubinstein wrote: > Hi, > > I modified your code to show the DFKI approach. Currently it is just for > the client, quick and dirty. Our application example is pretty like > yours just we start with this (see ClientExampleDFKI.java): > > Context context = Kiara.createContext(); > Connection connection = context.openConnection("tcp://127.0.0.1:8080"); > Calculator proxy = connection.getServiceInterface(Calculator.class); > > The magic is in getServiceInterface: > > public T getServiceInterface(Class interfaceClass) throws > Exception { > String proxyClassName = interfaceClass.getName()+"Proxy"; > Class proxyClass = Class.forName(proxyClassName); > if (!interfaceClass.isAssignableFrom(proxyClass)) > throw new RuntimeException("Proxy class "+proxyClass+" does not > implement interface "+interfaceClass); > Constructor proxyConstr = > proxyClass.getConstructor(Serializer.class, ProxyTransport.class); > proxyConstr.setAccessible(true); > return interfaceClass.cast(proxyConstr.newInstance(serializer, > transport)); > } > > So mostly our API is just a higher abstraction level. > > Since I am not familiar with Ant and Eclipse is not automatically > imports it I recreated project with Maven. Maven is also the de facto > standard for Java and is directly supported by main IDEs (Eclipse, > NetBeans, IntelliJ). You need to install Maven and then run "mvn > install" in kiara_java_mod directory to build everything. "mvn clean" > will do a cleanup. Archive also includes Eclipse project and .git > repository so you can track my changes. Shell scripts for running > example are included as well. > > Best, > > Dmitri > > On 10/01/14 11:31, Ricardo Gonzalez Moreno wrote: >> Hi all, >> >> As it was proposed, yesterday I wrote an example. It is fully functional >> and contains a client and a server that implement the following IDL: >> >> *service* Calculator >> { >> long add(long param1, long param2); >> >> long subtract(long param1, long param2); >> }; >> >> >> This example shows a possible future API, although the naming is not >> final. I tried to make it simple and user-friendly. This API is very >> easy to implement, and I developed a complete working example within one >> day. >> >> To develop a client application, the user should select the network >> transport and the serialization mechanism. Then he has to create the >> proxy to connect to the remote service. >> >> /// Create custom transport, serializer and the proxy./ >> ProxyTransport transport = *new *TCPProxyTransport("127.0.0.1",8080); >> Serializer ser = *new *Cdr(); >> CalculatorProxy *proxy*= *new *CalculatorProxy(ser, transport); >> >> >> After these steps, he can call the remote methods. >> >> >> /// Call 'add' method./ >> ret = *proxy*.add(param1, param2); >> >> >> To develop a server application, the user should select the network >> transport and the serialization mechanism. Then he has to invoke a >> server instance. >> >> ServerTransport transport = *new* TCPServerTransport(8080); >> Serializer serializer = *new* Cdr(); >> Server server = *new* Server(serializer, transport); >> >> >> After these steps, he can add his servants and run the server. >> >> Servant *servant* = *new* CalculatorServantExample(); >> server.addService(*servant*); >> server.serve(); >> >> >> This source code the user has to write is located in the directory >> 'user_src'. >> Also this example contains source code that should be generated by a IDL >> compiler. It is located in the folder 'gen_src'. The KIARA core source >> code is located in 'kiara_src'. You can see the code is pretty >> straightforward and just 20-30 lines of generated code do all the >> necessary tasks. >> >> This example can be compiled using 'ant', although I already provide the >> bytecode. The archive contains two bash script to execute the client >> (clientexample.sh) and the server (serverexample.sh) >> >> >> _______________________________________________ >> Miwi-middleware mailing list >> Miwi-middleware at lists.fi-ware.org >> https://lists.fi-ware.org/listinfo/miwi-middleware >> > > > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > -------------- next part -------------- A non-text attachment was scrubbed... Name: kiara_java_mod_2014-10-01.tar.gz Type: application/gzip Size: 57391 bytes Desc: not available URL: From JaimeMartin at eprosima.com Fri Oct 3 12:59:50 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Fri, 3 Oct 2014 10:59:50 +0000 Subject: [Miwi-middleware] Submissions please. Meeting Monday at 9.00 Message-ID: <6f6b754b96264c97bbf2336b26bea731@AMSPR06MB344.eurprd06.prod.outlook.com> HI everyone, I am going to let you work during the weekend to complete the submissions you own me. We will send our submission in a few minutes. Discussion and voting next Monday. Not KIARA meeting today. Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFDF09.6C930D70] 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 RicardoGonzalez at eprosima.com Fri Oct 3 13:16:21 2014 From: RicardoGonzalez at eprosima.com (Ricardo Gonzalez Moreno) Date: Fri, 3 Oct 2014 11:16:21 +0000 Subject: [Miwi-middleware] Submissions please. Meeting Monday at 9.00 In-Reply-To: <6f6b754b96264c97bbf2336b26bea731@AMSPR06MB344.eurprd06.prod.outlook.com> References: <6f6b754b96264c97bbf2336b26bea731@AMSPR06MB344.eurprd06.prod.outlook.com> Message-ID: <1412334980.23228.2.camel@ricardodesktop> Hi all, I've attached the eProsima initial submission. Best regards, Ricardo El vie, 03-10-2014 a las 10:59 +0000, Jaime Martin Losa escribi?: > HI everyone, I am going to let you work during the > weekend to complete the submissions you own me. > > > > We will send our submission in a few minutes. > > > > Discussion and voting next Monday. > > > > Not KIARA meeting today. > > > > Regards, > > Jaime Martin Losa > > CEO > > Twitter:@JaimeMartinLosa > > > > > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: KIARA RPC - eProsima Initial Submission_v0.1.0.odt Type: application/vnd.oasis.opendocument.text Size: 36474 bytes Desc: KIARA RPC - eProsima Initial Submission_v0.1.0.odt URL: From rubinstein at cs.uni-saarland.de Fri Oct 3 13:44:41 2014 From: rubinstein at cs.uni-saarland.de (Dmitri Rubinstein) Date: Fri, 03 Oct 2014 13:44:41 +0200 Subject: [Miwi-middleware] Submissions please. Meeting Monday at 9.00 In-Reply-To: <1412334980.23228.2.camel@ricardodesktop> References: <6f6b754b96264c97bbf2336b26bea731@AMSPR06MB344.eurprd06.prod.outlook.com> <1412334980.23228.2.camel@ricardodesktop> Message-ID: <542E8C29.80106@cs.uni-saarland.de> I am on vacation on next Monday (6.10.) and not available for the meeting. Best, Dmitri On 10/03/14 13:16, Ricardo Gonzalez Moreno wrote: > Hi all, > > I've attached the eProsima initial submission. > > Best regards, > Ricardo > > > El vie, 03-10-2014 a las 10:59 +0000, Jaime Martin Losa escribi?: >> HI everyone, I am going to let you work during the >> weekend to complete the submissions you own me. >> >> >> >> We will send our submission in a few minutes. >> >> >> >> Discussion and voting next Monday. >> >> >> >> Not KIARA meeting today. >> >> >> >> Regards, >> >> Jaime Martin Losa >> >> CEO >> >> Twitter:@JaimeMartinLosa >> >> >> >> >> 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 > > > > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > From JaimeMartin at eprosima.com Fri Oct 3 13:49:07 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Fri, 3 Oct 2014 11:49:07 +0000 Subject: [Miwi-middleware] Submissions please. Meeting Monday at 9.00 In-Reply-To: <542E8C29.80106@cs.uni-saarland.de> References: <6f6b754b96264c97bbf2336b26bea731@AMSPR06MB344.eurprd06.prod.outlook.com> <1412334980.23228.2.camel@ricardodesktop> <542E8C29.80106@cs.uni-saarland.de> Message-ID: Please send us your submission. I guess Philipp can substitute you. Regards, Jaime. -----Original Message----- From: Dmitri Rubinstein [mailto:rubinstein at cs.uni-saarland.de] Sent: viernes, 03 de octubre de 2014 13:45 To: Ricardo Gonzalez Moreno; Jaime Martin Losa Cc: miwi-middleware at lists.fi-ware.eu Subject: Re: [Miwi-middleware] Submissions please. Meeting Monday at 9.00 I am on vacation on next Monday (6.10.) and not available for the meeting. Best, Dmitri On 10/03/14 13:16, Ricardo Gonzalez Moreno wrote: > Hi all, > > I've attached the eProsima initial submission. > > Best regards, > Ricardo > > > El vie, 03-10-2014 a las 10:59 +0000, Jaime Martin Losa escribi?: >> HI everyone, I am going to let you work during the >> weekend to complete the submissions you own me. >> >> >> >> We will send our submission in a few minutes. >> >> >> >> Discussion and voting next Monday. >> >> >> >> Not KIARA meeting today. >> >> >> >> Regards, >> >> Jaime Martin Losa >> >> CEO >> >> Twitter:@JaimeMartinLosa >> >> >> >> >> 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 > > > > _______________________________________________ > 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 Fri Oct 3 20:23:01 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Fri, 03 Oct 2014 20:23:01 +0200 Subject: [Miwi-middleware] Submissions please. Meeting Monday at 9.00 In-Reply-To: References: <6f6b754b96264c97bbf2336b26bea731@AMSPR06MB344.eurprd06.prod.outlook.com> <1412334980.23228.2.camel@ricardodesktop> <542E8C29.80106@cs.uni-saarland.de> Message-ID: <542EE985.7000207@dfki.de> Hi, I am not aware of a meeting on Monday. I will be at an EU review meeting in Brussels on Monday and will not be able to join a meeting. We will provide comment on the ePros proposal by email. Sorry, Philipp Am 03.10.2014 um 13:49 schrieb Jaime Martin Losa: > Please send us your submission. > > I guess Philipp can substitute you. > > Regards, > Jaime. > > > -----Original Message----- > From: Dmitri Rubinstein [mailto:rubinstein at cs.uni-saarland.de] > Sent: viernes, 03 de octubre de 2014 13:45 > To: Ricardo Gonzalez Moreno; Jaime Martin Losa > Cc: miwi-middleware at lists.fi-ware.eu > Subject: Re: [Miwi-middleware] Submissions please. Meeting Monday at 9.00 > > I am on vacation on next Monday (6.10.) and not available for the meeting. > > Best, > > Dmitri > > On 10/03/14 13:16, Ricardo Gonzalez Moreno wrote: >> Hi all, >> >> I've attached the eProsima initial submission. >> >> Best regards, >> Ricardo >> >> >> El vie, 03-10-2014 a las 10:59 +0000, Jaime Martin Losa escribi?: >>> HI everyone, I am going to let you work during the >>> weekend to complete the submissions you own me. >>> >>> >>> >>> We will send our submission in a few minutes. >>> >>> >>> >>> Discussion and voting next Monday. >>> >>> >>> >>> Not KIARA meeting today. >>> >>> >>> >>> Regards, >>> >>> Jaime Martin Losa >>> >>> CEO >>> >>> Twitter:@JaimeMartinLosa >>> >>> >>> >>> >>> 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 >> >> >> >> _______________________________________________ >> 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 Fri Oct 3 20:37:15 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Fri, 03 Oct 2014 20:37:15 +0200 Subject: [Miwi-middleware] Submissions please. Meeting Monday at 9.00 In-Reply-To: <1412334980.23228.2.camel@ricardodesktop> References: <6f6b754b96264c97bbf2336b26bea731@AMSPR06MB344.eurprd06.prod.outlook.com> <1412334980.23228.2.camel@ricardodesktop> Message-ID: <542EECDB.8040101@dfki.de> Hi, I had a quick look (here in a meeting in the US). One thing that is not clear to me is the motivation for why you suggest to do thing the way you propose to do them. Would it be possible that you provide some more information about that (e.g. similar to the discussion we provided)? Best, Philipp Am 03.10.2014 um 13:16 schrieb Ricardo Gonzalez Moreno: > Hi all, > > I've attached the eProsima initial submission. > > Best regards, > Ricardo > > > El vie, 03-10-2014 a las 10:59 +0000, Jaime Martin Losa escribi??: >> HI everyone, I am going to let you work during the >> weekend to complete the submissions you own me. >> >> >> >> We will send our submission in a few minutes. >> >> >> >> Discussion and voting next Monday. >> >> >> >> Not KIARA meeting today. >> >> >> >> Regards, >> >> Jaime Martin Losa >> >> CEO >> >> Twitter:@JaimeMartinLosa >> >> >> >> >> 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 > > > > _______________________________________________ > 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 rubinstein at cs.uni-saarland.de Sun Oct 5 00:00:20 2014 From: rubinstein at cs.uni-saarland.de (Dmitri Rubinstein) Date: Sun, 05 Oct 2014 00:00:20 +0200 Subject: [Miwi-middleware] Submissions please. Meeting Monday at 9.00 In-Reply-To: <1412334980.23228.2.camel@ricardodesktop> References: <6f6b754b96264c97bbf2336b26bea731@AMSPR06MB344.eurprd06.prod.outlook.com> <1412334980.23228.2.camel@ricardodesktop> Message-ID: <54306DF4.1010708@cs.uni-saarland.de> Here are my comments and questions to your proposal: 1. IDL is a hybrid of OMG IDL and Thrift as you explain, however I miss an explanation why you added some features and removed others. Also besides the grammar, some examples of added/removed features would be very helpful. a) I found no syntax for annotations in your grammar, but we need them for security. We need annotations for services, service operations, return types and operation arguments. b) Why do we need separate types wstring and string like in CORBA, Thrift just use string. c) Do we need strings with limited length () ? d) Why do you prefer CORBA's notation for integers (long, short, unsigned long, etc.) to Thrift's (i32, i16, u32, etc.). Thrift's syntax directly tells you the minimal number of bits that you require to represent the value. f) You propose data types list and arrays id[n][m]... (). Is the difference in the mapping to Java ? Why do we need two different syntax styles, why not array and array instead ? 2. API First, I need to say that we have a similar two layer API in our KIARA/DFKI Java implementation: Transport - factory that produces TransportConnection and TransportAddress instances TransportConnection - a single connection between client and server. TransportAddress - abstract address identifying TransportConnection, Transport can construct TransportAddress from URI. ProtocolRegistry - factory that provides registration of Protocol classes, and construction of Protocol instances. Protocol - provides construction of Message instances for requests and responses from data (ByteBuffer). However, we use this API only internally. Of course we can provide RPC functionality like you suggest by making these two layers public. But then when we provide a new functionality like negotation or new protocols or serializers user of our library will need to take care of correct construction and initialization of all the required components (negotation layer, transport, serialization, etc). For example when we provide a new protocol, user will need to modify code of his application (client and server) in order to use it. Likely he will try to overcome this scalability limitation by writing a lot of boilerplate code for configuration, and finally will move his code into a separate library with a simpler API on top of ours. What we propose is to avoid "boilerplate" code. In our opinion user should not take care about how exactly connection is created, which transport and serialization is used but instead he should just tell 'connect me to endpoint with the specified URI' and our library should do the rest. And finally when the API is working nearly exactly like the one Thrift already provides, why not to just use Thrift and extend it ? Best, Dmitri On 10/03/14 13:16, Ricardo Gonzalez Moreno wrote: > Hi all, > > I've attached the eProsima initial submission. > > Best regards, > Ricardo > > > El vie, 03-10-2014 a las 10:59 +0000, Jaime Martin Losa escribi?: >> HI everyone, I am going to let you work during the >> weekend to complete the submissions you own me. >> >> >> >> We will send our submission in a few minutes. >> >> >> >> Discussion and voting next Monday. >> >> >> >> Not KIARA meeting today. >> >> >> >> Regards, >> >> Jaime Martin Losa >> >> CEO >> >> Twitter:@JaimeMartinLosa >> >> >> >> >> 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 > > > > _______________________________________________ > Miwi-middleware mailing list > Miwi-middleware at lists.fi-ware.org > https://lists.fi-ware.org/listinfo/miwi-middleware > From JaimeMartin at eprosima.com Mon Oct 6 09:05:02 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Mon, 6 Oct 2014 07:05:02 +0000 Subject: [Miwi-middleware] New date for the meeting: Tomorrow, Tuesday at 9.00 Message-ID: <603284f90fcf4ee7a803cb190af20d7b@AMSPR06MB344.eurprd06.prod.outlook.com> Hi guys, Given DFKI cannot attend, we postpone the meeting until tomorrow. In the meantime: 1.- Christof is going to send his proposal (almost finished right now) 2.- We will answer the Dmitri's questions. Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFE144.9C3309D0] 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 Tue Oct 7 07:22:37 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Tue, 7 Oct 2014 05:22:37 +0000 Subject: [Miwi-middleware] KIARA Meeting: 9:30 - 11:00 Message-ID: Hi guys, I need to start at 9:30. I will send you the hang out link a few minutes before. Regards, Jaime Martin Losa Director T?cnico [cid:image001.png at 01CDF898.FD97E4C0] The Middleware Experts Tel: + 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 Tue Oct 7 08:26:09 2014 From: philipp.slusallek at dfki.de (Philipp Slusallek) Date: Tue, 07 Oct 2014 08:26:09 +0200 Subject: [Miwi-middleware] New date for the meeting: Tomorrow, Tuesday at 9.00 In-Reply-To: <603284f90fcf4ee7a803cb190af20d7b@AMSPR06MB344.eurprd06.prod.outlook.com> References: <603284f90fcf4ee7a803cb190af20d7b@AMSPR06MB344.eurprd06.prod.outlook.com> Message-ID: <54338781.5010909@dfki.de> Hi, Unfortunately, I am booked also today, but cannot change this given the short notice. Dmitri will be at the meeting, though. I am a bit surprised that we did not get any feedback to our proposals and also no rational for the one from ePros. It is a bit difficult to discuss the different proposals, if key information about their design are not known and we do not get any information or discussion going about the specific merits of each one of them. This delays the selection of the new API, which I understood should be done quickly. I suggest we move to a more agile discussion. We could already have done most of that by email with everyone's participation, instead of trying to do this in telcos where participation is more difficult. Can I at least ask for a detailed documentation of the answers and feedback that will hopefully be provided today. We need to thoroughly document them anyway, as this is a key input for the reviewer who is supposed to look at this (to we have more info on that by now, yet?). Let me give you my (preliminary) feedback on the current state of the proposals: -- IDL: I fail to see the benefits of the new mixed IDL. It has mainly the same features of Thrift, which is widely used. Making it incompatible without a major benefit seems not a good idea. So I would argue for using the basic Thrift IDL to remain compatible with other uses and only add features where this may be required for new functionality. -- API: Again I fail to see the advantage of the app managing the communication setup. This is exactly the type of detail that an application should not be concerned with. All it should deal with is a "reference" or "name" of a service, which may encode also its location for the most simple cases as discussed here. When the app manages this aspect, all the details of the network setup are encoded in the app and its is hard to update and improve the middleware without rewriting the app. Furthermore, the suggested API is not scalable as we have discussed and I see no option for including security or the app-derived extension into it without conceptually changing how the app interacts with the middleware. As there are other options available, which even simplify the API with respect to the connection setup, I see so reason, why we should go in that direction. Not rational has been provided for that either. The proposed API is functionally almost identical to the one of Thrift but just different. I do not see a reason to do that either, if (for whatever reason) one wants to do a non-scalable API at all. I will be happy to comment on Christof's proposal as soon as I get a chance to see it. Best, Philipp Am 06.10.2014 um 09:05 schrieb Jaime Martin Losa: > Hi guys, > > Given DFKI cannot attend, we postpone the meeting until tomorrow. In the meantime: > > 1.- Christof is going to send his proposal (almost finished right now) > 2.- We will answer the Dmitri's questions. > > Regards, > Jaime Martin Losa > CEO > Twitter: @JaimeMartinLosa > > [cid:image001.png at 01CFE144.9C3309D0] > 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 Tue Oct 7 09:31:18 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Tue, 7 Oct 2014 07:31:18 +0000 Subject: [Miwi-middleware] We start in 5 minutes Message-ID: Here is the link. https://plus.google.com/hangouts/_/gxzev6oefvau7zhldadbjupssma I need 5 minutes more. Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFE211.73148600] 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 Tue Oct 7 10:32:37 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Tue, 7 Oct 2014 08:32:37 +0000 Subject: [Miwi-middleware] KIARA Submission Meetings Notes Message-ID: <9f301a980b2d4b0d86180531cdae1868@AMSPR06MB344.eurprd06.prod.outlook.com> Notes: IDL AP eProsima: IDL: Make an improved version for today, adding annotations, and making more "modern" Consider to make a modification to the basic types to be called int8, int16, int32, etc API Tranport: URL vs Classes to instantiate specific transports: Make a proposal for both Consider to hide this layer. Serialization: Consider to hide this layer. Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFE217.BE30AD20] 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 Tue Oct 7 10:33:43 2014 From: JaimeMartin at eprosima.com (Jaime Martin Losa) Date: Tue, 7 Oct 2014 08:33:43 +0000 Subject: [Miwi-middleware] KIARA Submission Meeting: Friday 14:00-15:00 Message-ID: I will send you an appointment later. Regards, Jaime Martin Losa CEO Twitter: @JaimeMartinLosa [cid:image001.png at 01CFE21A.2C0B5140] 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 rubinstein at cs.uni-saarland.de Tue Oct 7 15:08:16 2014 From: rubinstein at cs.uni-saarland.de (Dmitri Rubinstein) Date: Tue, 07 Oct 2014 15:08:16 +0200 Subject: [Miwi-middleware] KIARA/DFKI Internal API Design Message-ID: <5433E5C0.3000606@cs.uni-saarland.de> Hi, I just finished the first version of our internal API description that I developed. Please note that we don't want this to be an official public KIARA API. Possibly it can be used as a KIARA plugin API, but I expect more modifications in future. All of this is work in progress and change from day to day when new features are added. It is possible that my description is not fully clear, so please comment and ask about details. Best, Dmitri -------------- next part -------------- KIARA DFKI Internal API Design ------------------------------ In this document we explain internal design and implementation of the current KIARA/DFKI Java version available on https://github.com/dmrub/kiara-java. 1. Overall design The basic idea behind the internal API is that given a communication channel (e.g. TCP socket) both endpoints send and receive messages. The message can be seen as an universal data unit that can represent an RPC request, response, notification, etc. 2. Transport The transport layer works on top of the communication channel and takes care of splitting input data stream(s) into transport messages, and also to send transport messages via output data stream(s). Design was based on following decisions: * Transport layer is independent of other layers, we have no dependencies on serialization and dispatching layers of the framework. * We keeping all information provided by the implementation of the transport layer, since it can be required by the serialization and dispatching layers. * API is fully asynchronous * Convenience for the end-user (developer) is not a goal, since API is internal Transport layer API consists of following classes: TransportMessage - represents message and all the information that is provided by the transport layer. (source: http://goo.gl/bk0ohV) Transport - factory that produces TransportConnection and TransportAddress instances. (source: http://goo.gl/p7SF2m) TransportConnection - represents single communication channel between client and server (e.g. opened TCP socket), is used to send and receive transport messages. (source: http://goo.gl/Y0NlWK) TransportAddress - represents abstract address identifying TransportConnection, Transport constructs TransportAddress instances from URI. (source: http://goo.gl/jcRvTR) TransportRegistry - allow to register Transport instances with the transport name. (e.g. HttpTransport with "http" and "https"). (source: http://goo.gl/jFIfL7) Transport layer can also be seen as a higher level abstraction of a (not necessarily network-based) communication library, that allow to exchange messages containing payload (ByteBuffer) and related metadata. The current design is actually dictated by the features of the HTTP protocol, not TCP. In HTTP a single request message contains following information: Request line, such as GET /logo.gif HTTP/1.1 or Status line, such as HTTP/1.1 200 OK Headers Optional HTTP message body data For further processing and dispatch we need to keep and make available all this information. We map HTTP body data to the payload of the TransportMessage and represent it by the ByteBuffer. Everything else is stored as the metadata in a String to Object mapping. The mapping has a number of predefined keys with the fixed interpretation: session-id - ID of the current communication session, required for security content-type - Mime Type of the payload data encoding request-uri - URI used in HTTP request, or similar transport protocol http-method - HTTP method used in HTTP request, or similar transport protocol More keys can be easily defined later without changing the API. Additionally to the abstract representation of the transport connection and message we also provide abstract representation of the transport address. We need this for the advanced message dispatch, because in protocols like HTTP dispatch of the request is not based only on the combination of host and port. For example assume we provide KIARA services via HTTP server. The same host and port combination can be shared between multiple services (e.g. static HTML pages, files, etc.). In order to figure out if we should handle the request we need to check additionally the request path. Since transport layer is not taking care of the dispatch we need to provide an abstract API that allow to match requests. The idea is that URI's can have patterns (e.g. glob patterns with '*' and '?' letters) so we can register services not just for a specific path but also for a pattern. For example: String patternUri = "http://localhost:8080/*/bar"; String addrUri1 = "http://localhost:8080/foo/bar"; String addrUri2 = "http://localhost:8080/moo/tar"; Kiara.init(); TransportAddress patternAddr = TransportRegistry.createTransportAddressFromURI(patternUri); TransportAddress addr = TransportRegistry.createTransportAddressFromURI(addrUri1); boolean result = patternAddr.acceptConnection(addr); System.out.println(result); // Will output true addr = TransportRegistry.createTransportAddressFromURI(addrUri2); result = patternAddr.acceptConnection(addr); System.out.println(result); // Will output false The transport API is fully self-contained, so it can be used directly without the rest of the KIARA API. Here are examples of the client and server: http://goo.gl/1cNbo1, http://goo.gl/Z7sRcC. It is built on top of the Netty library (http://netty.io/), but it is 100% wrapper in order to be able to change internal implementation easily. Currently TCP and HTTP transport protocols are supported. The only limitation of this API is that without modification it can only support a transport protocol where data stream can be split into single messages. For example our TCP protocol sends a 32-bit unsigned integer specifying payload length at the start of every message. 3. Protocol Protocol layer is responsible for deserializing TransportMessage-s into request and response messages and vice versa. Protocol layer API consists of following classes: Message - represents a deserialized message that can be either serialized into TransportMessage or dispatched. Message contains its kind (REQUEST, RESPONSE or EXCEPTION), RPC method name, RPC call arguments or RPC call result. (source: http://goo.gl/1WUeQW) Protocol - provides construction of Message instances for requests and responses from TransportMessage payload (ByteBuffer). (source: http://goo.gl/ViC5ek) ProtocolRegistry - factory that provides registration of Protocol classes, and construction of Protocol instances. (source: http://goo.gl/YMx2rv) Important here is a difference between TransportMessage and Message. They represent usually the same message but on different abstraction levels. TransportMessage instance contains just data, but no interpretation (request, exception or response). Message instance represents an RPC message and allows to get or set arguments and a result. Additionally Message implementations (e.g. JsonRpcMessage, source: http://goo.gl/mh2fQP) store data that are specific to the protocol. In the case of JSON-RPC we need to store message ID required for the dispatch. Note that in our current implementation there is no serialization API, because we use external libraries (jackson for JSON-RPC: https://github.com/FasterXML/jackson, Java Serialization for JavaObjectSerialization format). Also depending on the protocol serialization encoding can be too different, so even multiple APIs are possible. Instead Message class currently require that user pass type information about Java class that should be deserialized, and serializer implementation takes care of correct conversion. 4. Dispatching Most of the server-side dispatch mechanism is implemented in ServerConnectionHandler.java (source: http://goo.gl/vMwqCr) and ServiceHandler.java (source: http://goo.gl/HTOIXp). 1) ServerConnectionHandler.onRequest is called each time when new incoming TransportMessage arrives. We prepare TransportMessage instance for a response. 2) First we check if the request is a part of negotiation protocol, and then we return JSON-encoded configuration document. 3) When request is not processed yet we search for the service (ServiceHandler instance) accepting requests on the transport address of the transport message. (Note: this part of the code is work in progress, ServerConnectionHandler will store later all ServiceHandlers that accept requests on the opened connection). 4) When ServiceHandler.performCall() is executed it converts TransportMessage to a Message by using internal Protocol instance. Then bound Java method is invoked, result or exception of its execution is serialized into a response Message and then into a TransportMessage. The client-side dispatch mechanism is implemented in the DefaultInvocationHandler class (source: http://goo.gl/bOzLzB). Client side dispatch is required because we can send and receive messages asynchronously. Because of this the order in which responses arrive is not specified. We solve this problem by having a list of handlers (that we call Pipeline) for pending responses. When we perform a call we add a handler to the pipeline and invoke asynchronous function that waits for the handler and then deserializes the result. When response arrives we search for a corresponding handler and pass a response (TransportMessage) to it. Our asynchronous function deserializes the result and returns it to the caller.