Component Design Patterns Guidelines

[ComponentDesignPatterns | ComponentDesignPatternsContext]

Overview

Many projects today use a component-based approach to developing software. ComponentBasedDevelopment stresses language and platform interoperability and separation of interface from implementation. Existing and newly constructed components are used on clients and servers to build flexible, reusable solutions.

Component software is usually built in the context of different scripting and programming environments used on different platforms with different frameworks. Sometimes the application spans many machines and components are distributed across platforms. The purpose of this pattern language is to capture some of the recurring themes and best practices in CBD that lead to winning software projects.

Scope

The ComponentDesignPatterns language covers component-based development for domestic (not distributed) and foreign (distributed) application solutions.

Currently, the technology set that is being used as a base for the varying pragmatic experiences and themes covered in this language are based on Microsoft, Sun Microsystems, and OMG technologies, tools, and products.

Some of the recent projects that the authors have experienced that followed certain themes covered in this pattern language are:

• Regent framework and tools the development of component-based concurrent and distributed systems
• A project building a distributed client coverage system for a global investment bank
• A project building a distributed options-trading system
• A project building a distributed manufacturing control system for a Japanese auto manufacturer
• IBM WebSphere -related projects

Most pragmatic things falling under ComponentBasedDevelopment are within the scope of this language. Since the industry has varying definitions of a component, see ComponentDefinition our definition of component.

What is not in the scope is some of the very interesting research and bleeding-edge work being done in distributed systems that is not frequently being used to develop solutions in the industry. For instance, research in the area of eliminating the distinction between local and distributed computing by raising the level of machine abstraction is highly interesting, but not practical at this point (early 1999) in our industry.

For a more granular approach to understanding the scope of this language, see the Context and Applicability for the language and for each pattern.

Organization

If you take the language as a whole, you can see it much like a pattern, in that we are defining the elements of the overall pattern language in CanonicalForm (also known as CoplienForm). Like a pattern, the language has a name, problem, context, forces, solution containing sturcture, participants, and collaborations, a resulting context, related pattern languages, and known uses. We are defining the following elements:

• ComponentDesignPatternsContext
• ComponentDesignPatternsProblem
• ComponentDesignPatternsForces
• ComponentDesignPatternsSolution

When you have a feel for the big picture, you can look at the language from different taxonomies. One approach to the language is to look at it from the role point of view. CautiousBuyOverBuild is a high-level decision-oriented pattern that leads to the following depending on your decision with respect to the requirements of your solution:

ComponentAssemblerPatterns?

• DistributionOfComponents
• DeploymentPatterns?
  • IndividualPackaging
  • GroupPackaging
• ThirdPartyBinding
• ComponentGlue
• UsagePreconditions

ComponentDeveloperPatterns?

• CookbookApproach
• AbstractInteractions
• ThirdPartyBinding
• AutomatedAssembly
• DataPatterns
  • ContainerManagedPersistence
  • ComponentManagedPersistence
• CommandPatterns
  • InterruptibleCommand
  • AcidCommand
  • ConcurrentCommands
• ConnectionPatterns
  • ConnectionSingleton
  • ConnectionFlyweight
  • ConnectionObserver?
• SplitDesignTimeAndRunTime

These roles are not mutually exclusive, and are perhaps played by a single person, but this classification can help you determine some of the themes that center around on role.

Status

This project is a work-in-progress. See ComponentDesignPatternsHistory for more information about what's happened since its inception.

There are a few dozen "patterns" that have emerged through this project. Some are directly applicable, some are ideas that may or may not survive, and some were hatched from this project but ended up being outside the context but related to CBD.

One big question we have right now is: how do we classify this thing? Criticism has been received that it's confusing to look at a list of 20 patterns and understand how they relate to each other when there's no taxonomy. Above, as we flesh more of this out, the Organization section should reflect our answer to this question.