Component-based development sounds like a neat idea, doesn't it? It seems intuitively obvious (at least to me) that if we could assemble applications out of well defined building blocks, we could finish projects a lot faster. And we'd build better applications too, because we could focus on solving the problems specific to our domains, rather than on how to glue this unwieldy piece of code over here to that clump of spaghetti over there.
Yet there are some big problems to be solved before component-based development makes good on its promises. One of the burning issues today is how to make a component "trustworthy." Just because a component implements the interface we want doesn't mean it will actually do what we want. We have to specify some semantics as well, yet without getting into implementation details. That is a tricky problem. It's like saying, "Take me from Key West to Miami. The route is up to you." If we specify too much — say, that the trip must be by car — we can easily spell out the whole implementation.
This issue of component trustworthiness derives, in part, from a desire to make components interchangeable. The idea is that we can quickly modify the behavior of an application by changing out a component, or improve behavior (well, that's the idea) by replacing an old component with a newer version. Trustworthiness and interchangeability address component-based development at a fairly low level, the level of the component. It is all very interesting stuff, yet I fear that if we focus too much at this level we will miss the point. Maybe before we talk about making components trustworthy we should simply focus on making them identifiable, and guaranteeing that we know which version of a component we actually have!
In Windows land, at least, this guarantee is hard to come by. Many of us have had the dubious privilege of having DLLs on our systems silently updated when installing new software. Consider yourself lucky if such an "upgrade" did not break any of your existing applications. I just don't think component-based development can be viable with this sort of nonsense going on. We need standards at the OS level that specify how to identify components by version, how different versions of a component can coexist in the same environment, and how applications can hang onto the versions they need to keep running reliably. I submit that the alternative — making components so perfectly interchangeable that we need not know their versions — is a false solution. Perfect interchangeability is a pipe dream, and if we fail to understand this we will only be condemned to more years of frustration and unmaintainable systems.
At the risk of offending the component experts everywhere, I present here my own mini-manifesto on component-based development. It is just a collection of ideas, a step toward standardizing component-based development at the OS level. Maybe these ideas will turn out to be naive or unworkable. But as long as they spark some intelligent thought and discussion, I'll be happy:
- Every component-based applications should include a manifest function. When invoked, it would list every component used by the application, along with its version number.
- Every component, shared library, DLL, etc. should have a version function, callable by the host application. It should return a string that uniquely identifies which version of component it is. This is not to be confused with COM's GUID (Globally Unique Identifier), which identifies interfaces, not versions. Given a particular interface, we want to know which implementation of it we have.
- It should be possible to freeze the configurations of non-distributed applications. That is, we should be able to protect an application against spontaneous replacement of any component upon which it depends. This probably implies that applications keep private copies of the components they need. (When 10 GB hard drives are selling for less than $500, does it really make sense for every application on a machine to share the same 50 KB DLL?) Actually, I would extend the scope of this "configuration freezing" to distributed applications that were confined to an enterprise-controlled network. Of course, for applications that rely on components "out there" on the Internet, all bets are off.
Well, that's it. If you have a particularly strong reaction to these ideas, I'd like to hear from you. Tell me why I'm all wet, or tell me where you would go even further than me. I'm all for using components, interchangeable or not. I would just like to know what I've got before I plug it into an application. I don't think that is too much to ask.
Marc Briand
Editor-in-Chief