Thursday, June 8, 2000

There is no such thing as a Component

I maintain that there is no such thing as a Component in the same way that there is no such thing as a donut hole. Just as the donut hole doesn't exist without a donut to define it, a Component doesn't exist without a Framework to define it. Using a printed circuit board as a metaphor for a framework, it's the "sockets", into which IC chips are meant to be plugged, that define components. So called universal or standalone components are meaningless (and certainly useless) without some framework that expects components of the same purpose and interface.

Ok, so what's your point? The point is that too many developers (and books on the subject) think about components as standalone chunks of functionality that can be "glued together" after the fact. They don't realize that the framework has to come first and foremost in conception and design. Szyperski doesn't get around to talking about frameworks until chapter 21 of his Component Software book for heaven's sake.

Even physical components are like this. The prototypical component, the IC chip, always was designed within a family of chips that were meant to work together. They all needed the same voltage levels for zeroes and ones and tri-states, the same amperage levels, the same clock rates, etc, etc. Other families used other voltage levels. The first reusable, interchangeable parts in history were for rifles. They were meant to be easy and quick to replace (as opposed to the hand crafted muskets they were replacing) but they were meant specifically to make rifles!

Rummaging around a garage, you could find all sorts of "widgets" and "gizmos" that you might guess are components of something, but unless you know what framework they were meant to be a part of, they are not good for anything but door stops or paperweights. In other words, random components don't tend to fit together or work together.

Too many people are trying to make "universal" components without realizing that those components still work within some framework that allows them to be put together and communicate with each other. The problem is that other people doing the same thing have defined other "generic" frameworks that are none the less incompatible.

For example, the toys that baby boomers played with when they were young abounded with generic frameworks of universal components: Tinker Toys, Lincoln Logs, Erector Sets, LEGOs. They all had universal components within a generic framework that let you build anything. BUT, you couldn't mix Tinker Toy parts with Erector Set parts (without glue or duct tape).

Ah, you say. That's why I like duct tape, weakly typed, languages like Perl that lets me glue together parts. Also, what about Play-doh?! You could stick anything together with that! Yes, but there was a reason you made bridges out of Erector Sets instead of Play-doh, and the same reasons apply to software systems (but Strong versus Weak typing is another discussion).

Objects versus Components

Until I had this epiphany about components as donut holes, I didn't have a good answer to the question "what's the difference between an object and a component?". I now understand that all objects ARE components, but not all components are objects. The framework that defines a set of components does not have to be an object oriented framework. But all object oriented languages define an object framework. They are generic enough frameworks that any objects programmed in that language may interoperate with each other. Unfortunately though, as with Tinker Toys and Lincoln Logs, Java objects typically can't interact with Smalltalk objects.

In the Java language there are at least two levels of object framework. There are plain old Java objects (POJOs) and there are so-called JavaBeans. Whereas any property of a POJO can be accessed (assuming its not protected by the "private" keyword) via a fooObject.barProperty syntax, only special properties may be accessed via the JavaBeans framework. JavaBeans are those objects that have defined special property accessor methods of the form: getBarProperty() and setBarProperty(). "JavaBean" is the name given to any component that works within that specialized framework. To make matters confusing however, it turns out that Javasoft called more than one framework "JavaBeans" (arrgh!). There are even more specialized versions of JavaBeans that are made to work with fancy GUI toolkits.  SO, WITHOUT CLEARLY FOCUSING ON FRAMEWORKS, EVEN JAVASOFT CONFUSES DIFFERENT COMPONENT TYPES WITH EACH OTHER!

The moral? Don't fret that there is no such thing as a truly "universal" component. Don't spend energy trying to build them, or building "single universal" frameworks. Focus on what is needed for your situation and design a well crafted framework first and foremost. If it needs to work with other frameworks (like whatever Microsoft builds that won't integrate with anybody else), understand that Frameworks need bridges to each other rather than simplistic component socket adapters.

Saturday, February 26, 2000

You can't surf the same Web twice

Just as Heraclitus said in approximately 500BC (as quoted by Plato),
"You could not step twice into the same river; for other waters are ever flowing on to you.";
You can not access the web as it existed yesterday, much less as it was a year ago.
There is no time on the web; only a fuzzy "now".

This makes it important for web site designers to be very clear about which portions of their content are static, and which are dynamic.  The API to this database of content (i.e. the web site itself) is the set of URLs published to access that content.  Just as Interfaces cause great problems if they change frequently (or have no precise meaning as to what they are retrieving), URLs must have stability and precision-of-definition too!  If the same content is to be made available for a long duration then its URL should not change, and it should always return the same version of the content.  On the other hand, if content is defined to be the current value of some query (e.g. the current temperature, or the current version of the home page) then its exact same URL should ALWAYS return the current value.

Just as with software engineering, this means that Interfaces need to be separated from Implementation such that the Interface can be stable even when the Implementation changes.  So, URLs should be designed and specified independently of which host machine, programming language, web framework, etc are used to implement the site because those will change over time.

Some web sites have embraced this notion in part by providing "permalinks", but unfortunately, it is often only the current version of the item to which it refers. Earlier drafts, editions, revisions that were published (and cited in magazines, books, other web sites) are not retrievable even with permalinks.

While the WWW is always changing, there should be ways for books to cite unchanging web content such that it can still be retrieved years later. Stable URLs are the solution.

POSTSCRIPT - Jan 3th, 2009
Off and on over the history of the web, many have advocated giant internet archival sites to solve the problem of stable URLs to frozen data. It can be seen in retrospect that this has not worked because:
a) Many archival sites have died, collapsing under the sheer weight of data
b) without a stable URL scheme implemented by each web site, one still doesn't know how to get to the latest version of a web page versus the version that existed 3 years ago.

POSTSCRIPT - May 12th, 2009
There is a new book out by Dan Bricklin that republishes his 10 years worth of blogs. He talks about this very problem in his book and this interview.  He praises which is the new location of the archives that search engines once linked to directly on their search results.

POSTSCRIPT - April 20th, 2010
There is a new program on ITC Conversations that talks about yet another new proposal to fix the problem of the web having no time dimension...i.e. no way to say "show me as it looked 6 months ago". See