My bookshelf is full of books about programming languages, from APL to Z. They are a little bit dusty because the last decade OSGi kept me confined to Java. However, I think it is time we should broaden our scope. There is just more life out there then just Java (really!).If you look at the OSGi API then you see that the class loader modularity is strongly tied to Java. I actually do not know any other language that provides a way to intercept class loading in the flexible way that Java allows this to be done. It is also clear that most other languages out there are not type safe, something the OSGi has been fanatic to maintain and support.
However, the most important part of the OSGi programming model has always been the µservices, an Inter Module Communication (IMC) mechanism, that has virtually no overhead but is a surprisingly powerful design primitive; µservices encode so many important design principles.
OSGi µServices are also the cornerstone of Distributed OSGi. As so much code is not written in Java, how could we provide the service model to other languages? Obviously JVM languages can usually use the Java API but that is likely not optimal for a language, you like to take advantage of the unique possibilities each language provides.
Now, I could sit down and dust off my Smalltalk and write a service registry with the OSGi semantics for Smalltalk. With a bit of effort I could probably do it for C(++), maybe even Basic? However, it is clear that most language experts do not live in my house. So the question to you is, how would you make the µservice model look in another language while remaining compatible to the OSGi semantics?
Write a blog or google document how your µservice API would look in your favorite language and place a comment on this blog with a link. I am really curious how those APIs would look like. Give me your Python, Ruby, Haskell, Scheme, Clojure, Smalltalk, Javascript, ActionScript, Scala, Cobol, Perl, PHP, .NET, Beta, ML, Modula, Pascal, Fortran, Forth, Erlang, Postscript, Bash, and any of those other languages you like!
Peter Kriens
P.S. This is something I am highly interested in which does not necessarily imply that the OSGi Alliance is interested in pursuing this.
Hi Peter,
ReplyDeleteA year or two back I attempted to port OSGi concepts to .Net (using C#). I will see if I can dig out the source and write something about it.
From memory it worked pretty well - particularly the micro services. The major downer was the inability to "unload" modules in .net without restarting the "VM".
Watch this space...
- Chris
The µServices is what I am after. I know about the loading/unloading problem in .NET but I think we can separate those 2 aspects of OSGi. So for now I would like to see an API in different languages for the services only.
ReplyDeleteHi Peter,
ReplyDeleteHow incidental!
There is currently a thread ("Why do we need modules at all?") in the Erlang user group (http://groups.google.com/group/erlang-programming/browse_thread/thread/2ca2deb26aecb369) started by Joe Armstrong.
Stefan
Well, as Erlang hasn't gotten its head around objects yet I would not use it as a benchmark for software engineering ...
ReplyDeleteHello Again,
ReplyDeleteI managed to find a bit the port of OSGi to .Net that I attempted a few years back. It turns out it got as far as an open source project (very low activity).
http://developer.berlios.de/projects/physalis/
Looking at the code; I have a few notes:
1) The focus seems like it was on lazy loading modules (the bundle activation side of things) rather than micro services. But there are nascent interfaces for that too.
2) The interfaces are a shameless rip off of OSGi using all the C# tricks.
3) Rather than manifest.mf most of the meta data is in attributes attached to the "module" (DLL)
Worth a look (glad to hear your thoughts). With a little effort I could probably get the micro services dusted off and finished.
Regards,
Chris
Do you have a link to source or Javadoc?
ReplyDeleteBrowse the SVN
ReplyDeleteOr grab a copy anonymously:
svn checkout svn://svn.berlios.de/physalis/trunk
I have not worked out a way to get the documentation out of C# into HTML yet. It's not as easy as JavaDoc anyway :-)
- Chris
You may be interested in Fantom - http://fantom.org/ - if you haven't heard of it. A statically typed language with modularity (pods) built in from the ground up - nothing exists outside a module. It runs on the JVM and Javascript. And its simple and easy to pick up. There is some support for pluggable definitions of what a module is to allow for things like classloader management.
ReplyDeletePeter, I don't think it meets your "remaining compatible to the OSGi semantics" criteria but the paper "Dynamic Applications From the Ground Up" (www.cse.unsw.edu.au/~chak/papers/yi.ps.gz) describes an elegant Haskell approach to the problem of creating fully dynamic applications.
ReplyDelete@Peter Kriens
ReplyDeleteErlang is a totally different paradigm. Objects are not the only why to make software modular. Erlang hangs more on mathematical laws, which are there to providing a stable base of composition of functions (and all kind of other mathematical structures).
It is a different beast. It would be very hard to translate something from Java to Erlang or Haskell. Haskell's type system is even not compatible with Object Oriented programming.