Software Framework

Here are some types of software frameworks:

Technology Framework: Provides a standard, generic software foundation; not necessarily limited to ComponentBasedDevelopment; examples are COM, CORBA, Java. Also known as System Infrastructure or Middleware Frameworks.
Object-Oriented Framework: Consists of a set of classes that work together to solve a family of related problems. Programmers can use inheritance and delegation to extend the framework. Examples are RogueWave Tools.h++, Model-View Controller, Microsoft Foundation Classes.
Component Framework: See ComponentFramework, ComponentFrameworkDefinition, or BlackBoxFramework.
Business Framework: Provides a domain-specific, business solution that can be extended into an organization; not necessarily limited to ComponentBasedDevelopment; examples: SAP R3, John Doe's Order Processing Framework, Janna Systems' Janna Contact Enterprise, Siebold, Baan Company's BaanSeries?. Also known as an Enterprise Framework.

How do component and OO frameworks compare? There can be a lot of overlap. In many cases, component frameworks are implemented in the context of an OO language and one or several layered OO frameworks. Also, the party extending the framework from an abstract design solution into a concrete one may also be programming in an OO environment.

But since component frameworks are BlackBoxFrameworks? that define a set of AbstractInteractions with components that communicate with it, they are not limited to an OO context and can be implemented in object-based or non-object-oriented languages.

Also, another place we see people raising the level of abstraction at this level of reuse is in taking OO frameworks and layering component frameworks on top of them. This can allow for more flexibility since interface is separated from implementation.

--PhilipEskelin

An article appeared in the Jan. 1999 C++ Report by DougSchmidt that calls the business framework an Enterprise Framework that "...address vertical application domains, such as avionics mission computing, call processing, ..."

In addition, he defines both System Infrastructure and Middleware frameworks, which seem to fall under Technology Framework defined above.

--PhilipEskelin

I'd like to quote a bit more from DougSchmidt's aforementioned "How to make Software Reuse Work for You" article in the Jan'99 C++ Report. I think it is relevant here, as well as to ComponentDefinition and ComponentFrameworkDefinition:

: An effective pattern I've seen applied repeatedly to organize a common software architecture is to use (1) *frameworks* in the horizontal middleware platform layers and (2) *components* in the vertical application layers. Components are self-contained instances of abstract data types (ADTs) that can be plugged together to form complete applications. Common examples of components include ActiveX controls and CORBA Object Services.
: The relationship between frameworks and components is highly synergistic, with neither subordinate to the other. Frameworks can be used to develop components, whereby component interfaces provide Facades for internal class structures inside a framework. Moreover, components can be used as "pluggable strategies" within a framework.
: Compared with frameworks, components are less tightly coupled and can support binary-level reuse more readily. For example, application developers can reuse components without having to subclass from existing base classes. Im my experience, applications are generally more comfortable and successful programming with components than they are customizing frameworks. However, frameworks are useful for middleware teams because the help to simplify the development of horizontal platform software. Naturally, components are also useful for developing infrastructure and middleware as well.

In the above, Doug has not only described a pattern, he has provided a definition of "component", and compared and contrasted components with frameworks and elaborated upon their interrelationships. As for developers being more comfortable using components than customizing frameworks, I suspect it is because the AbstractInteractions that comprise the "virtual engine" hard-coded in the framework imposes a specific conceptual orientation.

Developers are often more comfortable adapting code to work in their own conceptual world instead of having to make the conceptual leap necessary to make their code cooperate within the micro-world imposed by the framework. The framework may provide more of a technological "push" model, doing more things for you, while the component is more of a "pull" model, making you do more of your own coding using ComponentGlue; but conceptually speaking the same push-vs-pull contrast work against developer familiarity/comfort: The component lets the developer stay in their own conceptual orientation while the framework pushes the developer into the conceptual world of the interaction memes and metaphors of the workframe provided by the framework. (Hmm, Im starting to lose myself, Im not sure if that last bit makes sense) --BradAppleton

It does make sense ... I am flying at the same altitude you are ;-). Physically, I think components and component frameworks can be identical, however IndividualPackaging applies better to loosely-coupled components and GroupPackaging applies better to more strongly-coupled component frameworks. And I like Doug's "pluggable strategies" term -- it's the way I think about components that are plugged into component frameworks.

As an example, I think programmers find it easier to start with Visual Basic and a bunch of GUI components than starting out with a higher-level business framework for the reasons you mention above. It is easier for them to conceptually chunk at a finer level than they're required to if they're reusing a big horizontal (horizontal across the domain in question) business framework. However the drawback is that by escaping the initial learning curve, they only delay the pain until later, when they've got a juggernaut, complicated fat VB client that has too much business logic in it, and requirements keep popping up as they learn more about the domain in question as they code it.

If you follow the rules and organizational principles in Doug's articles, and you understand the domain very well and are working with a highly-skilled team of developers and architects, then you can abstract the programmer from many of the complexities of the domain's requirements. So reuse occurs at a much higher level of granularity, and there is an initial learning curve, but the ROI payoff can be a very high if the cost of the framework is far lower than giving programmers who may not be familiar with the domain the responsibility of doing it themselves.

Now above I'm focusing on component frameworks, where Doug was focusing more on SoftwareFrameworks? in general. I'm doing this because I believe, from the context of CBD, a component framework that is built as a business framework that provides the programmer with an abstract design solution they extend into the organization has and results in many patterns in the ComponentDesignPatterns language (I hope ;-).

--PhilipEskelin

[CategoryFramework]