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 <Philipp.Slusallek at dfki.de> 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 > --------------------------------------------------------------------------- > <philipp_slusallek.vcf>_______________________________________________ > 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: <https://lists.fiware.org/private/miwi-middleware/attachments/20140930/e03f8774/attachment.txt>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy