This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
I worked 10 years ago on a big project for a bank that provided almost the same functionnality than osgi... but it was written in C and linked to windows (NT 3.5).
I'm very interested by osgi... but had no enough free time yet to practice it.
So I have only a partial knowledge about osgi...
I would like to explain what in my "old project" offered in my opinion more fonctionnality:
- each module can be asynchrone (by configuration)
- each module can have a queue (by configuration) who can be or not saved to the disk (in case of crash, ...)
- each module can "auto" check for an update (via several protocols: http, ftp, ...)
- each module can load a new version and run in the same time than the other versions
- each module who depend from another version will take :
a. the version of the depend specified
b. the most newest version compatible (from until)
- when a newer version is loaded, the previous version can be "disabled for new request"... and stop when is job queue is empty.
- each module provide informations about his load, his average processing time, ... to a "statistic" service
- each module can be installed to different servers and communicate with dependencies through severals protocol (tcpip, ...)
- each module could be stopped for system maintenance and save his queue to the disk
- each module had a "watchdog"... who allow to avoid the system to freeze in case of deadlock or other similar problem.
I would like to debate how it should be possible to achieve the same functionnality with osgi.
--> I hope to work with osgi next year...
OSGI look very similar in several ways to this project.
Nice to see it in java 10 year later :-)
Thanks for your remarks.
Joined: Oct 21, 2003
I did'nt get any answeer... but win the book.
Well, this is may be a sign I have to read the book (I will).
It sounds like the project you worked on provided a lot of the same features as OSGi. Specifically...
- The ability to run multiple versions of a module at the same time
- Dependency management where one module can depend on a specific or ranged version of another module (although OSGi offers package-level dependencies which are more loosely-coupled than module-level dependencies)
- Hot-swapping of dependencies
- Distributed modules (becoming possible with OSGi R4.2)
As for some of the other features...OSGi may not offer them as part of its spec, but I can imagine ways to build on top of OSGi to provide them.