Summary: QuA component architecture
Last updated at 3:47 pm UTC on 24 March 2005
Reported by Author
What problem is being addressed
Research into how to support Quality-of-Service (QoS) (e.g., video resolution) in a software component architecture. Because QoS is a cross-cutting concern, that is, QoS may influence design choices across every component of a distributed system, we have had to insist that the component model be powerful enough to model even such things as remote communication protocols as components.
How it solves the problem
QuA component types are a logical abstraction that may be implemented by Squeak objects (for example). When an application requests instantiation of a QuA component type, the QuA platform discovers "plans" for implementing the type, selects one with acceptable QoS, and executes the plan. One common pattern for a plan is a "blueprint" which is an immutable value, corresponding to common definitions of a software component or _module_. Execution of a blueprint plan containing Smalltalk code for a class simply results in a runtime instance of the class object. Another common pattern for a plan is a "factory", such as a Smalltalk class that may be used to manufacture runtime instances of a QuA type.
For more information on the research project: http://www.simula.no:8888/QuA
Prototype code is available at: http://www.simula.no:8888/QuA/136
For coherence I think the author should write the sections above this line.
People can add what they want to these later sections, and can suggest that the author change the rest.
What's cool about it
- Clean distinction between immutable object of code/object distribution "blueprint" and the object(s) created by interpreting that blueprint on a runtime platform.
- Two clients requiring two versions of the same code can coexist! For example, one may bind its reference to "FileSystem" to a class created from the blueprint "/FileSystem:1.1" and another to a class created from the blueprint named "/FileSystem:2.0".
- Component model is concerned with explicit declaration of dependencies required for correct creation of runtime objects. The runtime platform (e.g. a specific version of the Squeak core image and compilation environment) is one explicit dependency. All references to other components (modules, packages or other non-core objects) must be explicit via QuA binding operations.
- QuA notion of "out of image" object references is similar to URIs and to Naiad/Spoon work, but we have not put effort into this aspect.
Its a research project. Our prototype is minimally functional and the architecture is still evolving.
Back to New Modules