| |
Component based development is about creating flexible families
of end-products from kits of inter-compatible components. But how does
one pull off this feat of architecture? Where do the components come from?
What must you do to ensure you get the advertised benefits? If you are
in the hot seat labelled 'architect', what should you do?
It must be recognised that CBD does not mean aquiring parts from everywhere:
they are unlikely to be compatible without a great deal of glue. Instead,
components must be designed to work together, and for a particular domain
or business: interoperability standards for components must be agreed
within a project, company, or industry. These standards involve much more
than interconnection and container technology such as CORBA or EJB: the
components talk to each other about Accounts, Customers, Targets, Calls,
or whatever, and must speak a common language. Nor is this just a question
of defining a common data model 9for example in XML): the different components
must have some common notion (even if partial) of what the constraints
on the objects of their communications are, what operations can be performed
on them, and what the effects of the operations are --- in other words
some semantics. All these definitions are part of the architecture on which
a kit of components is based.
A distinction between the tasks of product builder, component designer,
and component kit (= product line) architecture must be made. These tasks
require different skills and degrees of ceremony.
How to partition work between components is a common problem. Separation
of concerns is the initial and key rule. Variable features should, ideally,
map to separate components, decoupled with a well-defined interface. An
open type system must be maintained for the communication links. After
that (particularly in a distributed component system), bandwidth and continuity
of service must be considered, with the important tactics being caching,
replication and splitting; the need to consider how and how often cached
or replicated information will be synchronised follows. A useful guide
is to map large-scale use-cases onto components.
It's a feature of component based designs that different software end-products
can be made by 'rewiring': substituting one component for another, or rearranging
the configurations of the components. Such a kit is also open: you should
be able to extend the functionality achievable in the end-products by designing
more components. (If all the end-products have the same set of 'components',
they're not components at all: they're merely modules!) The same
principles apply to both large and small components, whether they are user
interface widgets or accountancy subsystems.
Once you have worked out your ideal architecture, a migration plan must
be generated about how (if ever) you're going to get there from the current
situation; and how you are going to find out what the latter really is.
complete solutions to create model and component-based architectures
(consultancy, courses, workshops, mentoring, seminars, development)
|
