Motivations for an embedded COM
Preparing some training that includes dealing with an embedded COM implementation, I have been thinking about why COM might be adopted in preference to some other component model?
In the domains I am considering, a prime motivation for component architectures is to standardize nd so to encourage the growth of a market in third-party components. Microsoft’s Component Object Model (COM) is attractive because it is a simple model that is widely used and well documented. COM is actually quite a small subsystem - a usable subset can be implemented for MIPS in less than 10 k. A full implementation provides functionality that may be unnecessary, and imposes overheads that are undesirable in real-time embedded systems, but a subset that avoids the more esoteric parts can be very useful.
Other software component models have been defined that target real-time embedded systems. For example Philips’s Koala component model for consumer electronics, the commercial product ControllShell, and ACCORD. Koala is quite different from COM. The other two differ from COM only slightly - but still enough to make them 'non-COM'. I think actually this is the key point against these and in favour of COM - just that COM is indeed well established and widely used. S developers of platforms that implement COM will not have to write extensive documentation, and can hope to find a pool of experienced COM programmers to use their platform who can be productive quickly.
Microsoft themselves have introduced a new component model as part of .NET. But .NET shifts responsibility for providing some ‘house-keeping’ functionality away from the components and into a more sophisticated run-time system. This is typical of a trend towards evolving large all-encompassing frameworks which can be made into products by customizing in a few isolated places: which is different from the component-oriented goal of building products out of relatively few pre-fabricated components. Many real-time embedded systems will not use the full functionality of the .NET run-time system, it may be wasted and become an undesirable overhead. Microsoft has defined a special compact version of .NET but the primary aim of .NET is greater development productivity, not resource efficiency. Since even COM is feared for its overheads in the embedded world, moving to the larger .NET seems unlikely to be acceptable just yet.
I have to consider also why not to just use C++ instead of a component model. COM is not a programming language like C++. Using COM enforces an object-oriented programming style without actually requiring the use of C++. Because it is implemented through vtables that require only a language that supports function calls through pointers, COM is in principle not tied to any particular language. COM specifies interfaces in a language-independent way. It in fact uses its own Interface Definition Language (IDL) that can be compiled (by an IDL compiler) to produce template code. Sadly, Microsoft’s IDL compiler is rather Windows-specific so the translation from IDL must ether be done by hand or someone must create their own IDL compiler.
In C++ it is possible (though bad practice) for the user of a class to have direct access to the data of an object: because COM cleanly separates interface from implementation it avoids this problem.
In the domains I am considering, a prime motivation for component architectures is to standardize nd so to encourage the growth of a market in third-party components. Microsoft’s Component Object Model (COM) is attractive because it is a simple model that is widely used and well documented. COM is actually quite a small subsystem - a usable subset can be implemented for MIPS in less than 10 k. A full implementation provides functionality that may be unnecessary, and imposes overheads that are undesirable in real-time embedded systems, but a subset that avoids the more esoteric parts can be very useful.
Other software component models have been defined that target real-time embedded systems. For example Philips’s Koala component model for consumer electronics, the commercial product ControllShell, and ACCORD. Koala is quite different from COM. The other two differ from COM only slightly - but still enough to make them 'non-COM'. I think actually this is the key point against these and in favour of COM - just that COM is indeed well established and widely used. S developers of platforms that implement COM will not have to write extensive documentation, and can hope to find a pool of experienced COM programmers to use their platform who can be productive quickly.
Microsoft themselves have introduced a new component model as part of .NET. But .NET shifts responsibility for providing some ‘house-keeping’ functionality away from the components and into a more sophisticated run-time system. This is typical of a trend towards evolving large all-encompassing frameworks which can be made into products by customizing in a few isolated places: which is different from the component-oriented goal of building products out of relatively few pre-fabricated components. Many real-time embedded systems will not use the full functionality of the .NET run-time system, it may be wasted and become an undesirable overhead. Microsoft has defined a special compact version of .NET but the primary aim of .NET is greater development productivity, not resource efficiency. Since even COM is feared for its overheads in the embedded world, moving to the larger .NET seems unlikely to be acceptable just yet.
I have to consider also why not to just use C++ instead of a component model. COM is not a programming language like C++. Using COM enforces an object-oriented programming style without actually requiring the use of C++. Because it is implemented through vtables that require only a language that supports function calls through pointers, COM is in principle not tied to any particular language. COM specifies interfaces in a language-independent way. It in fact uses its own Interface Definition Language (IDL) that can be compiled (by an IDL compiler) to produce template code. Sadly, Microsoft’s IDL compiler is rather Windows-specific so the translation from IDL must ether be done by hand or someone must create their own IDL compiler.
In C++ it is possible (though bad practice) for the user of a class to have direct access to the data of an object: because COM cleanly separates interface from implementation it avoids this problem.
Comments
Post a Comment