Compiler Support for Distributed Systems

Martin C. RinardUniversity of California, Santa Barbara

Goal

Provide Software Tools That Support Development of Components of Distributed Systems

• Problems

• Interoperability

• Distributed Component Development

• Components Developed At Different Times

• Components Developed By Different Organizations

• Interaction With People

• Our Approach

• Formal Interface Definitions Using Finite State Machines

• Automated Interface Extraction, Verification and Testing

• Novel Constructs for Building Robust User Interfaces

Model of Computation

• Distributed Systems Built Out Of Components

• Processes

• Agents

• Objects

• Components Communicate Via Message Passing

• Asynchronous Sends, In Order Delivery

• send(component, message type, parameters)

• Blocking Receives

• recv(component?, message type, parameters?)

• Selection Construct

Example

Please Deposit $5,000,000.00

147

2580

369.

Customer ATM Machine Bank

Scenario

• Existing ATM System

• Bank Contracts For New Kind of ATM

• New ATM Must Interoperate With Existing Bank Software

• ATM Developer Must Know Bank Interface

• Bank Unwilling to Release Source Code

Bank Implementation

loop { select {

recv(atm?, DEPOSIT,account?,amount?) -> {

account.balance += amount;

send(atm, OK);

}

recv(atm?,WITHDRAW,account?,amount?) -> {

if (amount < account.balance) {

account.balance -= amount;

send(atm, OK);

} else {

send(atm, FAILED);

}

}

}}

Bank Interface

• Message Type Information• recv(component?, DEPOSIT, int?, int?)

• recv(component?,WITHDRAW, int, int)

• send(component, OK);

• send(component, FAILED);

• Message Sequencing Information

recv(atm?,DEPOSIT) recv(atm?,WITHDRAW)

send(atm,OK)send(atm,FAILED)send(atm,OK)

Conformance of Components and Interfaces

• Context

• Have A Component (Bank Component)

• Have An Interface (Bank Interface)

• Does Component Correctly Implement Interface?

• Analyze Program To Automatically Extract New Interface

• Abstract Away From Computation

• Translate Communication and Relevant Flow of Control Constructs Into Parts Of Finite State Machine

• Does Extracted Interface Conform to Original Interface?

• Individual Programming Constructs• if (exp) {

send(c,OK);

} else {

send(c,FAILED);

}

• select {

recv(c?, OK) -> {}

recv(c?, FAILED) ->{}

}

• Interprocedural Interface Extraction

Automatic Interface Extraction

send(c,OK); send(c,FAILED);

recv(c?,OK) recv(c?,FAILED)

Internal Choice

External Choice

Basic Conformance Concepts

• Concept Of Conformance• An Interface I Extracted From a Component• An Interface J That System Is Designed to Use• If I Conforms to J, Can Safely Use Component In System

• If Every Message Sent Is Received With J, Every Message Sent Will Be Received With Component

• A State S is Stable If It Is Not An Internal Choice Point• A State S is Receptive If It Can Only Receive Messages• Given Two Interfaces, Sets Of Corresponding States

• Maximal Sets Of States Accessible Via Same Sequence of Sends and/or Receives

Original Interface

recv(atm?,DEPOSIT) recv(atm?,WITHDRAW)

send(atm,OK)send(atm,FAILED)send(atm,OK)

recv(atm?,DEPOSIT) recv(atm?,WITHDRAW)

send(atm,OK)send(atm,FAILED)

send(atm,OK)

Extracted Interface

Corresponding Sets In Example

First Conformance Condition

For Each Corresponding Set Of States

Messages Sent From States In Extracted Interface Must Be A Subset of Messages Sent From States In Original Interface

send(c,OK)send(c,FAILED)send(c,OK)

Extracted Interface Original Interface

Second Conformance Condition

For Each Corresponding Set Of States

Messages Received In States In Extracted Interface Must Be A Subset of Messages Received In States In Original Interface

recv(c?,OK)

Original Interface

recv(c?,OK)

Extracted Interface

recv(c?,FAILED)

Third Conformance Condition

For Each Corresponding Set Of States

If Receptive States Of Original Interface Must Receive One Of A Set Of Messages, Receptive States Of The Extracted

Interface Must Also Receive One Of That Set Of Messages

recv(c?,OK)

Original Interface

recv(c?,OK)recv(c?,MSG)recv(c?,OK)

Extracted Interface

Final Conformance Conditions

For Each Corresponding Set Of States

• If Original Interface Always Sends A Message

• Extracted Interface Must Always Send A Message

• If Original Interface Always Reaches A Receptive State

• Extracted Interface Must Always Reach A Receptive State

• If Original Interface Always Reaches A Stable State

• Extracted Interface Must Always Reach A Stable State

Original Interface

recv(atm?,DEPOSIT) recv(atm?,WITHDRAW)

send(atm,OK)send(atm,FAILED)send(atm,OK)

recv(atm?,DEPOSIT) recv(atm?,WITHDRAW)

send(atm,OK)send(atm,FAILED)

send(atm,OK)

Extracted Interface

Does Extracted Interface Conform To Original Interface?

Implementing ATM

• Interface Between Customer and Bank

• Model Customer As Simply Another Component

• Customer Actions Modeled As Message Sends

• Physical Actions Translate Directly Into Message Sends

• Example

• Customer Pushes the Deposit Button

• System Internally Generates

send(atm, DEPOSIT)

• Customer Hits 8 Digit On Keypad

• System Internally Generates

send(atm, DIGIT, 8)

ATM Primitives

void get_amount(int * amount) {

*amount = 0;

loop {

select {

recv(DIGIT,&d) -> {

*amount = (*amount * 10) + d;

}

recv(DONE) -> break;

}

}

}

ATM Implementationloop { get_account(&account);

select {

recv(DEPOSIT) -> { get_amount(&amount);

send(bank,DEPOSIT, account, amount);

recv(bank?, OK)-> { Confirm Deposit }

}

recv(WITHDRAW) -> { get_amount(&amount);

send(bank, WITHDRAW, account, amount);

select {

recv(bank?,OK) -> { Dispense Cash }

recv(bank?, FAILED) -> { Generate Error Message }

}

}

}}

ATM Message Type Information

• User Actions

• recv(DEPOSIT)

• recv(WITHDRAW)

• recv(DIGIT, int?)

• recv(DONE)

• Sends To and Receives From Bank

• send(bank, DEPOSIT, int, int)

• send(bank, WITHDRAW, int, int)

• recv(component?, OK)

• recv(component?, FAILED)

ATM Message Sequence Information

recv(DIGIT)

recv(DONE)

recv(DEPOSIT) recv(WITHDRAW)

send(bank,DEPOSIT)

send(bank,WITHDRAW)

recv(FAILED)

recv(OK) recv(OK)

recv(DIGIT)

recv(DONE)

recv(DIGIT)

recv(DONE)

Automated Testing And Verification

• Compose Interfaces

• Simulate to Derive All Possible System States

• Flag Potentially Erroneous States

• A Message Sent But Never Will Be Received

• User Messages Treated Specially

• Any Sequence of User Actions Possible

• User Actions Processed Only In Quiescent System States

Simulation Reveals Potential Problem In Example

• Customer May Back Out of Transaction

• Customer Starts A Deposit

• System Expects to Input Amount to Deposit

• But Customer Hits Withdrawl Button

• System Does Not Handle Event

• Programming Mismatch

• Programmers Reason With Expected Sequences, But

• Program Must Correctly Handle Exceptional Sequences

• Standard Constructs Do Not Support Construction of Robust User Interfaces

A Construct For Building Robust User Interfaces

• Goals

• Preserve Ability To Reason With Expected Sequences

• Easily Augment Program For Exceptional Sequences

• Reseting Select Construct

• Same Syntax As Select

• Same Behavior As Select For Expected Sequences

• Unselected Receive Alternatives Stay Enabled

• If Customer Generates Exceptional Action

• Implementation Resets Active Alternative

• Starts Newly Selected Alternative

• Reset Actions - Executed When Alternative is Reset

Reseting Select Construct

resetSelect {

recv(DEPOSIT) -> { get_amount(&amount);

send(bank,DEPOSIT, account, amount);

recv(bank?, OK)-> { Confirm Deposit }

}

recv(WITHDRAW) -> { get_amount(&amount);

send(bank, WITHDRAW, account, amount);

select {

recv(bank?,OK) -> { Dispense Cash }

recv(bank?, FAILED) -> { Generate Error Message }

}

}

recv(DIGIT,d?) -> { Print Error Message }

recv(DONE) -> { Print Error Message }

Comparison With Standard Methods

• Event Loop

• loop { wait_event(&e); process_event(e); }

• System State Encoded in Global Variables

• Demultiplexing Required To Determine Correct Action

• Difficult To Determine if All Events Handled Correctly

• Proposed Approach

• Supports Use of Standard Program Constructs

• Standard Flow of Control, Local State

• Semantically Related Code Appears Together

• Easy To Write Programs That Handle Events Correctly

• Easy To Determine if All Events Handled Correctly

Conclusion

• Program Analysis Techniques Can Help Programmers Develop Robust Distributed Systems

• Include Sequencing Information in Interface

• Automatic Interface Extraction

• Automatic Verification of Interoperability

• Interaction With User

• Model User As Another Component

• Novel Construct For Robust User Interfaces

Potential Scenarios

• System Developed From Scratch

• Developer of ATM Software Needs to Know

• Bank Interface

• Reasonable User Interface

• Bank Software Developer Needs to Know ATM Interface

• Bank Contracts For A New Kind of ATM

• New ATM Will Interact With Existing Bank Software

• ATM Software Developer Needs to Know Bank Interface

• Bank Unwilling Release Source Code

ATM Message Sequence Information

recv(DEPOSIT) recv(WITHDRAW)

send(bank,DEPOSIT)

send(bank,WITHDRAW)

get_account

get_amount get_amountrecv(OK)

recv(FAILED)

recv(OK)

Interface Uses

• Documentation During Development

• To Test That Components Correctly Implement Interfaces

• Analyze Program to Automatically Extract Interface

• Test if Interfaces Are Equivalent

• To Drive Automated Testing and Verification

• Compose Components

• Simulate to Derive All Possible System States

• Flag Potentially Erroneous States

• User Messages Treated Differently

• Any Sequence of User Actions Possible

• User Actions Processed Only In Quiescent States