[osgi-dev] Integration of native languages, "Universal OSGi"

Siamak Haschemi haschemi at informatik.hu-berlin.de
Wed Sep 24 06:42:07 EDT 2008


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 at mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: haschemi.vcf
Type: text/x-vcard
Size: 366 bytes
Desc: not available
Url : http://mail.osgi.org/pipermail/osgi-dev/attachments/20080924/f3c3792b/haschemi.vcf


More information about the osgi-dev mailing list