Composability Issues in Adaptive Reflective Middleware for Dynamic Distributed Environments

1
Composability Issues in Adaptive Reflective
Middleware for Dynamic Distributed Environments

• Nalini Venkatasubramanian
• School of Information and Computer Science
• University of California, Irvine

2
QoS Aware Information Infrastructure
Device and Sensor Networks
Electronic Commerce
Distance Learning
QoS enabled Wide Area Network
Collaborative Multimedia (Telemedicine)
Collaborative task clients
Data Servers
Requirements - Availability, Reliability,
Quality-of-Service, Cost-effectiveness, Security
3
Why Reflective Middleware?

• Wireless communication, mobile computing and
  real-time applications demand
• High adaptability
• Dynamic customization of systems, services,
  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
• In achieving these goals, one must be careful to
  maintain consistency and correctness need a
  semantic model

4
Composable Reflective Middleware

• In providing such an environment, interactions
  between various components as well as
  system-level correctness must be maintained
• Incorporate effective mechanisms into a
  composable middleware framework to ensure safety
  and QoS enforcement in distributed and mobile
  environments
• Customizable, Composable Middleware Frameworks
• Provide for dynamic network and system
  customization, dynamic invocation/revocation/insta
  llation of services
• To adapt to the above dynamic changes in modern
  applications and manage distributed components

5
Reflection

• Provides a plug-and-play environment for enabling
  run-time modification of policies
• An efficient technique to build composable
  middleware
• Features
• Separation of concerns
• Introspection
• Flexibility, Adaptability
• Composition
• Implies concurrent execution of multiple resource
  management policies

6
Composability Issues

• Service Composability
• Access control and context awareness
• Coordination protocols built into DS core service
• Secure mobility
• Dynamic delegation and revocation (keys, access
  rights, certificates) with mobile agents and
  hosts
• Support for disconnected entities
• Protocol Interference
• Timeliness Reliability Security
• Protocol - Service Interactions
• Mobility Security QoS
• Reachability Snapshot Failures
• Migration Reliability
• Need approximate notions of correctness

7
A Structured Approach to Reflective Middleware

• Two Level Meta Architecture (TLAM)
• Separate enforcement of system level requirements
  from application level activities to permit
  customizability
• Layered Specifications
• End-to-end service specification
• System-level architecture specification
• Local behavior specification
• Isolate complex interactions in well understood
  core services for managing composition
• Reflective Communication Framework (RCF)
• Extends the TLAM model to provide safe and
  flexible customization of communication protocols
• Ensures correctness of middleware services in the
  presence of flexible communication

8
Two Level Actor Machine (TLAM)

• A semantic framework for specifying and reasoning
  about components of ODS (middleware services)
• Features
• Based on the actor computation model for OODS
• Base-level actors model application functionality
• Meta-level actors model middleware services
• Base-level actors and messages have associated
  run-time annotations that can be set and read
  (only) by meta actors
• Use of core services to isolate complex
  interactions
• Specification viewpoints

9
Core Services
System (Meta) Level
Replication
Access Control
DGC
Migration
Check- pointing
Distributed Snapshot
Remote Creation
Directory Services
Application (Base) Level
Core services allow us to isolate complex
interactions -- useful for managing composition
of services
10
Specification Viewpoints
System specification (S)
Application
Global System Functions
Behavior specification (B)
Algorithmic specification (A)
meta behavior
meta behavior
End-End service specification (E)
...
Procedure
Node Base System
11
Relating Specification Viewpoints

• (S gt E) system spec implies end-to-end service
  spec
• (B gt S if I and NI) behavior spec implies
  system spec if
• (I) initial conditions satisfied
• (NI) non-interference conditions satisfied
• (AgtB) algorithm spec implies behavior spec
• .....

12
QoS Broker

• Composability is essential in ensuring
  cost-effective QoS in distributed multimedia
  systems
• Safe composability of resource management
  services
• QoS Brokers coordinate multiple activities in
  such systems
• interactions between multiple QoS sessions
• interactions with multiple system services
• Functions of a QoS broker
• Deal adaptively with incoming requests
• Re(configure) data to service requests
• Must maintain resource allocation invariants

13
The ComposeQ Framework
QoS Broker
Application Objects
Request Mgmt
Data Mgmt
Data Placement
De-replication
Message Scheduling
Request Scheduling
Clock Sync
Migration
Replication
Core Services
Remote Creation
Distributed Snapshot
Directory Services
Interaction with Core Services
14
Specification Viewpoints for Qos Brokerage
15
TLAM Configuration for QoS Brokerage Service
16
Simple Request Admission
17
Request Admission with Replication-on-Demand
18
Dereplication and Placement
Dsma(ds)
Dsma(ds)
Dsma(ds)
PP
DR
QB
(mms)
derepl(mms)_at_QB
repUpd(repU)_at_DR
repUpd(repU')_at_DR
repUpdAck_at_DSma(ds)
repUpdAck_at_DSma(ds)
dereplReply(repU")_at_DR
(mms repU)
place(mms)_at_QB
repUpd(repU)_at_PP
repUpdAck_at_DSma(ds')
repUpd(repU')_at_PP
repUpdAck_at_DSma(ds")
dereplReply(repU")_at_PP
(mms repU)
19
The ComposeQ Framework

• Physical Configuration
• Nodes distributed across a network
• Middleware Configuration
• Distributed Component
• Instance of runtime kernel on each node
• Programming Environment
• Based on concurrent objects

20
ComposeQ Node Runtime
21
Access Control in Dynamic Environments

• Access control is an important problem in
  distributed environments.
• Prevent service content providers from
  obtaining unauthorized access to client data and
  resources.
• Reduce complexity at firewalls and networks,
  supplement them with more robust, host-based
  security mechanisms.
• Widespread use of mobile object/agent based
  technologies, demand for data (of varying
  sensitivity) on-the-fly
• Introduction of mobility further complicates
  traditional mechanisms used in distributed
  systems and forces us to re-evaluate how we view
  systems.
• Multilevel security is becoming a popular
  paradigm in secure information processing.
• Allow entities to be associated with different
  security classifications while sharing data in a
  safe manner.
• Provision of a security framework for
  middleware-based systems
• Customizability composability for security

22
Existing Solutions

• Access control is largely limited to OS support
• Few solutions for fine-grained enforcement
• Hard to adapt, less flexible
• Resource intensive
• Little protection against inside threats (passive
  security)

23
Problems

• View Establishment Maintenance protocols for
  both establishing local views for objects on
  hosts and maintaining these views given changes
  in mobility conditions (view approximation).
  Define a number of invariants for the
  architecture, that need to hold during the view
  maintenance process.
• Disconnection Re-evaluating access rights
  depending on where a node appears upon
  reconnection. Message delivery to reconnected
  nodes.
• Delegation Revocation Protocols to support
  both object and node mobility. Complications that
  arise when performing these tasks on objects in
  varying security domains.

24
Customizable Security

• Capability-based access control architecture
• Customizable Security Mechanisms
• Adapt security policies to fit user needs under
  changing system and network conditions
• Resource constraints, network bandwidth
• Tradeoffs for Secure QoS
• Domain-based Security
• Inter-domain security based on various security
  levels.
• Protocols to define object mobility
• Customizable Authentication

25
Domain-based Access Control (DBAC)

• We model domains as partitions of the network
  space, encapsulating nodes of varying security
  levels. These partitions effectively represent
  certain equivalence classes that allow us to
  control the granularity of the domain.
• The security level (SL) of a domain is
  represented by a tag, which is associated with
  both the objects and the domain itself.
  Application objects are created in initial
  domains and move to new ones which may require
  different credentials or more specifically
  different security levels.
• By studying the interactions between various
  services and policies, objects moving between
  different domains should preserve a set of
  properties for availability, secrecy, integrity
  and semantic consistency.

26
(No Transcript)
27
A Reflective Model for Access Control

• A meta-level access control service manages
  access rights for base actors and ensures that
  the capabilities associated with actors
  accurately reflect the desired security policies.
• A global MSA co-ordinates and maintains
  information that is needed by the local MSAs, as
  well as encapsulate global policies for
  maintaining system wide security, secure
  bootstrapping functionality etc.
• The primary component in the access control
  service is the Meta-level Security Actor (MSA),
  which is resident on each node and is responsible
  for the following activities
• Encapsulates and interprets security policy as
  part of its behavior (view management,
  delegation/revocation etc.).
• Mutual authentication of meta-level
  communication.
• Capability insertion/verification for
  outgoing/incoming messages
• Communication (secure) with DS, maintain/update
  AC information

28
System Architecture
29
Security Meta Actor Functionality

• Local MSA (fixed nodes)
• Encapsulates and interprets security policy as
  part of its behavior (view management,
  delegation/revocation etc.).
• Mutual authentication of meta-level
  communication.
• Authenticate and establish secure connections
  with directory services (e.g. SSL-based).
• Capability insertion/verification for
  outgoing/incoming messages
• Verification that incoming messages to an actor
  have the necessary rights
• Tagging outgoing messages with capabilities for
  the sender
• Communication (secure) with DS, maintain/update
  AC information, cache information locally
• System (regional) MSA (RMSA)
• Mutual authentication of meta-level
  communication.
• Authenticate and establish secure connections
  with directory services (e.g. SSL-based).
• Maintain and update access control information
  pertaining to nodes in its domain (region).
• Processing rights associated with messages
  from/to all mobile hosts in its domain, as well
  as routing to the respective hosts (piggy-back AC
  information with message).
• Local MSA (mobile nodes)
• Maintain local view of objects on host

30
View Management/Maintenance

• All entities represented as active objects (e.g.
  files). Hence can prohibit access to objects via
  manipulation of an objects acquaintance list.
• View of an object representation of state of an
  object at some point in time. Total view of an
  object at the highest security level, which is
  represented in the DS (possible acquaintances,
  state).
• Development of a view management algorithm, that
  deals with instances in which the view of an
  object can change, during system operation.

31
View Management/Maintenance (2)

• State
• Initial state of object during bootstrap
  procedure, with any acquaintances that have been
  assigned at startup
• Object Migration If an object migrates to a
  host in a domain of lower SL (in relation to the
  current domain of residence), the SL of the
  object is decreased to match the target domain.
  Any sensitive information (of higher SL) is
  captured and held at the DS. Objects local view
  is updated to represent this change in state
  DBAC rule set
• Node Migration Note if the SL of a node is X,
  then all objects on that node have a SL less than
  or equal to X DBAC 1,2. Migration to a node
  greater than the current SL involves a change in
  view in the same way if it was just one object
  migrating to the new domain
• Shutdown All state acquaintances are stored
  in the DS. On restart, view establishment refresh
  needs to be performed due to possible changes in
  location (and possibly domain)

32
View Management/Maintenance (3)

• Host Reconnection
• Description A disconnected node comes back up,
  possibly in a new domain (of varying SL)
• Step 1 On reconnection, host re-registers
  (with the DS) if necessary (still must
  authenticate). Current location is updated.
• Step 2 Restore last known state for all objects
  on the node
• 2b MMSA If current SL(dom) gt previous SL of
  host ? all state acq restored. Else
  SL_Reduction (for all objects on host) in
  accordance with DBAC 1/3

33
View Management/Maintenance (3)

• View Approximation
• Description A view is associated with the
  current location (more specifically a domain) of
  an object. Assuming the underlying location
  management system uses a history-based profiling
  mechanism the protocol looks to identify common
  movement patterns and then approximate the view
  to prevent excessive computation of constantly
  switching state

34
View Management/Maintenance (4)

• Movement-based / history oriented tracking
  mechanism ? maintain a profile for mobile nodes
• Count of boundary crossings across regions
• If a common pattern is detected (we assume the
  profile information provides this) adjust the
  view most conservative SL (mindomains in
  pattern)
• Problem critical information may not be
  accessible even when a node as the required
  rights (SL) to access it because of the
  approximation
• Trigger events on critical state information that
  will force a view refresh if necessary
• Allow the user/application to control how far the
  view on a host should be allowed to diverge from
  the norm

35
Disconnection

• Types of disconnection
• Sign off (shutdown)
• Log off / Check out (disconnected, but remain
  registered with the name server)
• Failure (unexpected disconnection)
• Messages in transit
• Discard messages (on failure)
• Store messages
• In the worst case, if many hosts are disconnected
  for an indefinite period of time ? space needed
  is unbounded, and congestion is caused by other
  hosts sending messages rapidly

36
Disconnection (2)

• Store messages for a limited time (TTL)
• Host Reconnection (re-registration
  authentication)
• SMSA check each message for access rights
• Success route to target object
• Failure discard

37
(No Transcript)
38
Safety Properties (Example)

• DBAC Safety Properties
• SL(a) gt x, where x is the security level of an
  actor, and x ? L0, L1, L2, L3
• 1 Actor Creation / Monotonicity Preservation
• 2 Acquaintance Relations Preserve Domain
  Ordering
• 3 Migration Preserves Domain Ordering

39
Simulation

• Mobility Model Modified Random speed-based.
  Additional mobility model for objects on top of
  host-mobility.
• Metrics of evaluation
• MSA processing O/H (MSA,SMSA,MMSA)
• DS maintenance O/H
• Total Messaging O/H
• View maintenance O/H
• Update/refresh
• Impact of view approximation
• Experimental scenarios
• Location management schemes
• Domain (region) granularity
• Optimizing for varying mobility conditions
  (fast/slow mobility) effects of caching

40
(No Transcript)
41
(No Transcript)
42
Effects of caching on DS updates overhead
No caching
DS Updates (103)
Running Time (secs)
43
Implementation

• Prototype implementation is built on the
  CompOSEQ middleware architecture. This framework
  provides the necessary runtime semantics for the
  base and meta-level actors we utilize for the
  access control framework. The implementation
  consists of the MSA itself, first-class
  capability objects as well as the directory
  service and interface that serve as a trusted
  repository.
• The prototype security modules are implemented in
  Java for portability, flexibility through
  introspection and type-safety. Cryptix is used
  to provide the necessary cryptographic libraries
  for the framework.
• An outline of how capabilities are represented
  and embedded within messages is provided below.
  The effect of the access control mechanisms on
  the CompOSEQ runtime is also shown, and focuses
  on the message filtering that occurs as part of
  the verification/processing performed by the MSAs
  on incoming/outgoing messages.

44
Interaction of meta-level services with the
CompOSEQ runtime
45
Performance Results
Below is a selection of results obtained by
measuring the performance of our prototype.
Execution times are average results over 100
iterations of the various components and
represented without JVM introduced overheads. The
main goal of these preliminary measurements were
to ascertain what kind of overhead the security
mechanisms would place on both the runtime and
communication subsystem. Further experiments were
performed to examine the effect of the
architecture on the directory service.
46
A Question

• How can multiple communication protocols and
  middleware services be safely reconfigured in
  dynamic environments
• Protocol composition goes far beyond protocol
  layering order due to subtle interactions and
  dependencies between them (protocol interference)
• Protocols must be encoded to separately specify
  protocol functionality, dependencies and
  interaction properties
• Middleware services make assumptions about the
  underlying communication environment
  (protocol-service interaction)
• If these assumptions are not satisfied,
  correctness violations may occur

47
Protocol Interference Case Study Secure
Reliable Timely Delivery (SRTd)

• Some applications use time sensitive information
• Complex to support for continuous flow of time
  sensitive information
• Heterogeneity and dynamicity of the underlying
  network
• Impossible to distinguish extended transient
  network loads from network partitions or network
  failures
• Use reliable timely delivery
• Messages have predefined valid time span
  (delivery deadline)
• If we consider mobility
• Network is partitioned into geographical domains
  with varying security levels
• Secure protocol provides message integrity,
  secrecy and authenticity

48
SRTd Example
Messages may face temporary delays due to
re-keying
We need to identify and extract interaction
parameters entwined in the protocol functionality
49
A new way of specifying protocols
a.k.a. Show me the code slide
50
Protocol-Service Interaction Reachability
snapshot in the presence of failures

• Concurrent execution of an snapshot service (S)
  and a failure detection protocol (FD)
• S allows to gather relevant and accurate
  information about the state of a (distributed)
  system
• Records the set of reachable objects of a
  particular configuration using a mechanism to
  record the state of all nodes including the
  portion being communicated in the network channel
• Assign every message with a parity to indicate
  whether the message is old (unrecorded) or new
  (recorded)
• FD have been used to provide hints about possible
  failures in the system
• Usually based on a heartbeat mechanism
• Node failure may be inconsistent
• Variable degree of accuracy and efficiency
• A node failure
• Blocks the snapshot in progress (even when the
  crashed node is restarted)

51
Protocol-Service Interaction Case Study
Reliable Delivery to Migrating Objects (RDMO)

• Migration service
• 3 Phases
• C0 Determines the computation to be migrated by
  suspending the actor computation and noting its
  current description (state)
• C1 Creates a new remote actor with the current
  actor description in the desired node
• C2 Establishes transparent access to the
  migrated actor by changing the original actors
  behavior to a forwarder
• Traversing the forwarding chain may take
  unpredictable amount of time (especially if the
  actor is migrating during the traversal process)
• If the communication environment is unreliable,
  there is no way to distinguish between a message
  chasing its target and a lost message
• Message delivery guarantees may be meaningless
• Furthermore, the forwarding chain may contain
  loops
• Identify and collapse forwarding chain

52
RDMO Example
Migration service allows for easy access,
availability and load balancing
In an unreliable environment, It is complex to
distinguish between a message in transit
(chasing its target) and a lost message
If an object migrates every so often, a message
sent to it may never be delivered
In fact, the problem is worse
53
Solutions to the RDMO Problem

• Naive
• Use a flooding mechanism such as broadcast or
  multicast
• Excessive message overhead
• Requires every actor to maintain history of all
  possible previous names
• Pessimistic
• Constrain (actor) mobility in order to guarantee
  message delivery
• Serializes actor migration and reliable messaging
  sending process
• Publishes well know intervals when actors may
  migrate

54
Solutions to the RDMO Problem

• Conservative I
• Constrain mobility only during the time required
  to ensure message delivery to that specific actor
• Requires that some node in the forwarder chain
  realizes when a reliable message must be
  delivered to the actor and restraints its
  migration process until the desired messages are
  delivered
• Actor may visit every node in the system before
  being notified that it can not migrate until the
  chasing messages are delivered to it
• Worst case scenario has an upper bound O(NP)
• N nodes
• P max protocols

55
Solutions to the RDMO Problem

• Conservative II
• Use a directory service (DS) to maintain the
  current actor location and a disable-migration
  annotation
• Before sending a timed delivery message, activate
  the disable migration annotation
• If a migration has already been initiated (but
  not completed) when the annotation is set, the
  migration is allowed to proceed asynchronously
  and succeed
• The reliable message is sent to the previous
  location and it will need to traverse one link
• Worst case scenario has an upper bound OCP
• C DS constant access
• P max protocols
• RCF can adaptively choose to traverse the
  forwarder chain or consult the DS based on
• Reliability and timeliness requirements
• Actor information (migration frequency, etc)

56

Identification of forwarder chain loops
57

Identification of forwarder chain loops

58
Collapsing the forwarder chain
59
Limitations of the TLAM

• TLAM restricts reflective capability
• Two levels
• Base-level state represented and manipulated
• Communication and scheduling observed, but not
  controlled
• Base-level not aware of meta-level
• TLAM
• Provides a framework for formalizing interactions
  and for stating and proving desired properties
• Uses a special purpose (ad hoc) rewriting
  mechanism to express the interaction of the base-
  and meta-levels

60
The RCF Model

• Extends the TLAM to provide safe and flexible
  customization of communication protocols
• Distinguishes and handles different types of
  messages and communication protocols
• Integrates QoS parameters into resource
  management and message handling processes
• High-level communication services through
  composition of basic protocols
• Dynamic (un)installation of protocols
• 4 levels of message customization
• Efficient implementation
• Components
• Each base level actor has a meta level actor
  called messenger
• There is one communication manager on each node
  of the system
• There is one connection manager on each node of
  the system

61
RCF Components

• Messenger (Msgr)
• Message interception behavior based on send and
  receive events
• 4 queues
• up and dwn are used to communicate with the base
  actor
• In and out are used for interaction with the
  communication manager, requesting communication
  services for the incoming and outgoing messages
• Communication Manager (CMgr)
• Pool of message coordinators (MCs)
• Ensures safe protocol composition by coordinating
  (and possibly constraining) protocol execution
  order
• A set of communication protocols grouped and
  shared between objects, which simplifies the
  synchronization and composition process
• Each communication protocol (CPA) specification
  is enhanced with a list of restrictions of use,
  prerequisites and dependencies, interaction
  parameters and Installation (uninstallation)
  information
• Connection Manager (CxMgr)
• Collects relevant information regarding logical
  connections between nodes

62
The RCF Architecture
Communication Protocol 1
Communication Protocol n
Protocol installer
. . .
Protocol uninstaller
Message Coordinators pool
Protocol loader
gk
gp
gn
...
...
...
messenger
messenger
out
out
in
in
. . .
up
up
dwn
dwn
1
Base actor 1 and its messenger
m
Base actor m and its messenger
Node
63
Protocol Ordering

• The problem of determining the correct
  composition order has not been completely solved
• Several techniques have been developed and we
  integrate and leverage protocol dependencies from
  other projects
• e.g Ensemble, BAST
• We develop a generic rule base used as an oracle
  to determine which protocol implementation is
  suitable for a particular application in terms of
  coverage and efficiency

64
Protocol Composition (sndr)
. . .
S2
C1
S1
TD1
gl
gk
gp
gn
...
...
...
messenger
out
To the network
in
up
dwn
a
Base actor a and its messenger
Node
65
Protocol Composition (sndr)
Protocol installer
. . .
Protocol uninstaller
S2
C1
S1
TD1
Protocol loader
gl
gk
gp
gn
...
...
...
processed message
messenger
out
To the network
in
up
tunneled raw message
dwn
a
Base actor a and its messenger
Node
66
Protocol Composition (rcvr)
Protocol installer
. . .
Protocol uninstaller
S2
C1
S1
TD1
Protocol loader
gl
gp
gk
gn
...
...
...
messenger
out
in
up
from the network
dwn
a
Base actor a and its messenger
Node
67
Protocol Composition (rcvr)
Protocol installer
. . .
Protocol uninstaller
S2
C1
S1
TD1
Protocol loader
gl
gp
gk
gn
...
...
...
processed message
messenger
out
in
up
from the network
dwn
raw message
a
Base actor a and its messenger
Node
68
Protocol composition process

• Protocol composition mechanism (executed at the
  message coordinator)
• Extracts
• Prerequisite list
• Restriction list
• creates
• master prerequisite list,
• master restriction list
• Extracts application requirements
• Determines interaction parameters and sets their
  values
• Generates composition order list (ordlst)
• Verifies if execution needs to be serialized
• Coordinates execution of communication protocols

69
RCF Semantics

• If the message is processed through the RCF (case
  1), the following safety and liveness properties
  are satisfied
• No message spontaneity Every message processed
  by the RCF is attributable to a base level actor
• No message duplication No duplicated message is
  delivered to the application
• Message integrity Base level message payload is
  not modified by the RCF
• Protocol progress All messages in the RCF that
  require a communication protocol will eventually
  be processed
• Termination of transmission All outgoing
  messages in the RCF are eventually sent to their
  corresponding target actors
• Termination of delivery All incoming messages in
  the RCF will eventually be delivered to their
  corresponding base level actors

70
Reasoning about correctness

• Property 1 (Message uniqueness)
• Every message is tagged with a unique (monotonic)
  message identifier msgid by the node manager
• This is satisfied by the message creation
  behavior of the messenger
• Lemma 1 (No message spontaneity)
• Every message received by a base level actor has
  been sent previously by another base level actor
• Proof sketch messenger is the only RCF component
  capable of sending messages on behalf of base
  level actors and messenger behavior guarantees
  that every message queued in the up queue was
  previously sent by, or on behalf of, a base level
  actor

71
Reasoning about correctness

• Lemma 2 (Message integrity)
• The message payload is not modified iff the
  component of the RCF do not inspect message
  contents
• Proof sketch Communication manager, message
  coordinator and messenger behaviors guarantee
  that message payload is not modified. Hence if
  the protocols do not inspect or modify message
  contents, message integrity is preserved
• Fairness
• is a feature of actor computation
• is maintained as a consequence of the following
  assumptions
• Individual actor computations are guaranteed to
  progress
• FIFO assumption on the processing of messages

72
Reasoning about correctness

• Lemma 3 (Protocol progress)
• Every message that requires to be processed with
  a cps that will satisfy correct protocol
  composition execution order and return the
  processed message
• Proof sketch By communication manager, message
  coordinator behaviors, termination of
  communication protocols and actor fairness
• Lemma 4 (Termination of Transmission)
• Proof sketch By messenger and message
  coordinator behaviors, protocol progress property
  and actor fairness
• Lemma 5 (Termination of Delivery)
• Proof sketch By messenger and message
  coordinator behaviors, protocol progress property
  and actor fairness

73
Reasoning about correctness

• Theorem 1 (RCF behavior implies RCF service)
• If a system S satisfies the following
• S has RCF behavior
• Every configuration Cfig in S is reachable from a
  configuration satisfying the RCF initial
  conditions
• Then, S provides RCF service (Definition 1)
• The proof is derived from the specific RCF meta
  actor behaviors and the lemmas described earlier

74
The TLAM in Rewriting Logic

• The concurrent state of a system can be
  visualized as a flat multi-set of objects and
  messages that behave according to a set of rules
  describing the behavior of individual objects.
• Rewriting logic theory is a triple R(?,E,R),
  where
• (?,E) specifies the static structure of a
  distributed systems state space as an algebraic
  data type
• The rules in R specify local concurrent
  transitions that can occur in the system (i.e.
  describe the dynamics of the system)
• Object
• ltO F attsgt
• Rewrite rule
• R M1Mi ltOi Fi attsigt ltOk Fk attskgt ?
  ltOj Fj attsjgt ltOk Fk attskgt ltOnew1 F1
  atts1gt ltOnewi Fi attsigt MnewkMnewn

75
The Russian Dolls Model A Generic Formal Model
of Distributed Object Reflection

• Using the ideas and reflective nature of
  rewriting logic, we model a distributed system as
  a soup in which reflective objects and messages
  float and interact to each other
• A reflective object is a composite object
  consisting of a soup of meta-objects and a nested
  soup of base-objects whose structure and behavior
  is reflected in the meta-object soup
• The meta-objects can be given full control of the
  base objects by using the meta-representation of
  the base-level provided by the logic

76
The Russian Dolls Model A Generic Formal Model
of Distributed Object Reflection
77
TLAM in the Russian Dolls Model

• A TLAM system configuration is a soup of nodes
  and messages with base and meta actors forming
  nested soups inside the nodes
• Actors are modeled as objects with identity and
  state
• lta BC attsgt
• Messages have the form
• a lt- m
• Actor behavior is modeled as rewrite rules
• lta BC attsgt a lt- m ? lta BC attsgt bconf,
  if cond
• Meta actors are grouped as subobject
  configurations of nodes, which are meta-meta
  objects
• If there is an associated base level event, then
• Each event handling rule that matches the event
  must be applied (in an unspecified order)
• The associated annotation update applied to the
  local base-level configuration and messages

Trick Correctly model meta-level observation of
(base-level) events and ensure event handling
rules are applied when required
78
TLAM in the Russian Dolls Model

• A node transition is either a
• Communication transition
• Moves messages from the nodes buffer to the
  external soup
• Moves messages from the external soup into the
  nodes buffer
• Execution transition
• Applies either a base or meta level transition
  rule
• A node is an object of class TLAM-Node
• it has an attribute conf whose value is a
  configuration containing meta actors and
  messages
• ltnu TLAM-Node conf ltbtma BMC gt ltcma
  CMC gt mconfgt
• Special meta actors
• btma
• Base-behavior/task manager deals with base-level
  execution
• ltbtma BMC bMod!BM, bConf!bc, eRegemap,
  pendEvev, waitForWgt
• cma
• Communication meta actor deals with message
  processing
• ltcma CMC sendQsmsgs, arriveQamsgs,
  eRegemap, pendMsgev, waitForWgt

Note btma and cma also implement the event
handling semantics associated with base level
events
79
TLAM in the Russian Dolls Model

• Execution event
• Modification of a nodes base-level actor
  configuration resulting from applying either a
  base or meta level rule
• exe(!bConf, !update, cmap)
• Event handling
• Is modeled by sending notifications to meta
  actors registered for the event
• Meta actor is registered for an event iff it has
  an event handling rule matching this event
• apply(emap, event)
• Generates a reply to the notifying actor
• Other event functions
• Subconfiguration of bc containing the actor a and
  any pending messages for that actor
• restrict(!bc, !a)
• The result of updating bc using apply(!BM,
  restrict(!bc, !a), rname, subst)
• update(!BM, !bc, !a, !rname, subst)

Convention if foo denotes a base-level entity,
then !foo denotes the meta representation of
that entity
80
TLAM in the Russian Dolls Model

• Message
• Transmission (from the node to the external soup)
• send(!(a lt- m), !sndr, amap)
• Reception (from the external soup into the node)
• arrive(!(a lt- m), !sndr, amap)
• Delivery (to the target actor)
• deliver(!(a lt- m), !sndr, amap)
• Note
• cma can receive requests for message processing
  interleaved with the processing of a message
  event, but may not interleave processing of two
  or more message events
• Two rules that involve synchronization with the
  btma ensure a consistent causal connection
  between base and meta levels

81
TLAM in the Russian Dolls Model
rcvbuff
Node
Node
Node
sndbuff
Node
Base level
Node
Node
External Soup
82
RCF in the Russian Dolls Model

• The RCF node configuration
• Communication manager, which coordinates message
  processing
• Set of message coordinators (?)
• Set of communication protocol (?)
• Set of messengers (?), which controls message
  semantics for their base level actors
• RCF transition
• Message transmission
• Interception
• Classification
• Processing
• Transmission
• Message reception
• Arrival
• Handling
• Processing
• Delivery

83
RCF in the Russian Dolls Model
Messengers
CMgr
..
rcvbuff
Node
Node
Node
sndbuff
Node
Base level
Node
Node
External Soup
84
Concluding Remarks

• A cleanly defined meta architecture that provides
  dynamic customization and composition of
  protocols and services is needed to support
  ubiquitous applications
• Semantic models
• Contribute to the conceptual sharpening and
  unification of reflective notions
• Provide high assurance of critical system
  properties
• RCF is a first step to provide cost-effective
  reflective communication framework capable of
  addressing adaptive environments with evolving
  policies

85
Future Work

• On-the-fly (un)installation of protocols is
  cumbersome and error-prone
• Dynamic protocol reconfiguration may require a
  protocol itself
• Combination challenges
• Access control Reliable delivery
• What does it mean message is not deliverable
• How to find appropriate algorithms and rules for
  setting parameters

86
Bonus Section

• RCF Implementation
• We constrain Java to achieve actor semantics
• Exploit maximal concurrency in message processing
  without violating actor semantics
• Pipelined approach to execute multiple
  communication operations within a messenger
• Activation of external actors within messages
  (continuation pattern style)
• Extend the active object pattern and instantiate
  continuation pattern style execution via the
  command pattern
• Individual operations in a messenger do not need
  to be strictly sequential
• The only synchronization necessary is in the
  messengers queues, which is a fixed cost that
  can be amortized by pipelining

87
Startup Overhead

• Determined by
• Pool size
• Initial set of communication protocols

88
Messenger Management

• Messenger creation overhead is high due to the
  initialization of the blocking queues
• A spin lock is required to avoid race conditions
  in message dequeue operations

89
Message Overhead

• Assuming an underlying run time environment
• Measured message transmission and reception
  overhead from the underlying transport layer
• Integrate RCF and measured raw message
  transmission and reception overhead
• Measured processed message transmission and
  reception overhead (reliable and secure
  customization)