Middleware: State of the Art and Challenges Ahead

1
Middleware State of the Art and Challenges Ahead

• Changing environment
• Enterprise application integration formerly
  independent applications must interaction to
  access and share functions and data store in
  heterogeneous DB
• Internet applications
• The number of users may fluctuate and be
  unpredictable
• A stateful user session ins harder to maintain
• Interacting parties belong to independent
  autonomous organizations that do not necessarily
  trust each other insecure medium
• Communication infrastructure does not provide QoS
  guarantees
• Open environment, need common ontologies
• New application interoperate seamlessly with
  legacy applications
• QoS
• Nomadic mobility
• Ubiquitous computing

2
Middleware State of the Art and Challenges Ahead

• Programming models
• Client-Server???
• Asynchronous interaction
• Shared memory
• Mobile code and mobile agents
• Architecture
• Distribution transparency ???
• Layering ???
• Monolithic architectures (no adaptation,
  customization)
• Dynamic Configuration
• Disconnected operation
• Adaptive applications
• Ad hoc organization
• intermediaries

3
Middleware State of the Art and Challenges Ahead

• Middleware
• Shield software developers from low-level details
• Amortize software lifecycle, providing reusable
  framework
• Provide a consistent set of higher-level
  network-oriented abstractions
• Provide a wide array of reusable services
• Layered structure of middleware
• Host infrastructure middleware
• Distribution middleware
• Common middleware services
• Domain-specific middleware services
• Domain-specific middleware services

4
Host infrastructure middleware

• Encapsulates and enhances native OS communication
  and concurrency mechanisms to create reusable
  network programming components.
• Java Virtual Machine
• .Net
• ACE

5
Distribution Middleware

• Enable clients to program distributed application
  much like stand-alone applications by invoking
  operation son target objects without hard-coding
  dependencies of their location, programming
  language, OS platform,
• CORBA
• RMI
• DCOM
• SOAP

6
Common Middleware Services

• Augment distribution middleware by defining
  higher-level domain-independent services that
  allow application developers to concentrate on
  programming business logic, without the need to
  write the plumbing code required to develop
  distributed applications by using lower-level
  middleware
• CORBA common object services, event notification,
  transaction, etc.,
• J2EE
• .Net Web Service

7
Domain-Specific Middleware Services

• Service targeted at vertical markets, such as
  telecom, e-commerce, healthcare
• The Siemens Medical Engineering Group Syngo
• The Boeing Bold Stroke architecture uses COTS
  hardware and middleware to produce a
  non-proprietary, standards-based component
  architecture for military avionic mission
  computing capabilities

8
Areas of Focus

• Growing focus on integration rather than on
  programming
• Next generation applications will increasingly be
  assembled by modeling, integrating, and scripting
  domain-specific and common service components,
  rather than by being programmed either entirely
  from scratch or requiring significant
  customization or augmentation to off-the-shelf
  component implementations.
• Increased viability of open systems architectures
  and open-source availability
• Standard interfaces
• Increased leverage for disruptive technologies
  leading to increased global competition
• Growing focus on real-time embedded environments
  integrating computational and real world physical
  assets

9
Research Challenges and Strategies

• Cause of complexity
• Discrete platforms must be scaled to provide
  seamless end-to-end solutions
• Components are heterogeneous yet they need to be
  integrated seamlessly
• Most failures are only partial in that they
  effect subsets of the distributed components
• Operating environments and configurations are
  dynamically changing
• large-scale systems must operate continuously,
  even during upgrades
• End-to-end properties must be satisfied in time
  and resource constrained environments
• Maintaining system-wide QoS concerns is expected

10
Quality Object (QuO)

• The QuO architecture decouples DOC middleware and
  applications along the following two dimensions
• Functional path
• Flows of information between client and remote
  server applications.
• The middleware ensures that this information is
  exchanged efficiently, etc.
• Information is largely application-specific and
  determined by the functionality being provided.
• QoS attribute path
• Responsible for determining how well the
  functional interactions behave end-to-end with
  respect to key distributed system QoS properties
• The middleware is responsible for collecting,
  organizing, and disseminating QoS-related
  meta-information that is needed to monitor and
  manage how well the functional interaction occur,
  and enable the adaptive and reflective
  decision-making needed to support QoS attribute
  properties in the face of rapidly changing
  environmental conditions.

11
Systems of Systems

• Desired properties
• Predictability, controllability, and adaptability
  of operating characteristics for applications
  with respect to such features as time, quantity
  of information, accuracy, confidence, and
  synchronization.

12
Specific RD Challenges

• Providing end-to-end QoS support, not just
  component-level QoS
• Adaptive and reflective solutions that handle
  both variability and control
• Adaptive middleware is software whose functional
  and QoS-related properties can be modified either
  statically, or dynamically
• Reflective middleware permits automated
  examination of the capabilities it offers and
  permits automated adjustment to optimize those
  capabilities.
• Reflective middleware supports more advanced
  adaptive behavior and more dynamic strategies
  keyed to current circumstances, ie.., necessary
  adaptations can be performed autonomously based
  on conditions within the system, in the systems
  environment or in system QoS policies defined by
  end-user

13
Specific RD Challenges

• Combining model-integrated computing with DOC
  middleware
• Toward more universal use of standard middleware
• Leveraging and extending the installed base

14
Fundamental Research Concepts

• Contracts and adaptive meta-programming
• Graceful degradation
• Multiple behaviors are both feasible and
  desirable
• Feedback loops so that the application services
  can degrade gracefully as condition change
• Prioritization and physical world constrained
  load invariant performance
• Higher level design approaches, abstractions, and
  software development tools

15
Promising Research Strategies

• Individual QoS requirements
• Translation of requests for service among and
  between the various entities on the distributed
  end-to-end path
• Managing the definition and selection of
  appropriate applicati0n functionality and system
  resource tradeoffs with a fuzzy environment and
  
• Maintaining the appropriate behavior under
  composability
• Runtime requirements
• Addresses the need for run-time monitoring,
  feedback and transition mechanisms to change
  application and system behavior, e.e., through
  dynamic reconfiguration, orchestrating degraded
  behavior or even off-line recompilation.

16
Promising Research Strategies

• Aggregate Requirements
• Addresses the system view of collecting necessary
  information over the set of resources across the
  system and providing resource management
  mechanisms and policies that are aligned with the
  goals of the system as a whole.
• Reservations
• Admission control mechanisms
• Enforcement mechanism with appropriate scale,
  granularity and performance
• Coordinated strategies and policies to allocate
  distributed resources that optimize various
  properties
• Integration Requirements
• Address the need to develop interfaces with key
  building blocks used for system construction,
  including the OS, network management, etc..

17
Promising Research Strategies

• Adaptivity requirements
• Changes beneath the applications to continue to
  meet the required service levels despite changes
  in resource availability
• Changes at the application level to either react
  to currently available levels of service or
  request new ones under changed circumstances
• System Engineering Methodologies and Tools
• View-oriented or aspect-oriented programming
  techniques to support the isolation and the
  composition
• Design time tools and model-integrated computing
  technologies to assist system developers in
  understanding their designs
• Interactive tuning tools to overcome the
  challenges associated with the need for
  individual pieces of the system to work together
  in a seamless manner
• Composability tools to analyze resulting QoS from
  combining two or more individual components
• Modeling tools for developing system performance
  model
• Debugging tools

18
Promising Research Strategies

• Adaptivity requirements
• Changes beneath the applications to continue to
  meet the required service levels despite changes
  in resource availability
• Changes at the application level to either react
  to currently available levels of service or
  request new ones under changed circumstances
• System Engineering Methodologies and Tools
• View-oriented or aspect-oriented programming
  techniques to support the isolation and the
  composition
• Design time tools and model-integrated computing
  technologies to assist system developers in
  understanding their designs
• Interactive tuning tools to overcome the
  challenges associated with the need for
  individual pieces of the system to work together
  in a seamless manner
• Composability tools to analyze resulting QoS from
  combining two or more individual components
• Modeling tools for developing system performance
  model
• Debugging tools