Motivating a Team

1
- the knowledge cluster on QoS-aware, adaptable
component middleware architectures
Frank Eliassen, cluster leader
2
Goals

• investigate how to develop complex quality of
  service (QoS) sensitive distributed applications
  on a component architecture middleware platform
• learn through experimentation how dynamic QoS
  management and adaptation can be supported in
  general-purpose component middleware
  architectures

3
What is a distributed system?

• Definition Coulouris 2001
• a distributed system consists of hardware and
  software components located at networked
  computers that communicate and coordinate their
  actions only by passing messages.
• Challenges of engineering distributed systems
• Mananging complexity
• Partial failures, unreliable communiction,
  security, concurrency,
• Managing heterogenity
• Hardware, Operating systems, Programming
  languages

4
Quality of Service (QoS)

• What is QoS?
• QoS for distributed applications and services
  refers to their extra-functional properties, such
  as the provided response time, bandwidth,
  privacy, safety, accuracy, media-quality (for
  continuous media).
• What is QoS management?
• The planned allocation and scheduling of network
  and end-system resources and software algorithms
  to meet the QoS needs of applications.
• Static QoS management
• Dynamic QoS management

5
Why QoS?

• Increasing demand for quality of service
  guarantees in networking and distributed
  applications
• Telephony
• TV- and radio like applications
• Video-conferencing
• Distance education
• Surveillance control systems (real time
  systems)
• Cooperative work over distance
• Interactive large scale simulations (grid
  computing)
• Telemedicine
• Convergence requires QoS

6
What is middleware?

• Classical view Bakken, 2001
• Defined as a software layer above the operating
  system (and transport layer) but below the
  applications
• Enable interaction across a network
• Offers common (generally useful) services

7
The goal of middleware

• Provide distribution transparency via programming
  abstractions that hide the complexity of the
  underlying network and simplifies the task of the
  application developer

Distributed applicationes and services
Distributed tuples Remote procedure call Message
queues Distributed services Distributed objects
Platform Independent API
DISTRIBUTION MIDDLEWARE
OS Dependent APIs
Comm. Processing Storage
OS n
OS 1
. . .
OS 2
8
Object-based distribution middleware

• Most dominating form of middleware in the 90s
• Offers the abstraction that methods of a remote
  object can be invoked as if the object is located
  in the same addresse space as the caller
  (location- and access transparency)
• Makes avaialable to developers of distributed
  applications all advantages of object-oriented
  software engineering techniques encapsulation,
  inheritance, and polymorphism
• CORBA, Java RMI, DCOM

9
The emergence of component middleware

• To address some known problems with object-baserd
  middleware as CORBA and Java RMI
• How do I deploy my application?
• What services will be available on a given
  host?
• Who will activate my objects?
• Who will manage the life-cycle of my objects?
• To enable the construction of distributed
  applications by composition of reusable
  software-components
• Standards and proprietary technologies
• EJB/J2EE, CCM, .NET/COM

10
Component middleware

• A standard development, deployment and runtime
  environment for software components
• Realized as a component platform
• The component platform defines the rules for
  deployment, composition and activation of
  components

11
Reuse of components
12
The promise of component architectures

• 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).
• A component of the correct type will perform
  unacceptably if its internal implementation
  assumptions do not match the deployment
  environment and application QoS requirements

13
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
• QoS aware model transformation
• Platform managed QoS
• Influence standards like UML, CORBA and GLOBUS
• Research methods
• Reference architecture prototyping
• Evaluation by porting application from Grid,
  multimedia and mobile computing.

14
Some adopted principles

• Open-reflective extensible architecture
• A closed middleware platform cannot provide
  services optimized for every application
• Component-based middleware
• Middleware platform and services are built from
  components
• Everything is a service
• Uniform model from application level to system
  level services
• Formal definition of QoS
• Platform managed QoS

15
Principles of open-reflective extensible
architecture

• The middleware provides an open-reflective
  implementation
• The middleware can inspect its own implementation
  through a self-representation model
• Changes to the self-representation model is
  reflected to the implementation itself
• Configurable middleware
• Component-based middleware platform allows for
  configuration of middleware services according to
  application needs
• Re-configurable middleware
• Enable adaptation to changing operating
  environment (such as in mobile computing)
• Change behaviour of existing components
• Add new components, change components, ...

16
Principles of platform managed QoS

• An application developer specifies only logical
  properties
• The type of computational components in a service
  
• The logical bindings between components
• QoS requirements
• During service instantiation the platform is
  responsible for all implementation choices
  affecting QoS
• To execute this task, the QuA platform invokes an
  appropriate implementation planner associated
  with the requesting threads service context
• The implementation planner discovers alternative
  component implementations and configuration
  alternatives that make assumptions about the
  deployment environment and selects the one with
  the highest client utility

17
(No Transcript)
18
Status

• Infrastructure for experimentation (Squeak, and
  Java implementations of the QuA core)
• Java reference implementation
• Platform Independent Architecture Specification
  of QuA (UML)
• Code available as open source
• Experiments on service planning of audio and
  video bindings
• Current focus and research challenges (and topic
  areas in which master project proposals normally
  will be offered)
• Demonstrating service planning and implementation
  plans in the chosen domains (mobile computing,
  multimedia and Grid computing)
• Incorporating the details of dynamic
  reconfiguration (service replanning) into QuA
• produce UML based QoS-aware model transformers
  towards the QuA platform

19
Project members

• PhD students
• Arnor Solberg, SINTEF
• Sten Amundsen, Simula
• Sharath Musunoori, Simula
• Arne Munch-Ellingsen, UTromsø
• Eli Gjørven, Simula
• Master students Oslo
• Eivind Mork
• Øyvind Matheson Wergeland
• Per Ivar Sugar
• Espen Abrahamsen
• Tore Engvig
• Astrid Elise Magistad
• Kim Bredesen
• Alexander Bai
• Johannes Oudenstad

• Academic staff
• Frank Eliassen, Simula
• Ketil Lund, Simula
• Mourad Alia, Simula
• Viktor S. Wold Eide, Simula
• Jan Øyvind Aagedal, SINTEF
• Anders Andersen, UTromsø
• Gordon Blair, Lancaster/Simula
• Dave Bakken, WSU/Simula

20
QuA Master thesis project proposals

• Titles
• Distributed Garbage Collection
• Grid Scheduling
• Grid Monitoring
• Code generation towards the QuA platform
• Validation of Strategic Management Decisions
• Technology for a persistent versioned network
  repository for QuA component blueprints
• Technology for peer-to-peer resource discovery
  (implementation broker)
• SOAP binding type for QuA
• Pub/Sub binding type for QuA
• QuA performance studies
• For details see QuA project web
• http//www.simula.no8888/QuA/112