Using Binary Packages Like Java Jars?

On Tue, 13 Apr 2004 13:00:29 -0500, "Bill Schwab"
<[hidden email]> wrote:

<snip>

>>  While I agree
>> many smaller developers may not need components,
>
>I would argue almost all.
>

I can tell you from experience that shipping BottomFeeder as a
monolith was a mistake - which is why it now ships as a component
based application.  I do most of the development, with part time help
from a small group of other people.  Having it be monolithic meant not
allowing end user updates easily.

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView

Bill, good points....

> >  it is a
> > development approach that (at least in theory) allows for a higher
> > level of abstraction, modularity, and "pluggable parts".
>
> Not to mention interfaces that don't get changed because it's too much
> trouble, hence we end up living with poor quality and/or performance.  Even
> at their best, the unavoidable boundaries that come with components are an
> impediment to change.

I'd argue that interface "churning" for large-scaled components are
the least of the problems folk will encounter. In fact large-scale
components will realize many interfaces, some of them migratory. Also,
the use of component connectors (a concept started with Catalysis, and
continued with UML2 through ports and protocols) mitigate a lot of
those concerns by enforcing encapsulation from both the supplier and
client ends.

I think many (most?) people think about fine-grained components ala
classes, which is the least effective CBD approach. In fact, the
large-grained components I'm speaking about are composed of many
classes (and files/translation units)

> *If* they have either the vision and luck to get the interfaces right from
> the beginning, or the will and funding to change them several times during
> the project.

A true CBD approach is iterative, and doesn't require you to get
things "right", as you elaborate in subsequent iterations. Further, if
you're reusing harvested components, it helps give you an
architectural framework to work within, so you have contracts you must
adhere to in order to make use of the pluggability aspects of the
component. Definintely one of the strengths of CBD is its espousal of
Design By Contract.
 

> > Additionally, I
> > remember working with a mid-sized telecom company in Ohio that adopted
> > CBD because it helped them manage "families" of billing components
> > that gave them a competitive advantage.
>
> And they could do the same things with shared source code.  Their binaries
> would be a little larger, and their code would probably be better because
> they could stop worrying about which pre-existing apps any given change
> would break, and focus on making the next build better/smaller/faster.

Shared source code is a nightmare. You end up with a combinatorial
explosion of versions, and the enterprise doesn't get the benefit of
localized improvements in any of the applications that are using the
copied source. The company I mentioned actually *started* with source
code sharing, and quickly realized they had dug themselves into a deep
ditch that was difficult to get out of. Migrating to a CBD approach
helped them -- it definitely took managerial support, commitment and
$$$, but in the end, it reduced maintenance $$$, and gave them a
competitive advantage.

Again these components (e.g. "Billing") were large-grained, and were
designed to support the product families of this one company. I agree
that to design something similar for general consumption by the
industry would have been a more difficult task, and most likely not
worth doing.

I guess we've gotten a bit off track from my original post on binary
packages, but I think It's been a good discussion.

Thanks,

KeithB