[Miwi-middleware] KIARA/DFKI Java Design Document Revised

[Jaime Martin Losa]

	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: <https://lists.fiware.org/private/miwi-middleware/attachments/20140929/e52037e2/attachment.docx>