Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Summary: QuA component architecture
Last updated at 3:47 pm UTC on 24 March 2005
Reported by Author
Richard Staehli

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.

Useful links

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

What's not

Its a research project. Our prototype is minimally functional and the architecture is still evolving.

Commentary


Back to New Modules