celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bjoern Petri <bjoern.pe...@sundevil.de>
Subject Re: remote service admin with libffi
Date Wed, 03 Jun 2015 07:02:08 GMT

Hi Pepijn,

I actually have to admit that I've been a bit jealous when looking how 
easy the serialization can
be done with Java. For C there is always additional effort in adapting 
the proxy/endpoint
bundle. So, if this works as expected it would be from great benefit!

Looking at the code you've implemented I would assume that we can be 
even quite
flexible (e.g. variadic functions). The only constraint there is using 
the Java bytecode method
signature as schema. That's why it also might be an idea to also support 
an evolving schema?!

I am also wondering how to handle complex data types like hashmaps or 
arraylists. We usually
store void* pointers in there, so we cannot easily create a deep copy. 
Any ideas on that?

Last, this will also not work with the current amdatu remote service 
so we should ensure that we can still do it the 'old-fashioned' way - 
but that's probably
what you had in mind anyway.


On 2015-05-31 21:20, Pepijn Noltes wrote:
> Hi All,
> I pushed a new branch to Apache Celix (rsa-ffi) which contains a 
> initial
> setup for a remote service admin based on libffi [1].
> libffi (MIT License) is a c library for foreign function interface and 
> is
> used, among other, by python to invoke c functions. This is done 
> runtime by
> constructing calling conventions (ABI). libffi has been around for 
> quite
> some time and supports a broad range of configurations.
> Although not design for this purpose libffi is very use-able within 
> Apache
> Celix to support dynamic import/export of services. In the branch I
> realized this by provided an additional property for remote services.
> For example the calculator service is register with:
> ["add(DD)D", "sub(DD)D", "sqrt(DD)D"]
> as property values.
> This describes the services using a format inspired (and largly
> overlapping) with Java bytecode method signature. This description 
> (schema)
> is the only thing the ffi rsa needs to make endpoints or proxies. Note 
> that
> at the moment only double as argument type is supported.
> For endpoints ffi_cal structs are created for invoking the actual 
> service
> methods and for proxies a ffi closure object are created to "catch" the
> methods invoked.
> In the branch there is also a dyn_type & json_serliazer component which
> goes even furher and uses libffi types knowledge (alignment, size) to
> runtime construct and manipulate (complex) types based on a schema.
> For example:
> The following schema "{DI} a b"
> describes the following struct:
> struct arg {
>   double a;
>   int32_t b;
> };
> My goal is to combine the rsa and serializer part to support dynamic
> proxy/endpoints and serialization as long as there is a runtime schema 
> of
> the services. So for example a json based Apache Avro schema. The 
> dyn_type
> code works on a specific schema (again inspired by java bytecode method
> signature) to avoid support only a single serialization schema.
> As result only the types and services header have to be generated, 
> based on
> a schema (e.g. Apache Avro), and no additional bundles are needed to
> support remoting those services.
> The branch contains a struct_test executable which runs a few examples 
> of
> dynamic serialization based on a schema describing the types. For info 
> if
> you install pahole (linux only?) you can verify if dyn_type (-> libffi)
> creates the correct struct layout.
> Any thoughts/comments ?
> [1] https://sourceware.org/libffi
> Greetings,
> Pepijn

View raw message