Thursday July 14, 2005
Reusable components This is part of a discussion I'm having on the opensolaris-arc mailing list...
One of the recurring problems that we try to manage at Sun is how to effectively reuse components that should be reusable.
Reused components add risk to complex systems, primarily because incompatible changes to a component will break other parts of the system.
The FOSS/distro world many times deals with this situation by resyncing and recompiling whole subsystems every time some component revs in an incompatible way, giving what I call "source level compatability". Think gentoo and autoconf.
The alternative chosen by Sun and others is to provide "binary compatability", even in the face of incompatible change. This requires that we worry a lot more about changes to the interfaces between components:
- Exposing too many implementation details makes it difficult to evolve a component without breaking things that depend on it. We call exposed interfaces "public" and implementation details "private".
- Interfaces have expectations that need to be set and managed. We ask "Can we expect this interface to be stable over releases, or is it more of an experimental thing that will change in the next release?
- As a component evolves, we ask "what interfaces have you changed, and what expectations did you set when you first exposed them?
- We use two taxonomies to help us keep track of all this - an
interface taxonomy that sets expectations of stability and a release
taxonomy that defines the type of release that can contain the
changed interface.
Stability Public Stable, Unstable, Volatile, "not an interface" Private Consolidation Private, Project Private Releases Major, Minor, Micro, Patch There is a relationship between the two:
Incompatible changes to a Stable interface are only allowed to be made in a Major release of the consolidation that contains that interface. Unstable Major or Minor Volatile Major or Minor or Micro NAI Major or Minor or Micro or Patch * Private Major or Minor or Micro or Patch
As long as these components are not reused by anything else in the system, it is easy to "not care" about how they evolve or change. The collection (which we call a "consolidation") is both low-risk and low-maintenance.
As these components start to get reused as building blocks for other consolidations, the potential cost to the system increases. If a component changes in an incompatible way, all the things that depend on it will need to react; if they don't, things may/will break.
The architectural question here really comes directly from kindergarten: "does it play well with others?"
( Jul 14 2005, 02:40:00 PM PDT ) Permalink Comments [0]
This is a personal weblog, I do not speak for my employer.
