Layered Component Framework Layered Component FrameworkProblem
Forces
Solution
A newer version will be published soon that includes feedback from a PLoP'00 workshop and discussion on SevenPlusOrMinusTwo as a potential force that makes dealing with architecture or development of frameworks difficult. Either it's coincidence, or a mental issue, that too many moving parts in any given abstraction of an architecture might make it difficult to think of at once. It also turns out that most of these with 9+ layers are very difficult to integrate and/or debug.
An old version of the LayeredComponentFramework pattern can be found in the paper entitled Layering Frameworks in Component-Based Development. See http://www.eskelin.com/patterns/PLoP99/LayeredComponentFramework.pdf
ComponentDesignPatternsContext has a running discussion about the definition of a component. NatPryce pointed out that part of that definition should include component frameworks. Also see ComponentDesignPatternsDiscussion.
Nat, I think you're onto something. At first when you brought up component frameworks, I didn't really see the added value or understand their place in CBD w.r.t. the construction of this pattern language. Now that a few of us have had the discussion you reference above, I see their place. But I'm not clear on a few points you make above, for example when you talk about writing components that coordinate between the different frameworks. Can you elaborate?
To me, you can have frameworks at several levels. For example, the operating system is a framework for COM, COM is a framework for the ActiveX control container framework, and so on. You can take a simple ActiveX control container like Test Container (comes with Visual C++), plop your components into it, set properties, execute methods, log events, etc.
But sometimes you need to do more than the framework does out of the box to make your solution work -- this is where scripting comes in. Therefore, development environments like VisualBasic exist to allow you to write glue code to assemble them and help them coordinate with each other. MS Excel is another off-the-shelf application/framework that allows you to plug in components (e.g. Excel Add-Ins) and perform scripting.
Perhaps the framework plus any scripting code serve as the mediator between its constituent components. If your component is a container itself, then the same is true but at a more cohesive level.
...you talk about writing components that coordinate between the different frameworks. Can you elaborate?
The concept of an "application framework" that provides support for everything your applications might ever need to do never really worked. Instead, I see vendors and researchers writing small frameworks that target specific problem domains -- transport protocol development, database connectivity, user interfaces, media presentation etc. The problems to be solved by a large system span several of these domains, and so several frameworks must be integrated. In order to do so, components in one framework must interact with components in another. However, each framework defines its own interaction protocols meaning that components of one framework cannot be plugged into another. So, components need to be written that bridge between two or more frameworks, interacting with, and mediating between, other components in those frameworks.
Of course, scripting requires a framework of its own, such as ActiveX Automation or the APIs to various scripting languages, such as Tcl/Tk, Python etc.
...you can have frameworks at several levels.
I agree, but I think we need to address layering, and at which layer something becomes a framework. I don't think that COM, for example, is itself a framework. It provides presentation-layer and session-layer services upon which a framework can be defined. Similarly for CORBA. Similarly for the Java JVM. A ComponentFramework is located at the application-layer. (Using the ISO/OSI model again).
However, the presentation-layer & session-layer services are essential for, and orthogonal to, the ComponentFramework. There has to be a well defined way for components to pass invocations to each other. I just can't think of a pithy name for this concept as yet... perhaps CommunicationFramework? or CommunicationSupport??
I hope that clarifies things.
--NatPryce
On an arbitrary project, one could imagine using a GUI framework (ActiveX control container) to plug fine-grained ActiveX controls (list boxes, edit boxes, buttons, etc.), and scripting or programming to implement the intra-framework "glue". Then, one can imagine using a server framework like MTS and MSMQ as an application infrastructure where large-grained MTS objects are integrated. And finally, if you considered (I don't consider it a framework, but that's another discussion) a stored procedure, trigger, index, or view as a component in a relational database framework, then you can imagine that three frameworks all performing intra- and inter-framework communication, collaboration, and coordination exist at each tier in the system.
(For the sake of simplicity, we're not considering external data feeds, reporting, or other external systems that normally afflict <g> solutions.)
For inter-framework design, the framework, the "glue", and/or components all communicate via ConnectionPatterns. ConnectionSingleton conserves connection resources in the GUI. MTS has resource managers that pool database connections via ConnetionFlyweight?. After each tier is connected, CommandPatterns and DataPatterns? can be used to address requests, responses, and persistence.
For intra-framework design, more of an emphasis might be placed on things like ContainerIndependence, ContextIndependence, InterfaceDiscovery, and ThirdPartyBinding. Here, you are focusing on the relationships that these components have with each other. These can also be applied to the inter-framework design, just like CommandPatterns, ConnectionPatterns, and DataPatterns? can be applied within a framework.
I don't think that COM, for example, is itself a framework.
I can see that you're naturally thinking from an OSI/networking viewpoint. I'm thinking from an application development viewpoint. I don't mean to imply that our viewpoints render incompatible themes (in fact I think as we iterate further we will find Known Uses for our patterns in all flavors, shapes, and forms). But I've seen COM being used as the architectural framework upon which whole applications are built. I think I remember you saying the framework itself is a component (ahah, CompositePattern is baa-ack), so if this is true, my point is that it too must plug into a framework.
I'm still struggling to understand where this puts us, and whether ComponentFramework belongs at the higher level along with DistributionOfComponents. --PhilipEskelin
I've been thinking some more and I think component based systems are built as layers of frameworks. At the top layer there are the domain-specific frameworks that application developers use. These are implemented on top of frameworks that provide middleware level services, such as COM and CORBA. These can themselves be implemented on top of lower layer frameworks, such as DougSchmidt's ACE. And one could consider the OS itself to be a framework.
So perhaps LayeredFrameworks is a pattern (one doesn't have to build a framework on top of others but it makes things easier).
Another ProtoPattern is that of "open" layers, or "bypassing" layers. Hiding lower layer frameworks decreases coupling but must entail making assumptions about the needs of higher layers. If it is possible to get access to lower layers in a controlled manner, higher layers can configure lower layers to closely meet their needs. The work on QoS managed operating systems & middleware, and the work on exokernel operating systems, are addressing this problem. --NatPryce
Last weekend I did more research on frameworks. One of the papers I read was Framework Development for Large Systems [3] by DirkBaumer?, et al. They discuss a U-shaped, layered framework model that layers application, business area, and business domain frameworks horizontally while placing the technical and desktop frameworks vertically. The vertical frameworks are used by every layer, and horizontal layers specialize each other as you move upward. Components then use this multi-layer environment as a context with which to build rapid, integrated solutions.
I think this pattern can offer more value to the CBD practitioner if we take the intent (To place component context dependency upon a well-defined component framework.) and make it depend upon well-defined layers of component frameworks. I've always felt that ComponentFramework was only part of the picture. I'll make the switchover and let me know what you think. --PhilipEskelin
Philip and others,
I am having a very hard time to follow your ideas. I think this stems (at least partially) from the fact that a definition for the term framework is missing. After reading this page someone might come to the conclusion that (almost) everything is a framework! -- PeterMaier
Peter,
Thanks for speaking up. You're right. We stumbled upon emphasizing framework while in the midst of defining "component". Now that we've got some good ideas for that, now is the time to start thinking about defining "framework". This is important since the top level of our pattern language seems to be starting with a DistributionOfComponents and LayeredFrameworks. It is imperative that we accurately set the context for these concepts early and at the language level. --PhilipEskelin
I think a special kind of application framework is one upon which other application frameworks have been built. I'd call these application foundations, to distinguish them from the majority of uni-layer application frameworks. It seems a pre-requisite to any truly vertical application that there be an ability to organize the ground floor in a different fashion from the basement, the second floor in a different fashion from the first, etc.. All versions of InterViews (including Fresco) have proven out to have this capability, as well as ET++. It's an open question just what it takes to build an application foundation upon which others can build their application frameworks, but in my experience access to the source code and a good clean initial implementation are paramount. What isn't needed is any sort of absolute feature-completeness or bookstore-ready documentation. That would be like installing marble-tiled washrooms and the concierge in the sub-basement of a five-story, five-star hotel.
I also concur with the essence of the above statements, that component architectures are useful for layering frameworks, and a scripting language is a good mechanism for keeping disparate parts of the growing tower in touch. --ScottJohnston
KyleBrown and I met at Virgil's near Times Square last week. We discusses this very topic over brisket, ribs, and greens. Part of where the context of the language begins (I haven't though of where it comes from yet, for fear of core dump ;-) ) with DistributionOfComponents and LayeredFrameworks. Somewhere in between those is scripting or programming that focuses on integration and assembly of components in one or more layered frameworks.
I keep thinking about COM since most of my fishing stories come from the Microsoft pond (or more accurately, tumultuous ocean). I can integrate, assemble, and develop components using a programming language like C++. One can easily imagine COM as a framework that I use directly, and is used by all the frameworks on top of COM that I use to implement my solution. Multiple frameworks are being used and leveraged in more than one context, and I use ContextIndependence patterns to facilitate low coupling in all the right places.
First, frameworks are always layered when they get big. People manage complexity by breaking big things into collections of small things, so large frameworks get broken into a collection of smaller frameworks, and layering is one of the common ways to combine them.
The interesting question is not whether there are layers, but what the layers are. The thing that makes COM unique is that QueryInterface is put at the very bottom. Other systems provide a way to find out what interfaces an object has, but you are not forced to use them every time you communicate with an object. COM forces you to use QueryInterface before you do anything with an object, so it builds into every system the assumption that the other components might change.
Second, although Active-X is certainly a framework, I would not call COM itself a framework. To me, a framework needs to tell me how to decompose a problem into objects. It needs to describe several interfaces. A single interface like IUnknown is not a framework, no matter how interesting it is.
Check out ComponentFrameworkDefinition. I agree that IUnknown isn't a framework. But, I think COM is a technology framework and a component object model for the ActiveX framework. Then, for example, the ActiveX component framework acts as a generic foundation that allows you to integrate components and use ComponentGlue and potentially additional frameworks to compose a generic business framework. A business framework is specialized into the enterprise solution. It may or may not be component-based, and one or more of these layers may be absent. Regardless of the kind of framework, the context, forces, and complexity of the problem govern the degree to which layering should occur in an architecture. --PhilipEskelin
Earlier, on another page, NatPryce said that components must have a framework. My initial reaction was to disagree. I have COM servers which really do not depend upon anything other than COM. Then I saw that he was counting things like COM as frameworks. I kept quiet because I tend to like more expansive definitions of "framework." At this point, when we are talking about layering, I wonder whether we can nail down a good definition of framework. I've seen many. Here are list of qualities I've seen attributed to frameworks:
I've done two things with the hope that it helps clear things up: I've started a new format for the LayeredFrameworks ProtoPattern, and have created ComponentFrameworkDefinition. --PhilipEskelin
This discussion has been moved from within the pattern itself...
"Adapters are needed to mediate between components in different frameworks that talk using different protocols. ComponentGlue can be used to integrate frameworks."
Nat, is this a specialization of MediatorPattern in the context of a given framework? --PhilipEskelin
I don't think so. MediatorPattern and AdapterPattern can both be used to integrate application-independant frameworks and application-specific behaviour. ComponentGlue is a form of AdapterPattern or BridgePattern, but the real intent is the ease of adaption, rather than the adaption itself. LayeredFrameworks aim to simplify framework design, rather than integrate frameworks; the need for integration is the resulting context. Personally I prefer not to have a Mediator linking frameworks because placing all the adaption into one object makes it complex and cumbersome. If you follow the route of separating and simplifying Mediators, you end up with lots of small Adapters -- ComponentGlue. --NatPryce
I was thinking about the MediatorPattern inside the context of a single framework. I agree that having a mediator control layering would defeat the purpose because each framework layer would need to communication up and down via mediation, which increases coupling and reduces autonomy.
However, I think mediation is a more natural pattern to use when dealing with component collaboration and communication in a framework like ActiveX containment. For example, in VB, when you draw forms and plug components into them, VB extends the ActiveX framework with scripting. ComponentGlue is used to react to events and implement collaboration, communication, and coordination between each of the components in the form. When thinking about interframework communication, I agree that the AdapterPattern is more applicable. --PhilipEskelin
Perhaps. I still prefer small bits of ComponentGlue to a large Mediator, even within a framework. If you use ThirdPartyBinding, the ComponentGlue gets set up in one place, so it's still easy to maintain, and you don't have a cumbersome Mediator class to deal with.
Mediators are often one-off objects. A good principle someone told me about was to never create a class for an object that is only instantiated once. In "classical" OO languages you often cannot avoid it; I guess it's an easier principle to follow in prototype-based OO languages like Self and NewtonScript.
--NatPryce
[BTW, Good idea moving the discussion down here!]
I am using the word "mediator" not so much in the classical OO design pattern sense where you have a one-off mediator object (or several if you design something that resembles the BureaucracyPattern?), but more specifically in the sense of the ComponentGlue playing the role of mediator. In the position I have above, I think ComponentGlue essentially specializes the Visual Basic virtual machine by playing the mediator role between components. In an applicable context, this can be complemented by adapting components and/or lower-level frameworks. That's layering, and I suppose we will eventually capture it here in LayeredFrameworks.
How about Excel as a different example. It can be used as:
I've not really been very active here of late, but something that's been occupying my thoughts were the references we made to Containers on the ContainerManagedPersistence page and whether Containers have a place on this page. Reading through the EJB specs and various white papers it appears to me that the word Container is used in reference to the Framework layer directly beneath a Component. EJB specifies that it's the Container Vendors responsibility to provide certain services to the component, and beneath this "Container" is the EJB Server which provides the rest of the Framework. Unfortunately there is no current standards for Containers, so early EJB Servers are also performing the role of Containers. Is there any scope here for identifying a Container as an element of the Pattern Language?
Anybody else got thoughts on this?
ContainerIndependence is a ProtoPattern related to containers, but is in a different part of the language than ContainerManagedPersistence. Perhaps the resulting context of LayeredFrameworks could refer to both of them. It sounds like the EJB guys think of a container as a type of framework that is akin to ComponentFramework. --PhilipEskelin
At the Micromodeling dicsussion in early December '98 (see ComponentDesignPatternsHistory), we covered this pattern. There was question as to what a framework was, and whether or not COM was a framework. The group felt one key part of the solution was that in LayeredFrameworks you abstract as you get higher. Your intent is to make it easier for the programmer to his job faster and more efficiently. One way people started classifying types of frameworks was binary, language, and domain frameworks. Finally, a few asked if LayeredFrameworks really captured the intent and goals of the pattern. --PhilipEskelin
Just wanted to let folks know that the above link to the PDF document represents the latest Alexander-ized version of the Layered Component Frameworks pattern. I still think it needs work, so any comments would be greatly appreciated. Specifically, I think more can be discussed about how a layered architecture applies and how higher-level layers should use lower-level layers through interfaces, thereby reducing coupling. --PhilipEskelin
Can these components be Just Patterns (patterns as the building blocks of the framework). --SeshKumar
This page mirrored in ComponentDesignPatterns as of April 29, 2006