4

I'm thinking about Python and C/C++ combination to replace the original concept about OSGi + Java + JNI + C/C++ in our SW architecture.

I definitely don't need to replace all features of such OSGi frameworks as Felix or Equinox.

What I really will need in my Python code:

  1. Enabler of modularity for the application layer
  2. Component-based framework for applications
  3. Central registry of services/components
  4. Very lightweight framework, it will run on embedded devices (though pretty enough of RAM)

Can you please advise on such Python framework?

Oleg Puzanov
  • 71
  • 1
  • 3
  • Have you done some research? What came up? Have you tried anything? What didn't work? If you have done research prior to asking this question, mention it in your question. If you have not done research, please do so now (and also for future questions). – Björn Pollex Aug 29 '12 at 06:50
  • Bjorn, we did some research and in the end decided to stick with "Java + OSGi" combination. – Oleg Puzanov Sep 04 '12 at 20:30

2 Answers2

3

I think much of what OSGi offers is closely related to the architecture of Java: its class loaders and type safety. Implementing a service registry should not be too hard but managing it with the accuracy of OSGi will be virtually impossible. Obviously the power of multiple namespace that OSGi offers will not work in Python unless you move the modules into separate processes which will require more expensive inter process communication for inter module communication. You could start with Apache Celix, which is native based but I have similar doubts about its utility since native code does not provide a lot of information about its dependencies.

A more general solution is the original idea of Universal OSGi. In this model you keep the OSGi framework as it is for the deployment and management. However, you create handler bundles that can map a bundle written with other languages. E.g. a Python handler or C++ native. The handlers would map a native service registry model to the OSGi service registry. This is surprisingly easy to do since the OSGi service registry is properly evented. The native handlers would map the bundle events like start/stop to instruct the operating system to start/stop the native code.

Peter Kriens
  • 15,196
  • 1
  • 37
  • 55
  • Hi Peter, thanks for such valuable comments. In the end of our research we've still stayed with Java+OSGi combination instead of Pyton frameworks. There are many reasons, specifics of memory management in Python is one of the main reasons. Extreme efforts to enable lifecycle management for components in Python - another reason. – Oleg Puzanov Sep 04 '12 at 20:28
1

Peter already mentioned Apache Celix. Might be well worth to check it out. Part of Celix is a Remote Service Admin (RSA) implementation, making it possible to use it in a distributed environment. Eventually this implementation will also make it possible to communicate with a Java based OSGi framework, making Celix+RSA an alternative for JNI. This has the additional benefit that the native and java code don't share the same process. If one end runs into a problem, the other end still stays running.

In line with Celix, you could as well look at Native-OSGi, this is an effort of Celix and some C++ OSGi like frameworks (CTK Plugin Framework and nOSGi) to come up with a combined approach for Native OSGi like implementations. This includes stuff like a well defined API, bundle format, code sharing etc.

Looking at your requirements I thinks Celix and Native-OSGi might be a good fit.

Alexander
  • 553
  • 5
  • 9