A report by Ian Graham
This
paper summarises the discussion that took place at
a session of OT99 in Oxford, England on March 29th
1999. The session set out to explore the issue of
whether the recent emphasis on components is justified
as something genuinely different from object technology
or merely supplier-motivated hype. Participants were
invited to air their opinions and debate this and
the following auxiliary questions:
- What
exactly is the difference, if any, between a component
and an object?
- Do
components delivered as binaries which cannot be
modified by inheritance throw away most of the advantages
of object-oriented programming?
- What
is the ideal granularity of components, if there
is one?
- What
effect does the component viewpoint have on language
design and language selection?
- Are
IDL semantics rich enough to describe ‘business
object’ components?
- What
are the implications for object-oriented methods?
The
initial participants were:
Peter Jones (Bezant Ltd.)
Andrew Watson (OMG)
Alan O’Callaghan (De Montfort University)
Alan Wills (Trireme Ltd.)
Microsoft Inc. were invited to participate but declined.
The session leader was Ian Graham (Ian Graham Associates
Ltd.)
The majority of those attending (about 35) contributed
to the discussion at some point.
Peter Jones kicked off, pointing out that the concept
and term COMPONENT had a history just as long as that
of OBJECT, referring to a 1967 NATO conference. He
went on to try to distinguish objects from components
by saying first that component systems are extended
by composition rather than inheritance and then elaborating
the following differences:
- Objects
focus on conceptual entities whereas components
are based on more physical things.
- Objects
and components are both language dependent and separate
interface from implementation, but components depend
on context too.
- Components
are more pragmatic and impose a less rigorous discipline
on the developer.
His
most controversial point was that, while supporting
encapsulation, components failed to support inheritance
and other forms of polymorphism. Several people objected
that he seemed to have a completely different idea
of what a component was from everyone else in the
circle and opined that "if we forget polymorphism,
we’ve learnt nothing from OO". I think Peter’s
most interesting statement was that "the larger
the component, the less likely [that] it will be an
ideal match to a requirement", leading to the
need to bootstrap larger components. Clearly the discussion
reflected some industry confusion over terminology,
with large things like Word and Excel (which aren’t
polymorphic) being offered as examples of components
while other people think of things such as EJB or
COM+ finer grained components.
The audience was asked, on a show of hands, how many
were clear about the distinction between objects and
components when they entered the room. Nine hands
went up. At the end of the session only five people
answered this question positively; which clearly indicates
a problem in the face of what was actually a very
informed debate. I am convinced that components are
(as Paul Allen and Stuart Frost put it in their book
[1998]) merely "a new way of presenting objects
to the market".
Andrew Watson enumerated a number of dichotomies that
he thought would discriminate the concepts:
- Objects
were typically smaller than components
- Objects
worked within the boundaries of one programming
language rather than several
- Components
could include their own metadata while objects relied
on separate metadata
- Components
replaced traditional programming with the idea of
assembly
- Objects
stated what they provided in their specification
whereas components also had to specified the services
that they required in order to work
This
last point raises an interesting question for me.
Writing about object-oriented analysis and business
process modelling I had always been forced to assume
that objects had to include a ‘requires’ segment in
their specification. This is at the root of the notion
of collaboration in RDD and is represented in SOMA
by object’s message/server pairs (usage relationships).
The fact that object-oriented programming languages
do not support this is possibly one of the reasons
that most methods and notations like UML fail to offer
a distinguished ‘usage’ association. So, Andrew’s
comparison is clearly aimed at distinguishing components
from the common, language level notion of objects,
rather than a more rounded notion of an object suitable
for modelling business objects (which the OMG task
force is now referring to as components as it happens).
From that point of view I wonder if we could argue
that a component is what an object should have been
all along if we had defined it correctly.
Alan Wills pointed out that all software is very hard
to change and that we expect components to at least
address this problem. Alan O’Callaghan pointed out,
to little disagreement that much discussion of components
is vendor led. He argued that components were (tautologically)
things that could be composed and defined a component
as a software entity playing the role of a component
in a composition. He then argued that this is different
from saying they are things that could be simply composed.
Lego bricks, screws and house bricks were not components
(as is often suggested) when they are standing alone,
but only when they are in some larger composition.
Once in a composition they are as much a component
as any other element that was not pre-built. The difference
between them and the other purpose-built components
is that they have a special quality of being usable,
potentially, in more than one composition. Thus composition
was much more important than inheritance and that
this could not solve the software crisis: nothing
fundamental has changed! Interestingly, this theme
was echoed by Jim Coplien in a later OT99 goldfish
bowl, where he argued that in comparison to hardware
engineering, which was continually revolutionizing
its product according to Moore’s law, there had been
no fundamental improvement in software engineering
since 1956 (the invention of high level languages).
Relative to most other fields, our industry was actually
dysfunctional. Also, he said, no extant OO language
implements the original vision of object-orientation.
Alan also said that we needed to focus on qualities
that make components usable in potentially more than
one composition. Successful CBD will require a heightened
focus on software architecture and an enhanced emphasis
on object modelling (echoing the argument that I made
above for embedding usage relationships in the interface).
The question Alan then posed, in face of the vendor-led
hype about "software's industrial revolution",
was what was the software crisis and how did these
new components solve it? The essence of the software
crisis was the complex nature of the problem for which
software is being used to provide solutions. Fred
Brooks in 1987 clearly differentiated between this
(‘the conceptual essence’) and other problems of software
development (i.e. representation) which he considered
to be ‘accidental’ in the Aristotelian sense. Essential
complexity hits us in the face in terms of the composition
(the whole) not in its parts, and he suggested that
the ‘new’ idea of components did not solve the software
crisis and bring about the software industrial revolution
for the simple reason that, in and of themselves,
they did not address this conceptual essence. Not
a single one of the issues that bedevilled software
reuse through OO development was solved by components;
real advances in that direction would come through
a focus on object modelling and software architecture.
This would become clearer once the Y2K and EMU-conversion
issues were out of the way. Big corporations' use
of ERP modules to solve these twin problems at one
fell swoop in certain constrained areas have temporarily
inflated the market for pre-built solutions. The ERP
vendors themselves know this to be true, because they
are tring to find ways to ‘componentize’ their products.
And we are getting e-mails from their consultants
asking about modelling and architecture...
Charles Weir asked "what are you buying when
you buy a component?" and answered his rhetorical
question with "something tested". Surely
that was at least a small step forward. Furthermore
that use of standard components helps organizations
to enforce architectural choice: another mitigator
of chaos.
Kevlin Henney said that the focus of component based
develoment was on deployment. Given that a component
in the context of this discussion is not synonymous
with a single object (or even, more accurately, class),
this does not mean that we have a contradiction with
respect to analysis of key business issues. These
are more the concern of earlier parts of the lifecycle,
and their realization is in the more traditional realm
of OO. As the lifecycle progresses, one will turn
naturally more toward matters of deployment architecture,
and hence the packaging of units of development: components
make great packaging for objects. CBD and OO share
a common set of principles, but one is talking about
the logical concepts within a system and the other
about the physical shape of a system. He emphasised
that although we need to consider establishing a stable
baseline architecture early (i.e. prototypes and proof
of concepts explored iteratively from the start as
opposed to ‘waterfalling it’), he believed that the
idea of trying to ‘analyse components’ from the word
go is often misguided. There seems to be a bandwagon/trend
of people rushing into analysing 'components', and
this means that either they are just doing traditional
OO (but with a global replacement of ‘component’ for
‘object’), or that they are clueless about the problem
they are trying to solve but have figured out mysteriously/magically/not-at-all
what they are going to ship. This raises the issue
of how problems are to be decomposed. If components
shift the emphasis from earlier to later in the life
cycle, this means that changes ought to be easier.
Of course, there is an implicit contradiction here.
On the one hand components emphasize the need for
architecture whilst on the other they could be used
as an excuse to defer analysis of key business issues,
which I think is a great danger. On the other hand,
it could be argued that this isn't so much a contradiction,
as a sign that deployment architecture is not equivalent
to understanding of key business issues.
Basing a method around identifying components at analysis
time seems like the end of Restaurant at the End of
the Universe where the Golgafrinchans are trying to
reinvent the wheel, but have spent all their time
worrying about what colour it will be. Focusing on
components alone is like the sound of one hand clapping,
but it doesn't seem to have stopped hype merchants
touting them as the answer to everything, rejecting
all that has gone before. This relates to another
point made by Kevlin, which was to distinguish between
conventional software use of the term component –
to mean any part of a program, including functions,
classes, etc – and the CBD usage – which he defined
as ‘a unit of executable deployment that plays a role
in a composition’, having adapted/evolved/extended
his usual definition in the light of what Alan O'C
said about composition. The distinction he drew was
between "component" with a 'c' – the general
meaning of the word – and "Component" with
a 'C' – the CBD specialization of it.
John Daniels was irritated that everyone seemed to
have a different definition of components and pointed
out that only individual vendors were clear on their
own definitions, which of course were all different.
The issue of standards therefore arises so that at
least the vendors could converge on agreement.
Andrew Watson asked Alan O’Callaghan whether components
represented any advance at all. He replied affirmatively,
because there is clearly a gain in productivity and
cost-saving etc., if you can buy something rather
than build it. That, exactly and precisely is the
gain you get. At most, you deliver more quickly today
than you did yesterday (later John Daniels suggested
even this gain is centred almost exclusively in middleware
and it is easy to agree with him). Earlier delivery
is a requirement that is real, and so gains in this
direction are extremely valuable in a competitive
world. But who believes the industrial revolution
was solely about early delivery? And who believes
that early delivery solves the software crisis? In
terms of dealing with the software crisis, Alan asked
what the bit of magic is in the black box (the component)
that wasn't there when I handcrafted solutions using
objects? Without modelling the problem space, and
specifying a software architecture that has some strong
correspondence to the problem space, how do I even
know which components to buy ?
As the discussion broadened, it was thought that concepts
should be maintained throughout the life cycle, so
that there was better seamlessness. Phil Boardman
raised the oft used hardware simile, harking back
perhaps to Brad Cox’s coinage (or was it Tom Love’s?):
the software IC. Were components the fulfilment of
this promise? Eoin Woods asked what were the steps
that took one from a concept to the corresponding
component(s). Alan Wills saw components as mainly
a middle-tier idea. Francis Glasborrow wanted to emphasize
replaceability. Andy Carmichael repeated the view
that COMPONENTS was a "vendor-led word to help
sell products". John Daniels raised another issue
that merited further discussion; that components meant
a shift to instance level as opposed to class level
reuse. This was not explored in any detail, but it
is obviously an important question that raises inter
alia the debate about the rôle and nature of
class methods in object technology. Alan Wills thought
that fine-grained reuse had failed. He also opined
that components – when viewed as executables rather
than as business objects (back to the middle tier
view!) – enforced a useful discipline during the process
of system modification. Jukka Tamminen made the important
point that a system is more than the sum of its components
and that we viewed them in isolation at our peril.
Frameworks of course emphasize this view.
Richard Drake introduced a new theme, that of the
open source movement. He also exclaimed: "I’ve
been here before". Returning, I think, to the
essence of John Daniels intervention, he wanted us
to consider the value of source code reuse. However,
this proved to be an unpopular view and there was
still no deep discussion of the issue. More controversially
still he thought that a component was something that
could be used by a user via a scripting language.
Alan O’Callaghan made the last contribution, pointing
out that the discussion was not a new one and that
it had been revived by vendors' self-interest. John
Udell pronounced objects as ‘dead’ and componentware
as the future in a Byte feature splashed over its
front cover (May 1994). That was three years before
OT went mainstream by most people's reckoning. The
touted technologies were Microsoft's VBX controls,
OLE 2.0/COM, DEC's ObjectBroker, IBM's SOM, Sun's
OpenStep, Novell's Appware, and OpenDoc. None of these
survives today in its 1994 form, and a few have disappeared
altogether, while OT has gained strength.
As the discussion ran out of time there was general
agreement on the view that the whole idea of components
was no use without solid architecture. A key dichotomy
asked whether it was all about managing complexity
or about issues of delivery and maintenance. There
was no consensus either on whether components were
to be small or large. It was no surprise to me that
the original question posed had not been answered
and that uncertainty had actually increased despite
the relative profundity of the discussion and high
quality of the contributions to it. Perhaps this means
that not only are we, as an industry, uncertain about
what a component is; perhaps we don’t even have a
good, commonly understood notion of object.
complete
solutions for components
(consultancy,
courses, workshops, mentoring, seminars, development)
