Hello,
Rellermeyer Jan Simon schrieb:
Hi,
nice to hear from you.
Yes, it has been a while. I hope things are going well for you in Berlin.
I'm still fighting here to help to get OSGi accepted ...
As I understand, you are working on a component-framework written in C.
This is somehow different to what I was thinking of: I thought of some
C++-Bundles which can provide and use services into/from a OSGi-
Runtime.
That means that the OSGi-Runtime will manage dependencies and
lifecycle, but the C++-Bundles can participate on this through some
bridging technology ...
The pure bridging is something that we have implemented in the past for R-OSGi. Since you are likely crossing process boundaries (you actually want to have separate processes to avoid the issues that JNI has), you anyway need some IPC-like mechanism (which R-OSGi can do).
I don't get this. Why is it nessecary to start a new process and which
issues on JNI do you mean? Is it related to memory problems?
And, in order to communicate between modules written in Java and C/C++, you
need to agree on a common type system. So if the starting point is OSGi, you
probably want this type system to be the Java type system in order to have the
full expressiveness of OSGi. As we pointed out in here:
http://www.iks.inf.ethz.ch/publications/iot08.html , this fortunately doesn't
mean that you have to implement a full type mapping to write services in
languages like C/C++. Instead, it's sufficient to implement type mappings for
the types involved in the conversations, namely, those used in the service
interface. We managed to even implement this idea for sensor nodes with 8bit
microcontroller, some few KB of RAM, running Ti!nyOS.
Yes, you did a great work on this. I read this before. Really nice work.
Indeed, we didn't deal with managing the lifecycle of the services because we
were running them in different processes, most of the times, even on different
machines.
And here are the starting points for my ideas. I was thinking about
devloping an OSGi-like C++-API which includes bundles, lifecycle and
services. Not the whole OSGi-API, but some important parts (which I have
to identify). The big challenge then is to make the services from the
OSGi-runtime available to the C++-bundles, and vice versa. A
model-driven approach could be used to generate the service API for Java
and C++, but I'm not sure how the (transparent) mapping between this
servces could be realized. I think, I will need some automatic proxing
in Java and C++, but I'm not sure.
Also I'm not sure if the plenty of JNI alternatives (JNIEasy, JNative,
Java Native Access (JNA), NativeCall, Jace, J2Native, etc.) can help me
with relaizing this...
However, If you say that you've already solved some of this problems
with R-OSGi, I will take a look at it.
I think it's iteresting to push the OSGi-concepts into C++.
However, this would be a first step towards what we are trying to achieve. In our model, we are trying to integrate modules from different frameworks written in/for different languages. This fits very well into the "Virtual Framework" idea that I presented at last EclipseCon.
We recently received a generous grant from Microsoft
(http://systems.ethz.ch/news/systems-group-awarded-grant-from-microsoft) in
order to pursue this approach and (hopefully) come up with a universal
component model for embedded devices.
Wow, that's fantastic! I wish that Microsoft Germany would also start
such programs.
Kind regards,
Siamak
Cheers,
Jan.
------------------------------------------------------------
MSc Jan S. Rellermeyer, Systems Group, Department of Computer Science, ETH
Zurich
IFW B 47.1, Haldeneggsteig 4, CH-8092 Zürich, Switzerland
http://www.systems.ethz.ch
------------------------------------------------------------
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
