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<T> to describe
which methods of the interface are bound to which service
methods in the IDL provided by the server.
MethodBinding<Calc> 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<V> class. For example:
public interface Calc {
public Future<Integer> add(int a, int b);
public Future<Float> 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<V>.get() will enforce
immediate execution and block until result or an error arrives.
The only limitation of this approach is that Future<V> 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<T> 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: <https://lists.fiware.org/private/miwi-middleware/attachments/20140923/83d485e0/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy