Component Framework Definition
Component Framework DefinitionLet this be the place in WikiWiki where we discuss the definition of ComponentFramework in today's fast-moving world of ComponentBasedDevelopment. Other places to look for additional background is SoftwareFramework, ComponentDefinition, and BlackBoxFramework.
I look forward to group contribution. I agree different folks have different ideas and/or experiences with frameworks. Arriving at a common definition for ComponentFramework will help set a better context for ComponentDesignPatterns. And utility is a key factor. What kinds of things do you feel we could add to make it more useful? -- PhilipEskelin
It is much harder to come up with a "good" definition than to complain about an existing one... The thing that I immediately feel to be important is a comparison/contrast to object-oriented frameworks.
Agreed. I'm already starting to question whether it's right to classify frameworks into the above three areas (as examples). But that's the beauty of making mistakes - you learn from them. Still, I agree that a good OO framework contrast will help.
I've been thinking about this distinction between an OO framework and a component framework. I think one difference is that an OO framework has an "inverted" flow of control. That is, the application hands control over to the the framework after populating it with objects. The framework implements much of the system functionality and then calls back to the objects created by the application when application-specific actions are required. Brad Appleton has termed this the Hollywood Principle ("don't call us, we'll call you!").
I didn't coin the "Hollywood Principle." I don't know who did, but folks like DesmondDeSouza were using it before I was. I think I coined the "Greyhound Principle" (leave the driving to us ;-)
In contrast, components typically interact as peers. That is, the flow of control may start at one or more components and flow through others. Flow of control does not, usually, magically appear at a component from within the framework. How control and data flow between components is defined by interaction protocols that specify how components can interact. The component framework itself is involved with instantiating components and connecting them into legal configurations rather than performing the work of the application - it leaves that to the components selected by the developer.
To link this with the patterns... a ComponentFramework is defined as a set of AbstractInteractions set up by ThirdPartyBinding, and is fleshed out with ComponentGlue and AutomatedAssembly functions to make it easier to use.
Suppose we start off more from a dictionary-meaning which tries to loosely relate to software. Webster gives some definitions like:
Brad, in the paper I'm writing called Layering Frameworks in Component-Based Development, I have a section called "What is a Component Framework?" There, I describe something similar to your and Nat's comments. Here is the URL to a work-in-progress temporarily located version of my paper:
http://www.geocities.com/WallStreet/Exchange/7621/LayeringFrameworks.pdf
I contrast two types of software frameworks: object-oriented frameworks and component frameworks. Both offer large-scale reuse. The contrast is that OO frameworks contain abstract classes, and component frameworks contain abstract interactions. Also, control flows in opposite directions, as Nat describes above and in ComponentFramework. And, I'm hoping that Nat's distillation of comments from here and in ComponentDefinition can be played into the paper as well.
Phil, I like the paper. I worry that it may look like it makes OO Frameworks out to always be separate from and incompatible with ComponentFrameworks? (and vice-versa). Is it not possible to realize a component framework with objects or an OO framework with components (especially when sometime an object is also a component, or vice versa)? Some see components as "mostly" the interfaces and their specs and interactions, and they see objects as the component implementations (or at least one possible implementation of a component that takes advantage of some O-O benefits). Where might this fit in?
The intent of the paper is to show that a natural trend in technology is to raise the level of abstraction, that components and component frameworks with other frameworks are a part of this raising process, and that a layering frameworks can be a powerful kind of reuse. Tackling the way classes and components relate in daily practice would help a lot as opposed to just thinking about their contrast. But before I continue, I want to harvest a good ComponentDefinition into the CDP language and be clear about how it distinguishes between components and classes.
Regarding how some view components and how it fits into the paper, I too think it's a good thing to address. If I understand right, your point is that in the section What is a Component?, the paper should move beyond just C++-assembled and C++-developed components and tackle the binary-level and interaction protocol versatility aspect that might/might not include OO technology. It would reinforce that when trying to structure a new framework to simplify the architecture of a solution, raising the level of abstraction by developing a ComponentFramework introduce forces that lead to a solution including layering it above lower-level frameworks.
Gush!
Right now my premise is that components and component frameworks in conjunction with other developments in technology play an important role in raising the level of abstraction and making it easier for the programmer. Driving forces are economic and machine performance & capacity-driven. An important attribute of CBD is that the component assembler is abstracted from the details of implementation ("Who knows what the component's programmed in, I just use it by conforming to its interface specification or by discovering it through reflection or introspection at runtime") which leads to the fact that the programmer doesn't have direct control over or access to structural and behavioral aspects implementation specifics and must instead rely upon a physical packaging of logical components that provide interfaces as their means of abstract interaction. A result of this might perhaps be a pattern that involves something like OpenSource to make assembly (the general form of reuse) and maintenance (a specialized form of reuse) easier as well.
I re-read ComponentFramework and ComponentFrameworkDefinition to try and better understand the distinction between a component framework and an object(-oriented) framework. It seems to me if you ignore boundaries of source and binary, of locally and remotely developed code, the inverted-control distinction doesn't hold up. Either the threads of control are running in a procedural fashion through objects/components (non-inverted), or they're waiting for a new event to dispatch (inverted) - a distinction between different parts of an entire applications' code, not a fundamental difference in frameworks.
So perhaps the difference is really in the eye of the beholder (in one's conceptual orientation anyway).
What does make sense to me is the requirement for ThirdPartyBinding for it to be called a ComponentFramework. This then, in turn, requires a whole set of things, like InterfaceDiscovery, ComponentGlue, etc.. Which leads me to my next question - is dynamic linking required for a ComponentFramework?
Not necessarily. If you SplitDesignTimeAndRunTime, you can use ThirdPartyBinding when implementing, but statically link components into the final executable. This approach is used in the Koala component system that Phillips developed to build embedded software for consumer electronic devices, such as televisions. By statically linking components, Koala can reduce the foot-print and performance overhead of the resultant software.
For more information see:
Rob van Ommering, Koala, a Component Model for Consumer Electronics Product Software, in Development and Evolution of Software Architectures for Product Families, Lecture Notes in Computer Science 1429, Springer-Verlag, 1998. ISSN 0302-9743.
After reading a detailed description of JavaBeans from a reference manual, it dawned on me that the goal of that environment, and perhaps similar component programming environments like ActiveX, is a reproduction of the power and flexibility of the LispMachine, by reimplementing the InterfaceDiscovery and component packaging mechanisms of Lisp. It made me wonder if ComponentVirtualMachine? would be more self-explanatory to a wider audience than ComponentFramework. No-one would deny that component programming as discussed here requires some sort of virtual machine, would they?
A components is deployed as an independent binary package in the physical sense. It either runs in its own process, or can attach to an existing one. As one component in the physical sense, it can provide access to one or more components in the logical sense that were designed as a way to name a set of interfaces defined a black box interaction protocol with its implementation. OCX files and JAR files are examples of physical packaging that realize one or more components that realize one or more interfaces.
A component framework is also a set of AbstractInteractions that define an interaction protocol. But don't components do this too? After all, many ComponentFrameworks? exist in one binary component, and contain a set of interfaces that define a protocol for using and extending it. What's the difference between a component and a component framework?
Both are black box in nature, but one difference is that component frameworks can provide AutomatedAssembly or ThirdPartyBinding or the opportunity to use ComponentGlue to tie components together, and can allow you to BypassAbstractions? for access to lower-layer frameworks if and when requirements aren't fully met. As Nat says, bypassing the BlackBoxFramework allows you to get at lower-layer WhiteBoxFrameworks?.
What about a component framework packaged and deployed as several components or one big component? Perhaps different patterns can apply depending on how you make this decision. But from the design perspective, you are typically abstracted from knowing the details of packaging, and different patterns can apply depending on where the component is instantiated (e.g., in-process, local, or remote).
As the group converges on these definitions, I'm starting to see that ComponentFramework is a special kind of component. I think new patterns for both design (of AbstractInteractions) and deployment (of physical packages) have the potential to emerge.
In a sense, I agree with the above. But let me suggest one more thing. Why bother to redefine "framework" at all? After all this discussion, I find it simplest to think of framework as having pretty much the same implications, whether we're talking about components or objects. There was no need to redefine "design pattern" for CBD, and people have worked hard on defining frameworks relative to design patterns, so why not just reuse these terms as is? Once you have a ComponentDefinition you can move on to their implications for patterns, frameworks, compilers, interpreters, virtual machines without having to redefine each one. -- ScottJohnston
Scott, I am sensitive to your concern as it is definitely not my goal to overcomplicate this pattern language with new or altered definitions. After all, the language is all about things that already exist, so it would go against the grain to do that.
Using your argument, we redefined framework when we coined the term OO framework and business framework too. I don't think we're redefining it, we're just classifying software frameworks to understand how they relate to each other. With classifications it helps us layer them. For example, my gut tells me I wouldn't put a low-level technology framework like the OSI networking stack above a business framework, or implement COM on top of MFC (gawd what a nightmare that would be). By coming to grips with a component framework, we're honing in on a type of BlackBoxFramework that consists of components and also glues them together. As far as I can see, contrasts between that and traditionally white-box frameworks and lower-level and higher-level frameworks are evident, and new concrete patterns arise from component frameworks specifically.
One major difference I see is that in CBD, the user of a component is completely decoupled from its implementation. If I'm using C++ and I have an abstract class I'm using to interact with a component, my dependency goes as far as the interface, and I am not aware of specific state, behavior, or the programming language the developer used to develop the component (or whether the concept of an object even exists for that matter). With OO white-box frameworks, I'm highly coupled to its implementation, and I must essentially understand the framework's structure and behavior to utilize it. And with many black box frameworks that allow me to interact via abstract classes for example, I'm still coupled to implementation (for example the realization of objects throughout the system, for example).
These are the things that come to my mind right now regarding how a ComponentFramework is both a specialized component and a kind of special framework. I'm sure there are additional attributes that will eventually arise in the evolution of ComponentDesignPatterns.
Regarding duplicating design patterns, that's not what we want to do either. One thing I have noticed is that some of our patterns are decision-oriented (e.g., CautiousBuyOverBuild) and some are design-oriented (e.g., ContainerManagedPersistence). Perhaps others are process- or architecture-oriented. I think ComponentBasedDevelopment includes all of these, and some are very relevant to a project using a CBD approach.
Phil, I've been using framework pretty much as defined in the original Design Patterns book, so I don't look at OO framework as a redefinition of that term. I think terms like "technology" or "business" are adjectives to characterize the best use of a framework, or describe different layers of a framework. But I'll admit that "component" as defined here implies a little more when concatenated to "framework" (as does "application"). Feel free to refactor my comments. Interesting to see that the discussion has arrived at underlining the black-box nature of a component. But that is a whole 'nother topic...
The DesignPatterns definition of framework seems to define an OO framework, not a software framework or a more generic conceptual structure or skeleton. Here's the definition, pulled from page 26 of DesignPatterns:
Pretend that a C++ framework for yield curve instruments was developed with GnuCpp under Sun Solaris. It works great for years. Then suddenly out of the blue, everybody in the firm has Windows NT desktops. Traders want to reuse it in Excel in conjunction with real-time market updates, and programmers want to reuse it in Visual Basic and Visual C++.
If we port it to Windows NT, we're constrained to reusing it in Visual C++. But how about that ComponentBasedDevelopment thing? A decision is made to port the code to NT and raise the level of abstraction by decoupling the programmer from its implementation. We use the LayeredFrameworks pattern to layer in-process COM objects accessible by all three development environments (and more) above the ported C++ framework.
AbstractInteractions between components are defined by codifying abstract interfaces. We implement ProtocolTunneling through the IDispatch interface to support access to Visual Basic and Excel. At the end of the day, binary independence and the black box nature of our components allowed us to make it easier to reuse at a larger scale than before.
So, to me, when I hear adjectives like technology, business, object-oriented, or component, I envision their location in layers. I don't envision all of them referring to viewpoints into one big framework. People have a tendency to decompose bigger complex problems into smaller problems and solve them through a design that includes collaboration and interaction amongst these smaller elements to solve the bigger problem.
Vertically, LayeredFrameworks reduce complexity and allow the programmer to bypass abstractions as needed, and you narrow in on the application domain as you work your way up. Horizontally, at the level of a component framework, you break things up by partitioning it into components and interfaces. In both directions, nothing stops folks at any level from coding examples of DesignPatterns into their frameworks and components.
So in short, I think OO and component frameworks exist hand in hand. Nobody said they were orthogonal or mutually exclusive. In fact, OO frameworks and patterns are very important to the whole of CBD. I'm exhausted - glad you keep arguing this because it's making me think more. But I'm almost out of air ;-).
So to me, when I hear adjectives like technology, business, object-oriented, or component I envision their location in layers.
Phil, I have no problem with this point. I'm a believer in layers myself, a publisher of a sizeable suite of code composed of plain OO frameworks, application frameworks both generic and specialized, and even a scripted component manipulation layer (but not black-box componentry as defined here). I thought with my last post I was agreeing with you in that there was a worthwhile distinction, in a software architecture sense, between plain OO frameworks, collections of software like ACE from DougSchmidt that give you a starting point for derivation, and OO frameworks that provide some sort of partially closed, unifying architecture, i.e. application frameworks and component frameworks as discussed here. But of course they all can be layers in any given system. I'm glad you've found my comments thought-provoking and useful.
Thanks again, Scott. If I'm understanding you right, you're saying that a ComponentFramework is just a kind of OO framework. I agree with that to a certain extent, especially if the user of the component framework is coding in an object-oriented language such as C++ or Java. But if they aren't, then many of the OO concepts don't apply. So that's probably the key point - that a component framework is black box and while it can be used and implemented in the context of object-oriented programming, it is not limited to that since the user and implementor are completely decoupled from each other.
EditText of this page
(last edited September 28, 2009)
or FindPage with title or text search