I spent a couple of years (while working a full-time job) writing my master's thesis on "component technology" -- COM, CORBA, .NET assemblies, OSGi and the COM-inspired object model developed at Ericsson and Sony Ericsson for use in cell phones. This was back in 2009.
I tried to make sense of how all these disparate technologies fit together. Give it a read if you like (CC-licensed):
As for your thesis, i.e., components in embedded system, I think a critical missing piece is C/C++ dependency manager like conan/vcpkg, which IMO is the primary reason why such technology is not popular in embedded world.
you are the expert so please correct me if I oversimplify>
to me .net assemblies and Java JAR files are just a portable DLL (because they use bytecode and support reflexion).
OSGi seem to push the concept further and try to define how plugin should integrate in a hosting application (ex: eclipse ID plugin, web browser extension ...)
The way OSGi try to achieve this is by defining protocol for dependency injection (Services Registry, Modules, Life-Cycle inteface ..)
I never really understood COM, I built some OCX module for visual basic 6. I have been told OCX are ActiveX control and that ActiveX control are based on COM but this is all confusing.
It all depends on how you define a software component. I use one definition in my thesis, and I argue that .NET assemblies satisfy that definition, as do OSGi bundles (but not plain JAR files). (There have been many, many attempts at defining a software component, and they tend to be incompatible with one another.)
In the end, it doesn't much matter. I chose a topic for my thesis way back in 2005, and at that time, there was some academic interest in what was called Component-Based Software Engineering (CBSE). That interest, as far as I can tell, evaporated pretty quickly.
(Sorry about the late reply, I suppose I stopped monitoring the thread after a while.)
If memory serves, XPCOM was fairly derivative of COM, but fully cross-platform. (It had to be, as Netscape's browser and its open source successor ran on Windows, Mac OS and lots of different Unix flavors.) For this reason, I didn't include a full section on it in my thesis, but I do mention it in passing.
XPCOM saw overuse in the codebase, which led to bloat and a years-long effort to cut down on its use[1]. However, when I studied XPCOM, it seemed like an excellent way to bring the core ideas of COM to a cross-platform codebase, with C++ and JavaScript language bindings.
Comments
I spent a couple of years (while working a full-time job) writing my master's thesis on "component technology" -- COM, CORBA, .NET assemblies, OSGi and the COM-inspired object model developed at Ericsson and Sony Ericsson for use in cell phones. This was back in 2009.
I tried to make sense of how all these disparate technologies fit together. Give it a read if you like (CC-licensed):
http://www.polberger.se/components/
http://www.polberger.se/components/read/
http://www.polberger.se/components/thesis.pdf
This is really interesting, thank you for sharing. I downloaded the PDF of your thesis and put it in my to-read library.
Nice, let me know if you have any questions or feedback! (Email in profile.)
As for your thesis, i.e., components in embedded system, I think a critical missing piece is C/C++ dependency manager like conan/vcpkg, which IMO is the primary reason why such technology is not popular in embedded world.
you are the expert so please correct me if I oversimplify> to me .net assemblies and Java JAR files are just a portable DLL (because they use bytecode and support reflexion).
OSGi seem to push the concept further and try to define how plugin should integrate in a hosting application (ex: eclipse ID plugin, web browser extension ...) The way OSGi try to achieve this is by defining protocol for dependency injection (Services Registry, Modules, Life-Cycle inteface ..)
I never really understood COM, I built some OCX module for visual basic 6. I have been told OCX are ActiveX control and that ActiveX control are based on COM but this is all confusing.
It all depends on how you define a software component. I use one definition in my thesis, and I argue that .NET assemblies satisfy that definition, as do OSGi bundles (but not plain JAR files). (There have been many, many attempts at defining a software component, and they tend to be incompatible with one another.)
In the end, it doesn't much matter. I chose a topic for my thesis way back in 2005, and at that time, there was some academic interest in what was called Component-Based Software Engineering (CBSE). That interest, as far as I can tell, evaporated pretty quickly.
What's your opinion about Mozilla XPCOM regarding the others?
(Sorry about the late reply, I suppose I stopped monitoring the thread after a while.)
If memory serves, XPCOM was fairly derivative of COM, but fully cross-platform. (It had to be, as Netscape's browser and its open source successor ran on Windows, Mac OS and lots of different Unix flavors.) For this reason, I didn't include a full section on it in my thesis, but I do mention it in passing.
XPCOM saw overuse in the codebase, which led to bloat and a years-long effort to cut down on its use[1]. However, when I studied XPCOM, it seemed like an excellent way to bring the core ideas of COM to a cross-platform codebase, with C++ and JavaScript language bindings.
[1] https://wiki.mozilla.org/Gecko:DeCOMtamination