celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject remote service admin with libffi
Date Sun, 31 May 2015 19:20:43 GMT
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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message