distributed systems architecture

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: 

• 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 (CBD).
• 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.

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.

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 bandwidth.

• If there would be too much communication between units, consider:
• would a redeployment be OK?
• whether to split a component across deployment units;
• whether to replicate some information or functionality between DUs
• If so, consider how to keep the replicated information in sync, and how often it should be sunc (?)
• whether to introduce mobile components that can move to where they're needed.
• Tend to disbelieve your guestimates about performance; make measurements.

Consider continuity of service

• 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, splitting, replication.

Consider openness.

• 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 problem.

Consider existing architecture (if there is one). 

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)