1. Reflective- Adaptive Middleware
Leila Jalali
Distributed Systems Middleware – ICS 237
Prof. Venkatasubramanian
Fall 2008

2. Outline Motivation Background Key Paradigms Taxonomy Examples
Overview:
Motivation
Motivation
Background
Background
Key Paradigms
Taxonomy
Examples
Key Paradigms
Conclusion
Taxonomy
Examples
Conclusion

3. Motivation Problem Traditional Middleware
Overview:
Problem
complexity of interprocess communication
heterogeneity of platforms
changing conditions
Functional
Environmental
Traditional Middleware
addresses the first two problems to some extent
is limited in supporting adaptation
Reflective and Adaptive Middleware
addresses all three problems
still ongoing research
Motivation
Background
Key Paradigms
Taxonomy
Examples
Conclusion
Developing distributed applications is a difficult task for several reasons.
First, writing code for interprocess communications is tedious and error prone.
Second, supporting multiple interacting platforms is difficult.
Third, adapting to dynamic changing conditions is hard to achieve without the right tools and techniques.

4. Traditional Middleware
Background
Overview:
Traditional Middleware
Middleware Classification by Emmerich [1]
Motivation
Background
Key Paradigms
Taxonomy
Traditional Middleware
Message-Oriented
Middleware
Transactional
Procedural
Object-Oriented
Examples
Conclusion
Object-Oriented Middleware
Java RMI
CORBA
DCOM
Emmerich [8] provides a frequently referenced taxonomy of middleware.
Transactional middleware supports distributed transactions among processes running on distributed hosts.
Message-oriented middleware facilitates asynchronous message exchange between clients and servers using the message-queue programming abstraction.
Procedural middleware extends the procedure call in procedural programming languages to include remote procedure calls (RPC), where the body of the procedure resides on a remote host and can be called the same way as a local procedure.
Finally, object-oriented middleware is based on both the object-oriented programming paradigm and the RPC architecture.

5. Computational Reflection
Overview:
The ability of a program to reason about, and possibly alter, its own behavior
Enables a system to “open up” its implementation details for such analysis without revealing the unnecessary parts or compromising portability.
Terminology
Motivation
Background
Key Paradigms
Reflection
Taxonomy
Examples
Conclusion
Base-level
Meta-level
Reification
MOP
Base Level
Meta Level
Meta Object Protocols
Computational reflection refers to the ability of a program to reason about, and possibly alter, its own behavior.
Reflection enables a system to “open up” its implementation details for such analysis without revealing the unnecessary parts or compromising portability
Relationship between meta-level and base-level objects

6. Why Reflective Middleware?
Overview:
Wireless communication, mobile computing and real-time applications demand
High adaptability
dynamic customization of systems, services and communication protocols
Safe flexibility
constrain composition of services and protocols in order to prevent functional interference that could lead to an inconsistent state of the system
required to protect the system from security threats and failure
Cost-effective QoS guarantees
Motivation
Background
Key Paradigms
Reflection
Taxonomy
Examples
Conclusion
Computational reflection refers to the ability of a program to reason about, and possibly alter, its own behavior.
Reflection enables a system to “open up” its implementation details for such analysis without revealing the unnecessary parts or compromising portability

7. Reflection
Overview:
Provides a plug-and-play environment for enabling run-time modification of policies
An efficient technique to build composable middleware
Features
Separation of concerns
Flexibility, Adaptability
Composition
Implies concurrent execution of multiple resource management policies
Motivation
Background
Key Paradigms
Reflection
Taxonomy
Examples
Conclusion
Computational reflection refers to the ability of a program to reason about, and possibly alter, its own behavior.
Reflection enables a system to “open up” its implementation details for such analysis without revealing the unnecessary parts or compromising portability

8. Reflection & Reification
Overview:
Reflection
Behavioral reflection
Structural reflection
Metaobject protocol
reflection + object-oriented programming
Motivation
Background
Key Paradigms
Reflection
Taxonomy
Examples
Conclusion
Meta-level
Reification
Reflection
Base-level

9. Reification What can you reify?
Overview:
What can you reify?
Structural reflection: the models of your program (MDA), the structure of structured files (e.g. XML DTDs), the classes of a program, the code of a program (AST), the object structures (rarely), the bytecode of a class.
at design-time, compile-time, at load-time, or at runtime.
Behavioral reflection: the object behavior (e.g. when they change states), the interaction between the objects (e.g. when a client invokes a remote object, when an invocation arrives on an object).
at runtime, (design-time, compile time – partial reification).
Motivation
Background
Key Paradigms
Reflection
Taxonomy
Examples
Conclusion

10. Outline Motivation Background Key Paradigms Taxonomy Examples
Overview:
Motivation
Motivation
Background
Background
Key Paradigms
Taxonomy
Examples
Key Paradigms
Big Picture
Conclusion
Taxonomy
Examples
Conclusion

11. Note: an adaptive middleware project may fall in more than one layer.
Middleware Layers
Overview:
Schmidt decomposed middleware into four layers:
Motivation
Background
Key Paradigms
Domain-Services
Tailored to a specific class of distributed applications
Common-Services
Functionality such as fault tolerance, security, load balancing and transactions
Distribution
Programming-language abstraction
Host-Infrastructure
Platform-abstraction
Kernel
Application
Distribution
Common-Services
Host-Infrastructure
Domain-Services
Taxonomy
MW Layers
Adaptation Type
App. Domain
Examples
Middleware Layers
Conclusion
kernel boundary
process boundary
layer boundary
Note: an adaptive middleware project may fall in more than one layer.
Middleware layers [8]

12. Adaptation Type Static Middleware Dynamic Middleware
Overview:
Development Time
Adaptive Middleware
Static Middleware
Customizable
Configurable
Tunable
Mutable
Compile Time
Startup Time
Run Time
Dynamic Middleware
Adaptation Type
Application Lifetime
Motivation
Background
Key Paradigms
Taxonomy
MW Layers
Static Middleware
Customizable Middleware
Enables developers to compile (and link) customized versions of applications.
Configurable Middleware
Enables administrators to configure the middleware after compile time.
Dynamic Middleware
Tunable Middleware
Enables administrators to fine-tune applications during run time.
Mutable Middleware
Enables administrators to dynamically adapt applications at run time.
Adaptation Type
App. Domain
Examples
Conclusion
Note: an adaptive middleware project may provide more that one adaptation.

13. Application Domain QoS-Oriented Middleware Dependable Middleware
Overview:
Adaptive Middleware
Dependable Middleware
QoS-Oriented Middleware
Embedded Middleware
Motivation
Background
Key Paradigms
Taxonomy
QoS-Oriented Middleware
supports real-time and multimedia applications
Example:
video conferencing and Internet telephony
Dependable Middleware
supports critical distributed applications that are required to be correctly operational
military command and control and medical applications
Embedded Middleware
supports small footprints
Examples:
smart phones, hand-held devices, and industrial controllers
MW Layers
Adaptation Type
App. domain
Examples
Conclusion
Our survey of the literature reveals that most adaptive middleware projects support one of these three main application domains:
QoS-oriented systems, dependable systems, and embedded systems.
Figure 7 illustrates our classification of adaptive middleware based on application domains.
QoS-oriented middleware supports real-time and multimedia applications, such as avionics systems, video conferencing and Internet telephony, that are required to meet deadlines and adhere to some QoS contracts, which define the acceptable levels of QoS.
Dependable middleware supports critical distributed applications that are required to be correctly operational, such as military command and control and medical applications.
Embedded middleware supports applications that are required to have small footprints to be able to run on very limited memory devices, including set-top boxes, smart phones, hand-held devices, industrial controllers, and scientific instruments.
Each of the three domains are further refined in the next section, where we describe each of the refinements
and use them to introduce speci¯c adaptive middleware projects. We also discuss where each
project ¯ts with respect to the ¯rst two dimensions of our taxonomy.
Note: there is a lot of overlap among these groups.

14. Outline Motivation Background Key Paradigms Taxonomy Examples
Overview:
Motivation
Motivation
Background
Background
Key Paradigms
Taxonomy
Examples
Key Paradigms
Conclusion
Taxonomy
Examples
Conclusion

15. QoS-Oriented Middleware
Overview:
Motivation
QoS-Oriented Middleware
Stream-Oriented
Middleware
Real-Time
Reflection-Oriented
Aspect-Oriented
Background
Key Paradigms
Taxonomy
Examples
QoS-Oriented
TLAM
Conclusion
Reflection-Oriented Middleware
Computational reflection is the primary focus
Real-time middleware is required to meet the deadlines defined by real-time applications.
In a hard real-time middleware, a failure to meet a deadline may lead to loss of life or property. Life critical military and safety critical civilian distributed real-time systems
are two examples of hard real-time applications. In a soft real-time middleware, however, a failure
to meet a deadline is not as critical as in a hard real-time middleware.
Stream-oriented middleware provides a continuous data streaming abstraction to the multimedia application developers. Video conferencing, Internet telephony, and digital libraries are some examples of multimedia applications.
Reflection-oriented middleware supports QoS-oriented applications using computational reflection as its primary focus. No specific consideration for real-time and stream-oriented applications is provided by this type of middleware.

16. TLAM Core services allow to isolate complex interactions
Overview:
System (Meta) Level
Motivation
Two Level Meta Architecture (TLAM)
Background
Replication
Access
Control
Key Paradigms
DGC
Taxonomy
Migration
Check-
pointing
Examples
QoS-Oriented
TLAM
Remote
Creation
Distributed
Snapshot
Directory
Services
Conclusion
Application (Base) Level
Core services allow to isolate complex interactions
-- useful for managing composition of services

17. Reflective middleware framework – CompOSE|Q
Motivation
Background
QoS
Broker
Key Paradigms
Taxonomy
Request
Mgmt
Data
Mgmt
Examples
QoS-Oriented
TLAM
Conclusion
Data Placement
De-replication
Message
Scheduling
Request
Scheduling
Application
Objects
Clock Sync
Replication
Migration
Core
Services
Remote
Creation
Distributed
Snapshot
Directory
Services
Interaction
with
Core Services

18. Conclusion and Future Work
Overview:
Conclusion
A classification for traditional middleware
Supporting paradigms for reflection
A taxonomy of adaptive middleware
Future Work
Domain-services middleware
Common-services middleware
Embedded middleware
Mutable middleware
Safe adaptation
Higher-level paradigms
Motivation
Background
Key Paradigms
Taxonomy
Examples
Conclusion

19. References Overview: Motivation Background Key Paradigms Taxonomy
[1] Wolfgang Emmerich. Software engineering and middleware: a roadmap. In Proceedings of the Conference on The future of Software engineering, pages , 2000.
[2]
[3] Pattie Maes. Concepts and experiments in computational reflection. In Proceedings of the ACM Conference on Object-Oriented Languages (OOPSLA), December 1987.
[4] G. Kiczales, J. d. Rivieres, and D. G. Bobrow. The Art of Metaobject Protocols. MIT Press, 1991.
[5] Clemens Szyperski. Component Software: Beyond Object-Oriented Programming. Addison-Wesley, 1999.
[6] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements od Reusable Object-Oriented Software. Addison-Wesley Professional Computing Series. Addison-Wesley Publishing Company, New York, NY, 1995.
[7] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Videira Lopes, J. M. Loingtier, and J. Irwin. Aspect-oriented programming. In Proceedings of the European Conference on Object-Oriented Programming (ECOOP). Springer-Verlag LNCS 1241, June 1997.
[8] Douglas C. Schmidt. Middleware for real-time and embedded systems. Communications of the ACM, 45(6), June 2002.
[9] D. C. Schmidt, D. L. Levine, and S. Mungee. The design of the TAO real-time object request broker. Computer Communications, 21(4): , April 1998.
[10] Fabio Kon, Manuel Román, Ping Liu, Jina Mao, Tomonori Yamane, Luiz Claudio Magalhaes, and Roy H. Campbell. Monitoring, security, and dynamic configuration with the dynamicTAO reflective ORB. In Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2000), New York, April 2000.
[11] T. Fitzpatrick, G. Blair, G. Coulson, N. Davies, and P. Robin. Supporting adaptive multimedia applications through open bindings. In Proceedings of International Conference on Congurable Distributed Systems (ICCDS'98), May 1998.
[12] R. Koster. A Middleware Platform for Information Flows. PhD thesis, Department of Computer Science, University of Kaiserslautern, Germany, July 2002.
[13] John A. Zinky, David E. Bakken, and Richard E. Schantz. Architectural support for quality of service for CORBA objects. Theory and Practice of Object Systems, 3(1), 1997.
[14] Nalini Venkatasubramanian, CompOSE|Q – A QoS enabaled Customizable Middleware Framework for Distributed Computing., Distributed Middleware Workshop, Proceedings of the IEEE Intl. Conference on Distributed Computing Systems (ICDCS '99), June 1999.
Overview:
Motivation
Background
Key Paradigms
Taxonomy
Examples
Conclusion

20. Thank you! Overview: Motivation Background Key Paradigms Taxonomy
Examples
Conclusion