mChaRM: a Reflective Middleware for CommunicationBased Reflection

1
mChaRM a Reflective Middleware for
Communication-Based Reflection

• Yuanfang Cai

2
Overview

• Problem Analysis
• Traditional Reflective Approaches on Distributed
  Systems
• Multi-Channel Reification
• Related Works and Application
• Open Discussions

3
Problem Analysis
Naming and Routing Security authentication Communi
cation Reliability Multi-communiations QoS
Requirments
4
Out of Control-CORBA
5
Hard Wired TAO
6
Reflective Computation

• Reflection a computational process of reasoning
  about and acting upon the system itself.

How to do?
What to do?
Computational Part
Reflective Part
7
Meta-Object Protocol (CLOS MOP)
(defclass position)() (x y))
(defclass person)() (name age address))
8
Meta-Object Protocol (CLOS MOP)
Base Object
(defclass person)() (name age address)
(metaclass hash-table-class))
9
OpenJava
Base-Level Program
.java
Meta-level Program
10
(No Transcript)
11
CodAA reflective middleware for distributed
programming
Lookup
Execution
Scheduling
State access
Buffering
sending
Receiving
Base Level Application Object
12
CodAA reflective middleware for distributed
programming
13
Problems for Traditional Reflective Approaches
Receiving Decrypt
Sending Encrypt
Object 1
Object 2
14
Problems for Traditional Reflective Approaches
15
Problems for Traditional Reflective Approaches
Object B
Object A
Trapped
Trapped
Meta A
Meta B Authentication
16
Multi-Channel Reification --Model
Target locus
Abstract Locus
Target locus
Source locus
Target locus
(1) the sender and the beginning of the
communication, termed source locus, (2) the
dispatching and the delivering of the message to
the designed receivers, termed abstract locus,
and (3)the receivers and the carrying the
computation really out, termed target loci.
17
Multi-Channel Reification --Model
Non-functional Code CoreMetaBehavior()
Abstract Locus
Target locus
Source locus
Functional Code Invoke() ReceiverStubMetaBeha
vior() return tInvoke()
Functional Code SenderStubMetaBehavior()
18
Java RMI (Remote Method Invocation)
Remote Interface
Client
Server (Remote Object)
Registration Server
19
Java RMI (Remote Method Invocation)
Client Program
public static void main (String argv)
try HelloInterface hello
(HelloInterface) Naming.lookup ("//ortles.ccs.neu.
edu/Hello") System.out.println
(hello.say()) catch (Exception e)
System.out.println ("HelloClient exception "
e)
20
Java RMI (Remote Method Invocation)
Server Object
import java.rmi. import java.rmi.server.
public class Hello extends UnicastRemoteObject
implements HelloInterface private String
message public Hello (String msg) throws
RemoteException message msg public
String say() throws RemoteException return
message
21
Java RMI (Remote Method Invocation)
Server Program
public static void main (String argv)
try Naming.rebind ("Hello", new Hello
("Hello, world!")) System.out.println ("Hello
Server is ready.") catch (Exception
e) System.out.println ("Hello Server failed
" e)
22
Multi-Channel Reification
Sender
Receiver


Define Kinds Invoke MultiRMI
mChaRM Preprocessor
Services
23
Multi-Channel Reification Kind
public class sender instantiates
mChaRM_MOP kinds kind verbose with A, B, Z to
dummy1 kind normal with A, B, Z to dummy2,
dummy3 //usual class description
Methods
Kind Name
Receivers
24
Multi-Channel Reification Sender
Sender Program
public class customer instantiates
mChaRM_MOP Kinds Kind validation with ATM1 to
withdraw public static void main( String
args) customer c new
client(Walter) c.multiRMI(deposit,
new String ATM1 new Object walter,
c.multiRMI(withdraw, new String
ATM1 new Object walter,
25
Multi-Channel Reification Receiver
Receiver Program
public class ATM instantiates mChaRM MOP public
void deposit(String id, String accNum, int sum)
// code for depositing the ltsumgt on the ltidgts
account. public void withdraw(String id,
String accNum, int sum) // code for withdrawing
the ltsumgt from the ltidgts account.
26
Multi-Channel Reification Channel Core
Channel Core Program
class validationChannelCore extends
channelCore private Hashtable right
public validationChannelCore(String RsName,
String permissionFileName) //
initialize the right table . . .
super(Validation, RsName, senderStub,
receiverStub) public Object
coreMetaBehavior(mChaRMMethodCall msg)
bool permission right.get(key(client,
receiversName, methodName)) if
(!permission) thrown IllegallRequestForAService
return super.coreMetaBehavior(msg)

27
Related WorkQuO
28
Related WorkQuO
We asked How to keep consistency among contracts?
29
Related WorkQuO

• Client Delegate
• ---Source Locus
• Object Delegate
• ---Target Locus
• Contract
• ---Abstract Locus

30
Related Work -TAO

• Can we use Multi-Channel to realize end-to-end
  real time TAO?
• Add on-line configuration feature to TAO.

31
Related Work -AspectJ
Object
Object
Object
.exe
32
Related Work -AspectJ

• Join Point
• Pointcuts
• Advices
• Aspects

AspectJ
Advice
advice body
pointcut
join point
Java Program
33
Related Work -AspectJ
Pointcut
34
Related Work -AspectJ

• Features
• Can be used on legacy codes
• Can work on multiple objects (Can MOP do this)
• One step reflection
• How would AspectJ do this?

35
Another ApproacheOpenCORBA
ORB Wrapper
ORB Wrapper
ORB
ORB

• Doesnt need new language
• High Cost

36
Reflective Application Spring Kernel

• A Reflective Architecture for Real-time OS
• Specification of Reflective Information
• Spring-C
• System Description Language(SDL)
• Fault Tolerant Entities for Real-Time (FERT)
• Real-Time Scheduling
• Fault Tolerance
• Integrating Scheduling and Fault Tolerance

37
Reflective ApplicationSpring Kernel

• Features
• Addresses time constraints at all levels of the
  system so that more accurate timing analysis can
  be done even early in the design
• Facilitates the use of scheduling algorithms that
  are robust even under violations in the initial
  assumptions
• Supports planning-based scheduling that allows
  detection of timing errors early and application
  of state- and time-dependent recovery strategies
• Supports adaptive fault tolerance so that there
  is flexible management of redundancy subject to
  time constrains.

38
Discussions

• Can senders use multiple channels of the same
  kind at the same time?
• Where are the registration servers? Are they in
  different machines and we have to have them
  running all the time?
• Tradeoffs for Reflective Computing
• Security
• Performance
• Others