ACT Adaptive CORBA Toolkit: Integrating Adaptive Middleware Techniques

1
ACTAdaptive CORBA ToolkitIntegrating Adaptive
Middleware Techniques
SeyedMasoud Sadjadi Advisor Dr. Philip K.
McKinley Software Engineering and Networking
Systems Laboratory Department of Computer Science
and Engineering Michigan State University www.cse.
msu.edu/sens
2
Motivation

• Obsevations
• There is no one complete solution to adaptive
  middleware
• Each adaptive middleware approach has some
  advantages and shortcoming comparing to other
  approaches.
• For each application, a customized solution seems
  to work better than a general solution.
• Goals
• Promoting Code Reuse
• So many existing applications and third party
  components.
• Adaptive code are tangled in the business code
  and is not reusable
• Providing Unanticipated (Dynamic) Adaptation
• Target apps distributed applications including
  mobile, embedded, real-time, .
• Supporting heterogeneous devices
• Supporting dynamic changes of the context

3
Our Solution

• Integration of the best aspects of different
  adaptive middleware techniques depending on the
  application.

4
Acknowledgement

• OMG (CORBA)
• BBN Technology (QuO)
• IONA (ORBacus, Orbix)
• Freie Universität Berlin and Xtradyne
  Technologies AG. (JacORB)
• DOC Group (ACE, TAO, CIAO, ZEN, TAO LoadBalancer)
• UIUC Researchers (DynamicTAO, LegORB, UIC)
• Distributed Multimedia Research Group, Lancaster
  University (Open ORB)
• University of Rome La Sapienza (IRL)

5
Agenda

• Background
• Introducing Adaptive Middleware Approaches
• Categorizing Each Approach in the Middleware
  Layers
• Evaluating Each Approach
• Introducing ACT
• Current Status of ACT
• Concluding Remarks and Future Work

6
Background

• Object-Oriented Computational Model
• An application is represented by interactions
  among a web of objects.

Voice Amplifier Application
Service provided through interface
Service is accessed through a reference
Thread
Main Loop
7
Background (cont.)

• Evaluation
• Transparency
• Not transparent.
• Performance
• Can be very high.
• Interoperability
• Can be interoperable
• HTTP, FTP, .
• Generality of supported adaptations
• Tangled adaptive code.
• No code reuse for business and systematic
  behavior.
• Ad hoc dynamic adaptation.

• Distributed Object Computational Model
• Objects are distributed on a network

Client
Server
Application Layer
Socket
Socket
File
Shared Memory
Pipeline
File
Shared Memory
Pipeline
Operating System Layer
Network
8
Background (cont.)

• Evaluation
• Transparency
• Hardware, Network, OS.
• Language heterogeneity
• Performance
• Depends on the ORB implementation.
• Interoperability
• Interoperable with CORBA compliant.
• Generality of supported adaptations
• Application specific adaptive code is still
  tangled with the business code.
• ORB code is reused.
• Ad hoc dynamic adaptation.

• Middleware
• Offers a higher level of programming abstraction.

Client
Server
Application Layer
Proxy
Skeleton
Middleware Layer
ORB
ORB
Operating System Layer
Socket
Socket
File
Shared Memory
Pipeline
File
Shared Memory
Pipeline
Network
9
Adaptive Distribution Middleware

• Examples are TAO, CIAO, ZEN, DynamicTAO, LegORB,
  UIC, OpenORB, JacORB, ORBacus, and ORBix.

Client
Server
Application Layer
Proxy
Skeleton
ORB
ORB
ZEN
UIC
Distribution Middleware Layer
ORBix
CIAO
LegORB
JacORB
ORBacus
TAO
DynamicTAO
OpenORB
Socket
Socket
Network
File
Shared Memory
Pipeline
File
Shared Memory
Pipeline
10
Adaptive Distribution Middleware

• Examples are TAO, CIAO, ZEN, DynamicTAO, LegORB,
  UIC, OpenORB, JacORB, ORBacus, and ORBix.

• ORB Generations
• Static Monolithic ORB
• Monolothic ORB with Compile-Time Configurable
  Flags
• Dynamic Micro-ORB
• Dynamic Reflective Micro-ORB
• Static Reflective Micro-ORB

TAO
11
Adaptive Distribution Middleware

Micro-ORB vs. Monolithic-ORB

• Examples are TAO, CIAO, ZEN, DynamicTAO, LegORB,
  UIC, OpenORB, JacORB, ORBacus, and ORBix.

• Context
• Implementing full-service can yield a
  monolithic-ORB with large footprint
• Problem
• Embedded Systems often have severe memory
  limitations

• Solution
• Micro-Kernel pattern
• Virtual Component Pattern
• Identify core ORB services whose behavior may
  vary
• Move each core ORB service out of the ORB

ZEN
Monolithic-ORB Architecture ZEN
Micro-ORB Architecture ZEN
12
Virtual Component Configurator Pattern
Adaptive Distribution Middleware

• Examples are TAO, CIAO, ZEN, DynamicTAO, LegORB,
  UIC, OpenORB, JacORB, ORBacus, and ORBix.

• Intent
• to factor out components that may not be needed
• Solution
• Use abstract interfaces for all components
• Upon component-fault load concrete
  implementations using
• Factory Method
• Proxy
• Component Configurator

Eager Static Loading Strategy
Eager Dynamic Loading Strategy
ZEN
Virtual Component Static Structure
Lazy Dynamic Loading Strategy
13
Adaptive Distribution Middleware

• Examples are TAO, CIAO, ZEN, DynamicTAO, LegORB,
  UIC, OpenORB, JacORB, ORBacus, and ORBix.

DynamicTAO
14
Adaptive Distribution Middleware

• Examples are TAO, CIAO, ZEN, DynamicTAO, LegORB,
  UIC, OpenORB, JacORB, ORBacus, and ORBix.

UIC
15
Adaptive Host Infrastructure Middleware

• Evaluation
• Transparency
• Hardware, Network, and OS transparency for
  distribution ORB.
• Performance
• Depends on the middleware implementation.
• Interoperability
• Provides more interoperability.
• Generality of supported adaptations
• Application specific adaptive code is still
  tangled with the business code.
• ORB code is reused.
• Ad hoc dynamic adaptation.

• Examples are MetaSockets, ACE, and Rocks

Client
Server
Application Layer
Proxy
Skeleton
Distribution Middleware Layer
ORB
ORB
ORBacus
ORBix
TAO
CIAO
ZEN
DynamicTAO
UIC
OpenORB
JacORB
Meta- Sockets
Meta- Sockets
Host Infrastructure Middleware Layer
ACE
Rocks
ACE
Rocks
Socket
Socket
File
Shared Memory
Pipeline
File
Shared Memory
Pipeline
Network
16
Adaptive Host Infrastructure Middleware

• Examples are MetaSockets, ACE, and Rocks

Meta- Sockets
17
Adaptive Host Infrastructure Middleware

• Examples are MetaSockets, ACE, and Rocks

ACE
18

• Evaluation
• Transparency
• Provides transparent services to the application
  if used in combination with portable
  interceptors.
• Performance
• Degrading the performance because of forwarding.
• May have better overall performance, because of
  adaptation it offers.
• Interoperability
• Can be designed CORBA compliant.
• Generality of supported adaptations
• Some of the application specific adaptive code
  can be moved to this common middleware layer
  (limited).
• Business code can be reused.
• Adaptation code can be reused
• Can be used for systematic dynamic adaptation.

Adaptive Common Middleware

• Examples are IRL, FTS, TAO LB, Eternal, Immune,
  and Realize.

Client
Server
Application Layer
Eternal
Immune
Realize
TAO LB
FTS
IRL
Common Layer
Proxy
Skeleton
Distribution Layer
ORB
ORB
ORBacus
ORBix
TAO
CIAO
ZEN
DynamicTAO
UIC
OpenORB
JacORB
Host Layer
MetaSockets
MetaSockets
ACE
Rocks
ACE
Rocks
Network
Socket
Socket
File
Shared Memory
Pipeline
File
Shared Memory
Pipeline
19
Adaptive Common Middleware

• Examples are IRL, FTS, TAO LB, Eternal, Immune,
  and Realize.

20
Adaptive Common Middleware

• Examples are IRL, FTS, TAO LB, Eternal, Immune,
  and Realize.

Eternal
21
Adaptive Common Middleware

• Examples are IRL, FTS, TAO LB, Eternal, Immune,
  and Realize.

IRL
22

• Evaluation
• Transparency
• Not transparent to the application.
• Can be transparent if used with portable
  interceptors
• Performance
• Have better performance if not used with
  interceptors.
• Degrading the performance because of forwarding.
• May have better overall performance, because of
  adaptation it offers.
• Interoperability
• Can be designed CORBA compliant.
• Generality of supported adaptations
• Most of the application specific adaptive code
  can be moved to this domain specific middleware
  layer.
• Business code can be reused.
• Adaptation code can be reused
• Can be used for systematic dynamic adaptation.

Adaptive Domain Specific Middleware

• Examples are QuO and ACT.

Client
Server
Application Layer
Domain Layer
Smart Proxies
Delegates
Adapters
Callbacks
Delegates
Adapters
Callbacks
QuO Kernel
ACT Kernel
QuO Kernel
ACT Kernel
Common Layer
Eternal
Immune
Realize
TAO LB
FTS
IRL
Proxy
Skeleton
Distribution Layer
ORB
ORB
ORBacus
ORBix
TAO
CIAO
ZEN
DynamicTAO
UIC
OpenORB
JacORB
Host Layer
MetaSockets
MetaSockets
ACE
Rocks
ACE
Rocks
Network
Socket
Socket
File
Shared Memory
Pipeline
File
Shared Memory
Pipeline
23
Adaptive Domain Specific Middleware

• Smart Proxies.

Client
Server
Application Layer
Domain Layer
Smart Proxy
Common Layer
Proxy
Skeleton
Distribution Layer
ORB
ORB
Host Layer
Network
24
Adaptive Domain Specific Middleware

• QuO.

Client
Server
Application Layer
Domain Layer
Adapters
Callbacks
Adapters
Callbacks
Delegate
Delegate
QuO Kernel
QuO Kernel
Common Layer
Proxy
Distribution Layer
Skeleton
ORB
ORB
Host Layer
Network
25
Adaptive Domain Specific Middleware

• ACT Overview.

Client
Server
Application Layer
Domain Layer
Adapters
Callbacks
Adapters
Callbacks
Delegate
Delegate
ACT Kernel
ACT Kernel
Common Layer
Proxy
Distribution Layer
Skeleton
ORB
ORB
Host Layer
Network
26
Adaptive Domain Specific Middleware
Example of adding a rule dynamically Rule rule
new Rule(1, RuleType.SEND_REQUEST,
"com.bbn.quo.examples.bette.interceptor.
DynamicConditionAction.TargetIsServerSlideService
_Condition", "com.bbn.quo.examples.bette.interc
eptor.DynamicConditionAction.
ForwardRequest2SlideService_ClientLocalProxy_Acti
on") try ruleBase.insertRule(rule)
catch(Exception e) e.printStackTrace()
System.exit(1)
public class GenericRequestInterceptor extends
LocalObject implements ClientRequestIntercepto
r, ServerRequestInterceptor,
RequestInterceptorRunTimeRegistererOperations
private Object loadAndInstantiateRequestInter
ceptor( String className) Object
retObject null try Class c
Class.forName(className) Class partypes
new Class1 partypes0
org.omg.CORBA.ORB.class Constructor ct
c.getConstructor(partypes) Object
arglist new Object1 arglist0
orb retObject ct.newInstance(arglist)
catch(Exception e) e.printStackTrace()
System.exit(1) return retObject
public class GenericRequestInterceptor extends
LocalObject implements ClientRequestIntercepto
r, ServerRequestInterceptor,
RequestInterceptorRunTimeRegistererOperations
private void processClientRequestInterceptors(
ClientRequestInfo ri, int interceptionPoint)
throws ForwardRequest Set keys
clientRequestInterceptors.keySet() Iterator
iter keys.iterator() while(iter.hasNext())
Object key iter.next()
ClientRequestInterceptor clientReqInt
(ClientRequestInterceptor)(clientRequestIntercepto
rs.get(key)) switch(interceptionPoint)
case SEND_REQUEST clientReqInt.send_req
uest(ri) break case SEND_POLL
clientReqInt.send_poll(ri) break case
RECEIVE_REPLY clientReqInt.receive_reply(ri)
break case RECEIVE_EXCEPTION
case RECEIVE_OTHER clientReqInt.receive_other(ri)
break
public class RuleBaseClientRequestInterceptor
extends LocalObject implements
ClientRequestInterceptor public void
send_request(ClientRequestInfo ri) throws
ForwardRequest if(!setRuleBase(ri))
return try ruleBase.processRules(RuleType.SE
ND_REQUEST, ri) catch(ForwardRequest fr)
throw fr catch(Exception e)
public void send_poll(ClientRequestInfo ri)
public void receive_reply(ClientRequestInfo
ri) public void receive_exception(ClientRe
questInfo ri) throws ForwardRequest
public void receive_other(ClientRequestInfo ri)
throws
public class RuleBase implements
RuleManagementOperations public void
processRules( RuleType ruleType,
org.omg.PortableInterceptor.RequestInfo reqInfo)
throws org.omg.CORBA.UserException
Iterator iterator activeRules.keySet().iterator(
) while(iterator.hasNext())
java.lang.Object key iterator.next()
ActiveRule activeRule (ActiveRule)(activeRules.g
et(key)) if(activeRule.ruleType
ruleType) if(activeRule.condition.
check(reqInfo)) // may throw
a UserException. activeRule.action.proce
ss(reqInfo)

• ACT details.

public class GenericRequestInterceptor extends
LocalObject implements ClientRequestIntercepto
r, ServerRequestInterceptor,
RequestInterceptorRunTimeRegistererOperations
public void send_request(ClientRequestInfo
ri) throws ForwardRequest
processClientRequestInterceptors(ri,
SEND_REQUEST) public void
send_poll(ClientRequestInfo ri) public
void receive_reply(ClientRequestInfo ri)
public void receive_exception(ClientRequestInfo
ri) throws ForwardRequest public
void receive_other(ClientRequestInfo ri)
throws ForwardRequest
public class GenericRequestInterceptor extends
LocalObject implements ClientRequestIntercepto
r, ServerRequestInterceptor,
RequestInterceptorRunTimeRegistererOperations
public void registerClientRequestInterceptor(S
tring cri) throws AlreadyRegisteredException
ClientRequestInterceptor clientRequestInterc
eptor (ClientRequestInterceptor)
(loadAndInstantiateRequestInterceptor(cri))
clientRequestInterceptors.put(cri,
clientRequestInterceptor) public void
registerServerRequestInterceptor(String sri)
throws AlreadyRegisteredException
ServerRequestInterceptor serverRequestInterceptor
(ServerRequestInterceptor)
(loadAndInstantiateRequestInterceptor(sri))
serverRequestInterceptors.put(sri,
serverRequestInterceptor)
Client
Server
Application Layer
Domain Layer
Common Layer
Proxy
Distribution Layer
Skeleton
ORB
ORB
Host Layer
Network
27
Adaptive Domain Specific Middleware

• ACT details.

Client
Server
Application Layer
Domain Layer
Adapters
Callbacks
Adapters
Callbacks
Delegate
Delegate
ACT Kernel
ACT Kernel
Common Layer
Proxy
Distribution Layer
Skeleton
ORB
ORB
Host Layer
Network
28
ACT Kernel
Observer code sample in CDL contract Diagnose
( syscond quoValueSC quo_scValueSCImpl
userLatencyThreshold, //msec syscond
quoDataSC quo_dataDataSCImpl
expectedNetworkCapacity,//kbps syscond
quoDataSC quo_dataDataSCImpl
expectedServerLoadAverage //num ) syscond
probe instr_scPropertyProbe
measuredNetworkCapacity("network_Capacity",
100.0) //kbps syscond probe
instr_scPropertyProbe measuredNetworkPropDelay(
"network_PropDelay", 50.0) //msecs .
Decision Maker (DM)
Decision Maker sample in CDL contract Diagnose
() region Normal ( (measuredAverageTotalLate
ncy lt userLatencyThreshold thresholdFactor)
and (Not useInstrumentation )) region
Faster // The measured latency faster
than half the // expected latency
region Slower . region Expected (true)
region Instrumented (true) region
ObjectSlow region NetworkSlow
region UnknownBottleneck (true) .
Responder sample code in CDL contract Diagnose
() transition any-gtObjectSlow
synchronous instrumentationConverged.reset(-
11) processingFactor.longValue(100)
thresholdFactor.doubleValue(0.05)
transition ObjectSlow-gtany transition
any-gtNetworkSlow transition
NetworkSlow-gtany transition
any-gtUnknownBottleneck transition
UnknownBottleneck-gtany .
Observer
Responder
ACT Kernel
Event Mediator
29
ACT Delegate
Delegate sample code in ASL behavior Diagnose
() qosket slideDiagnoseDelegateQosket
qk void slideSlideShowread(in long
gifNumber, out string size, out
octetArray buf) inplaceof METHODCALL
region Instrumented region
ObjectSlow iServer.readBig(gifNumb
er, size, buf, holder)
region NetworkSlow iServer.readSmallProcessed(g
ifNumber, size, buf, holder)
.
getStatus()
FP
get()
put()
Fltr
Delegate
put()
Filter Pipeline
LP
get()
send() close()
MT
close()
send()
SS
insertFilter() removeFilter()
30
ACT Current Status

• Generic Interceptors are implemented in Java.
• Rule-based interceptors are developed in Java.
• A library of catalysts is currently being
  developed. Examples are
• Power consumption adaptation.
• Wireless network QoS adaptation.
• Run-time architecture for ACT kernel is being
  develped.
• Some sample delegates are ready for test.

31
Concluding Remarks and Future Work

1. Different adaptive middleware are categorized
   according to a taxonomy first introduced by
   Schmidt Taxonomy.
2. Each approach is evaluated with respect to
   transparency, performance, interoperability, and
   generality of supported adaptations.
3. Novel key ideas such as generic and rule-based
   interceptors are developed that provide the
   minimum required infrastructure to support
   dynamic adaptation.
4. An architecture for run time adaptation is
   introduced that includes the three key
   components decision maker, observer, and
   responder.
5. A high level programming abstraction that
   supports dynamic adaptation for distributed
   application is provided (this one not even
   started yet!).
6. A solution to dynamically composing of aspects
   with conflicting behaviors is provided (is being
   tested).

32
References

• CORBA-overview http//www.cs.wustl.edu/
  schmidt/corba-overview.html.
• Taxonomy D. C. Schmidt, Middleware for
  real-time and embedded systems, Communications
  of the ACM, vol. 45, June 2002.
• TAO D. C. Schmidt, D. L. Levine, and S. Mungee,
  The design of the tao real-time object request
  broker, Computer Communications, vol. 21, pp.
  294324, April 1998.
• DynamicTAO F. Kon, M. Roman, P. Liu, J. Mao,
  T. Yamane, L. C. M. aes, and R. 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.
• UIC M. Roman, F. Kon, and R. H. Campbell,
  Reflective middleware From your desk to your
  hand. IEEE Distributed Systems Online Journal
  2(5), 2001.
• QuO J. A. Zinky, D. E. Bakken, and R. E.
  Schantz, Architectural support for quality of
  service for CORBA objects, Theory and Practice
  of Object Systems, vol. 3, no. 1, 1997.
• IRL C.Marchetti, L.Verde, and R.Baldoni, Corba
  request portable interceptors A performance
  analysis, in the 3nd International Symposium on
  Distributed Objects and Applications (DOA 2001),
  (Rome, Italy), Sept. 2001.
• Eternal L. Moser, P. Melliar-Smith, P.
  Narasimhan, L. Tewksbury, and V. Kalogeraki, The
  eternal system an architecture for enterprise
  applications, in the 3rd International
  Enterprise Distributed Object Computing
  Conference (EDOC99), July 1999.

33
References (cont.)

• TAO-LB O. Othman, The design, optimization,
  and performance of an adaptive middleware load
  balancing service, Masters thesis, University
  of California, Irvine, 2002.
• ZEN R. Klefstad, D. C. Schmidt, and C. ORyan,
  Towards highly configurable real-time object
  request brokers, in Fifth IEEE International
  Symposium on Object-Oriented Real-Time
  Distributed Computing, April - May 2002.
• MetaProgramming N. Wang, D. C. Schmidt, O.
  Othman, and K. Parameswaran, Evaluating
  meta-programming mechanisms for orb middleware,
  IEEE Communication Magazine, special issue on
  Evolving Communications Software Techniques and
  Technologies, October 2000.
• OpenORB G. S. Blair, G. Coulson, P. Robin, and
  M. Papathomas, An architecture for next
  generation middleware, in Proceedings of the
  IFIP International Conference on Distributed
  Systems Platforms and Open Distributed Processing
  (Middleware98), (The Lake District, England),
  September 1998.
• MetaSockets S. M. Sadjadi, P. K. McKinley, and
  E. Kasten, Metasockets Run-time support for
  adaptive communication services, in Proceedings
  of the International Symposium on Distributed
  Objects and Applications (DOA) (submitted for
  acceptance!), (University of California, Irvine,
  U.S.A.), November 2002.
• WOSS Z. Yang, B. Cheng, R. Stirewalt, J.
  Sowell, S. Sadjadi, and P. McKinley. An
  aspect-oriented approach to dynamic adaptation.
  In Proceedings of Workshop On Self-healing
  Software, Nov. 2002.