The QuA architecture:
A general component middleware
supporting QoS-sensitive applications
Background, goals
and relationship to e-Science/Grid
http://www.simula.no:8888/QuA
Partners
• Simula Research Laboratory, Oslo, Norway
• SINTEF, Oslo, Norway
• University of Tromsø, Tromsø, Norway
• Supported by a 4 year grant from the Research
Council of Norway
2
Background and problem
• Component architectures make it easier for developers
to build reliable distributed applications from reusable
software components.
• Safe deployment property of component architecture:
– The guarantee that components may be reused in any
application requiring the declared functionality.
– The application will function correctly when deployed on any
sufficiently provisioned implementation of the component
architecture
• The current de facto standards, EJB 2.0 and .NET, and
standards like CCM, do not support safe deployment of
QoS-sensitive applications (QSAs).
3
Limitations of current standards
• Platform services are closed, cannot be extended, and
may be grossly inefficient for specialized applications like
streaming continuous media.
• Real-time constraints are not communicated and can
receive no guarantee
• Tolerance for imprecision or other data losses is not
communicated and cannot be traded for better real-time
performance
- Hide knowledge of component location and platform
heterogeneity: information that is needed to configure
QSA components
4
Research goals
• Primary goal
– Develop, prototype and experimentally evaluate a
component architecture that supports safe deployment of
QoS-sensitive applications (platform will make intelligent
use of resources to achieve best QoS)
• Secondary goals
– Release software
– Simplify development of QoS-aware applications
– Influence standards like UML, CCM and OGSA
• Research methods:
– Reference architecture prototyping
– Evaluation by porting application from Grid computing and
mobile computing.
5
Main hypothesis: Platfom managed QoS
• We believe is the only general solution that preserves
the safe deployment property
• An application developer specifies only logical
properties:
– The type of computational components in a service
– The logical bindings between components
– QoS requirements
• The platform is responsible for all implementation
choices affecting QoS
6
Questions we hope to answer
- How can QoS management services be implemented with
reusable components?
- How are QoS requirements communicated via standard
platform APIs?
- How can the platform discover implementation alternatives
for a component type or binding, resource requirements for
an implementation, resource availability and scheduling
alternatives, anticipated QoS for an implementation?
- How can the platform optimally plan a service
implementation, automatically deploy software
components, instantiate and bind application objects,
monitor QoS and detect the need for adaptation or
reconfiguration, be invoked for dynamic adaptation and
reconfiguration?
7
Relationship to e-Science/Grid
• Grid is part of our workplan
– Management and trading of global computing resources.
– Evaluation of QuA architecture by porting application from
Grid computing to QuA
– How well does the architecture support Grid computing?
• Does it succeed in reducing the complexity of developing Grid
applications?
– How can we influence a standard like OGSA?
– What are e-Science application requirements for QoS?
– What QoS sensitive e-Science applications could be suitable
for porting to the QuA platform?
8
Contacts
• Richard Staehli {richard@simula.no}
Frank Eliassen {frank@simula.no}
http://www.simula.no
• Anders Andersen{anders@cs.uit.no}
Gordon Blair {gordon@comp.lancs.ac.uk}
http://www.cs.uit.no
• Jan Øyvind Aagedal {jan.aagedal@sintef.no}
http://www.informatics.sintef.no
9