Components: myths and reality
- component-ware allows for combining components
if semantical issues can be resolved
- component-ware simplifies software distribution and maintenance
development becomes more complex
- component-ware supports mega applications
it affects performance significantly
- component-ware is a revolution
wrong, it is an evolution from OO and C/S
unknown source
slide: Components: myths and reality
From a market perspective, a successful component-based approach
requires interoperability between components from different
vendors,
and standards with respect to the services components offer.
Such standards are necessary to insulate clients
(i.e. corporations) from vendor-specific, proprietary
solutions.
Clearly, on the technology side,
this surpasses the mere wiring or plumbing standards
that form part of (D)COM, ORBs and JavaRMI.
In addition, suitable component standards are required
for components to interact,
as for example offered by ActiveX, JavaBeans or OpenDoc,
as well as general services, as for example defined by the
OMG, to manage such systems.
Software engineering perspectives
From a software engineering perspective,
we encounter a number of unsolved questions,
as phrased in [Szyperski97]:
- How to describe the interaction between components?
- How to manage variety and flexibility?
- How to guarantee critical system-wide properties?
In addition, we need to deal with the practical aspects
of developing component-oriented applications,
that is master the distributed (object) technology involved,
and manage multi-tier architectures.
And, as indicated in slide [myths],
do not underestimate the complexities
of developing such applications.
Given the failure of many OO projects, as described in [Surviving],
component-oriented solutions which involve client/server aspects
are not likely to be better off, see [CS2001].
Another area that needs to be studied is the performance of
such systems, see for example [CorbaPatterns].
Yet, in conclusion,
just as object orientation may be regarded as
a natural evolution from data-oriented approaches,
we may look at component-oriented approaches
as a natural evolution from object orientation into
the realm of distributed systems.