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

David Bosschaert davidb at iona.com
Wed Sep 24 08:00:39 EDT 2008


Hi Siamak,

One way to achieve this would be to go outside of the process space and 
use Distributed OSGi Services to talk between C, Visual Basic or 
whatever language and OSGi Services.
As Jan mentions below, you need to decide on an interface between the 
components, which could be Java, but you can also think of using WSDL, 
IDL or even XML Schema for such an interface.

Have a look at RFC 119 (Distributed OSGi), of which a draft has been 
released last summer (see here: 
http://www.osgi.org/download/osgi-4.2-early-draft.pdf ) as it outlines 
the various scenarios for using existing bindings and protocols to 
distribute OSGi Services and OSGi Service consumers and allow them to 
communicate with non-OSGi runtimes as well using this mechanism.

Best regards,

David

Siamak Haschemi wrote:
> 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
>>     
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev at mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland



More information about the osgi-dev mailing list