component architecture basics
the building language
In some senses, the architecture defines a language in which the variants of the product family may be expressed.
For example, if your domain of expertise is hotel billing systems and you have many hotel customers,
there will be a lot of parameters and variations between the needs of one client and another.
You can invent a set of components that plug together in various ways to meet all their needs;
and in a sense, each ocnfiguration is a statement in a language about hotel billing. In fact,
you can make this idea quite concrete, by inventing a small language in which to notate the
variations in hotel billing, and design a compiler that, given a description in the language,
assembles the components in the right way. You could even make it a pictorial language.
Workflow systems work this way.
the interface language
A separate language is the one the components use to talk to each other. To make the
components able to adopt many configurations (like the ones in the picture below),
it's essential to have a common set of interface definitions -- significantly fewer than there are components.
In simple components at the Java Beans level, the language is elementary: this
event has happened, this property has been changed. In more complex business
components, the language is about events in the domain: Customer X has made an
Order for 10 Widgets, etc.
So the interface language definition consists of two parts:
the protocol of transactions that components can perform with each other —
'event occurred', 'order cancelled', etc; and the details of the messages used to implement them;
the model of what they're talking to each other about — Customers, Orders, etc.
(Notice that the important objects here are not the components themselves, but the business concepts they deal with).
In defining the model, it isn't usually sufficient to make a data model:
you need to say something about the operations that can be done on the
business objects, the sequences of operations that are allowed, and the
constraints on values their attributes may take. Different components may
have different internal representions of the concepts, so the model should
ideally be independent of any implementation — just saying what the
effects of operations are, rather than what they achieve.
The architecture should define how components and products
will be tested, and provide some quality control support —
usually in the form of test harnesses that check conformance to the architecture.
complete solutions for model-based architecture
(consultancy, courses, workshops, mentoring, seminars, development)