how do you do it?
In a closed system, the central issue is that of deployment: the question
of which pieces of hardware run which pieces of software.
It's useful to separate two issues here:
Notice that DUs are not components. A deployment unit will typically run
several components; a component class may appear in many deployment units.
Typical DUs include: DLLs; EJB containers; the program execution environment
provided by a traditional operating system; the sandbox provided by a web
browser for a Java applet.
How the overall job(s) of the whole distributed system should be divided
up into functional units of software (which we'll call components): this
is the skill of component based design
How those components should be distributed between the execution contexts
(which we'll call deployment units — DUs): this is the issue we deal
with here. This distribution will form the basis for your enterprise blueprint.
Let's assume you are designing a system made up of some number of
deployment units; as distinct from an open network, in which you don't
have much control over the contents and purpose of the individual DUs.
Follow these steps:
Partition the system into components.
Variable features of whole system behaviour → components
Major use-cases → components
Distribute components between deployment units (DUs)
Consider modifying the basic design patterns to take into account distribution,
minimising the need to communicate between DUs
Consider continuity of service
If there would be too much communication between units, consider:
Tend to disbelieve your guestimates about performance; make measurements.
If it is required that some DUs continue to function to some extent when
the others are down, consider whether your current plan provides for this.
If not, consider the same options as under the Bandwidth heading: redeployment,
Consider existing architecture (if there is one).
The DUs you have today won't be the only ones in the future. You need to
be able to add new DUs, and modify existing ones, without changes propagating
through the whole system. If you've started from a good component design,
with clear separation of concerns, then this shouldn't be too much of a
Work out how you are going to migrate stepwise from any existing deployment
scheme to the one you've just worked out; make compromises if necessary;
plan for never actually getting all the way there.
complete solutions for e-business
(consultancy, courses, workshops, mentoring, seminars, development)