High Assurance SOA-Based Systems Engineering University of Texas at Dallas

High Assurance SOA-Based High Assurance SOA-Based Systems EngineeringSystems Engineering

University of Texas at DallasUniversity of Texas at Dallas

Issues in Developing HA SOA-based SystemsIssues in Developing HA SOA-based Systems

HA SOA Infrastructure

HA Service Composition

HA Service Development

HA SOA-based Systems

Component Technologies

Adaptive Monitoring &

Diagnosis

Target System Dynamic

Adaptation

HA SOA-based System Development

Continuous Monitoring & Dynamic Adaptation

SOA-based System V&V

SOA Technologiesreusable


Component-basedHA System Development

Technologies

Component QoS Property

Evaluation

Component Certification (functional)

Component Repository

QoS-driven Component Composition

System Certification

Planning-basedPattern-guided Composition

QoS-DrivenComposition

Analysis

QoS-driven Component

Parameterization

QoS-Driven Component ParameterizationQoS-Driven Component Parameterization

GoalMaking components reconfigurable for QoS tradeoffs

Steps Identify variables that can be configurable parameters

Which, when set differently, yield different QoS behaviorsRequire expert knowledge for configurable parameter

identificationAdapt the component to incorporate these configurable

parametersMechanical

Measure the QoS tradeoffsWhen composing components, these measurement can be used to

help with component selection and parameter setting


Steps Identify variables that can be configurable parameters

Require expert knowledge for configurable parameter identification

Use a rule-based parameter identification approach

Parsing

QoS-R componentj

Rulebase

Componentj

Inference

Identification Rules

User validation

Rule updates

Component Adaptation

71 rules in the rule base 32 for time-quality tradeoffs4 for time-space tradeoffs13 for space-quality tradeoffsOther auxiliary rules

Configurable Parameter Identification

Facts


Suggested actionIdentified configurable parameters

Source code of the component


Case studyNumerical computation library (338 components)

Manual: 126 configurable parameters identifiedTool: 140 parameters identified

14 are not really configurable parameters

AMR speech codec library (112 components)Manual: 23 configurable parameters identifiedTool: 26 parameters identified

3 are not really configurable parameters


PerformanceManual versus tool: weeks versus minutes



Technologies


Evaluation






Analysis


Parameterization


Planning-based Pattern-guided CompositionPlanning-based Pattern-guided Composition

GoalReduce development cost and timeBy automatically compose components into systems

Fully automation: not yetAs much automation as possible

ApproachUse planning technique to deduce composition

Planning yields sequential stepsHow to drive programs

Use code patterns to guide the planning processCode patterns define how the components should be invoked and

what are the effects for different invocation sequences

Planning Technique for CompositionPlanning Technique for Composition

PlanningGo(A,B) :- Go(A,C), Go(C,D), Go(D,B)How about Go(x, y)Planner generates a path, not a program

Using planner to generate programsNeed to handle conditionNeed to handle loopNeed to handle parameters

Pattern-guided CompositionPattern-guided Composition

Common code pattern operatorsConcatenate

Connect two (or more) code patternspost-condition(P2) precondition(P1)

Encryption Send


Common code pattern operatorsSplice

Interleave the internal code of two code patternsTo identify the location for interleavingThe two patterns have to have

BEGIN

loop stmts endloop

ENDThe dependency determines the order for interleaving


Example for the splice operator

B:

Wri

te-s

oket

A:

Rea

d-f

ile

*file.open(*file_name)

*data = *file.read()

*file.close()

[ *cond = false ]

[ *cond = true ]

*socket.open(*socket_name)

*socket.write()

*socket.close()

[ *cond = true ]

[ *cond = false ]


*socket.write()

*socket.close()



*file.close()

[ *cond = false ][ *cond = true ]

Splice (A,B)


Common code pattern operators Inverse

Create the converse code for a code patternExamples: read/write, encrypt/decrypt, send/receive

Encryption Send Receive Decryption


Example for the inverse operator


*socket.write()

*socket.close()



*file.close()

[ *cond = false ]


*file.write()

*socket.close()


*data = *socket.read()

*file.close()

[ *cond = true ][ *cond = false ]

Together it is afile transfer program

Read-write invert} {Order Invert

[ *cond = true ]


Convert code patterns and operators to rulesRules are used by the planner for reasoning

MEA-Garph based Loop/Condition capable

Planner


Components Code PatternsPlanner R

ulebase

System Goal Spec

Composed System


Repository of patterns

Generated Codes



Technologies


Evaluation






Parameterization



Analysis

QoS-Driven Composition AnalysisQoS-Driven Composition Analysis

GoalMost component composition techniques focus on functional

requirementsComposed system should also satisfy QoS requirements

AppraochQoS-driven composition analysisSelecting proper assembly of components so that QoS

requirements can be satisfiedProperly setting the parameters of configurable components

Some components are configurable for QoS tradeoffs

How to make such decision?



Component

Funcational Spec

QoS Spec

System Design

QoS Requirements

AB C

ED

F

Which components to use for A-F? How to configure the components?

Repository of Aggregate Functions

Which composition can results in the best QoS? Choose that composition

We know the QoS properties of the componentsP(A), P(B), …, P(F)

How to derive system QoS properties?Need aggregate functions

f (P(A), P(B), …, P(F))

AF for Time Composition

AF for Reliability

Composition

AF for Com. Quality

Composition. . . . . .

Large design spaceMany component selections and Many parameter setting choices

Need efficient algorithm to help with decision makingUse genetic algorithm

Design Decision Process

candidatesbetter

candidatesnew

candidates

MutationCrossover

Evaluate


Case study system: Security media gatewayProvide transcoding and encryption services

Packetization (PA)AMR Encoder (AE)

Packet Receiver and Session Conditioner(PS)

SRTP Sender (SS)

Depacketization (DP)

SRTP Receiver (SR)

AMR Decoder(AD)

Packet Forwarder (PF)

Internet

Media Security Gateway

Client

Intranet

Client Client…

Internet

Media Security Gateway

Client Client Client…Intranet


Case study systemConfigurable parameters for packetization component

Intranet

Parameter (Notation) Domain Comment

octet-align flag (OA) 0: Bandwidth-efficient mode1: Octet-aligned mode

Number of frames per packet (N) 40 N 1

Forward Error Correction (FEC) flag (FEC)

1: with FEC, 0: without If FEC = 1, RS = 0 and I = 0

Packet number of a FEC block (Fn) Fn > 1

Media packet number of a FEC block (Fm) Fn >Fm > 0

Retransmission Sliding Window (RSW) flag (RSW)

1: with RSW, 0: without If RSW = 1, FEC = 0 and I = 0. The length of the sliding window is N. If RSW = 1, N 2.

Interleaving flag (I) 1: with interleaving, 0: without If I = 1, OA = 1, and FEC = 0, RSW = 0

Interleaving length (L) L 2

Robust sorting (RS) flag (RS) 1: with robust sorting, 0: without

If RS = 1, OA = 1 and N > 1

CRC flag (CRC) 1: with CRC, 0: without If CRC = 1, OA = 1


Case study systemQoS properties for packetization component

PA.ET = OAPA.EToa + (1-OA) PA.ETbe

DP.ET = OADP.EToa + (1-OA) DP.ETbe

PA.delay = { (N-1)(1-RSW)(1-I) + RSW(N/2-1) + I(N-1)L } * 20ms

PA.PS = OA PA.PSoa + (1-OA) PA.PSbe

PA.RP = RPFEC FEC + RPRSW RSW + (1-RSW) (1-FEC) LP

Intranet


Case study systemSystem QoS requirements

Objective-based requirements: minimize system bandwidth requirement optimize the voice quality

Constraint-based requirements: guarantee each session has an acceptable voice quality guarantee that certain percentage sessions can receive the strongest

security service

Intranet


Case study systemDesign space exploration

Intranet







Diagnosis


Adaptation





SOA Technologies



Technologies


Evaluation






Parameterization



Analysis

SOA-basedHA System Development

Technologies

Web Services & UDDI

Planning-basedService

Composition

Service QoS Property

Evaluation

Service Certification (functional)

QoS-driven Service

Parameterization

UML Technology OWL-S TechnologyQoS extensions: OWL-SQ







Diagnosis


Adaptation




SOA Technologies


High Assurance SOA InfrastructureHigh Assurance SOA Infrastructure

Fault-tolerance, reliability, availability, security, survivability, real-time, confidentiality, etc.

Service replicationSupport service fault-tolerance, availability, integrityAt the same time, should satisfy timing requirements

Security policyRole-based access control and delegation

Data partitioningSupport data confidentiality, availability, integrity

Real-time SOA…

A B


Service replicationProblems

Expensive communication All to all request/response

SolutionCoordinator-follower approachOnly coordinator sends requestOnly coordinator sends responseKeep track of certification trail (CT)Periodically exchange and exam CT

A1

A2

A3

B1

B2

B3


Data partitioningSystem can have sophisticated access control policies If the storage server is compromised, all policies are

uselessData replication

Necessary for data availabilityBut increase the security risk

If one server is compromised data compromised

Encrypt replicas Push the burden to key management

Partition and disperse data to ensure secure storageAdditional shares to offer data availability, integrity


Data partitioning (m, t) threshold partitioning scheme

Total m shares in the systemReconstruct data with t sharesIf adversary obtain < t shares no information revealed

Need to maintain data share location informationUse peer-to-peer DHT approachTwo layer DHT for real-time access efficiency


Service replication + Data partitioningEach server holds a data shareUse multi-party computation algorithm for coordinated

computationWhen A invokes B

A group reshares and sends to each member of BAll to all communicationBetter protocol? Not yet


PerformanceTo complete a complicated task

Need to compose many services (service chain)The selected services may be far apart and the communication cost

may be high

Service migrationTo reduce communication costSome services are light-weighted migratableSome services has data/resource dependencies non-migratableWhere to migrate migratable resources to minimize the costUse EA to find best solution








Adaptation




SOA Technologies


Diagnosis

Adaptive Monitoring and DiagnosisAdaptive Monitoring and Diagnosis

Target systemFocus on achieving system goalTarget system components: {ci | for all i}

Health monitoring and diagnosis (HMD) systemManage the health of the target systemConsists of sensors, analysis, diagnosis, prognosis software

For convenience, use sensors to represent all HMD components

HMD Sensors: {i | for all i}

HMD system consume significant resources Need to be adaptive to conserve resources


Model the system as a phased-mission systemsDifferent phases may use different target system

components more extensivelyHence, different HMD components become more critical

Unexpected events unexpected phase transitionsUnexpected environment changesUnsatisfactory target system output qualityUnsatisfactory target system performanceFailure of components (HMD or target system)


What can be adapted in the HMD systemSensor/software activation frequency

Can also disable sensors to conserve resources

Configurable sensor/software parametersE.g., taking information at a lower resolutionE.g., analyze, diagnosis, prognosis at a lower resolution

Alternate sensor/software for different diagnosis qualityTest different aspects of the componentsSome times may require on-the-fly generation of the HMD

software

Adaptive HMD ApproachAdaptive HMD Approach

Construct FSM To associate sensors with target system components

Many to many associationAssociate based on rules

Define system diagnosis quality Diagnosability degree Diagnosis sensitivity Diagnosis timeliness

Other factors System resource constraints IVHM component resource consumptions Target system component criticality

Adaptive HMD ApproachAdaptive HMD Approach

FSMThe matrix describes the relation between components and sensors (based on rules).

For example, consider rule 1when 1 and 2 are activated c1 is faulty if the measured data does not satisfy rule 1

Adaptive HMD DemoAdaptive HMD Demo

Demo 1Phased-mission systemCompute sensor activation frequency, which

Optimize diagnosis qualitySatisfy resource constraints

Demo 2Adaptive selection of monitors

For diagnosis quality and time, power consumption tradeoff

Adaptive monitor generationGenerate monitor from target system specification


Demo 2: tracking systemSystem goal:

Camera should always align with a pre-specified object

T1Find the coordinates of the object from the input imageInput: image from last roundOutput: (x, y), which has the object on it

T2Compute the degrees of the angles the camera should moveInput: T1’s outputOutput: and


Demo 2: tracking systemT1: Find the coordinates of the objectT2: Compute the degrees of the angles for the cameraM1 (monitor for T1)

Prior knowledge: the speed of the objectCompute the region the object can beCheck within the region to find whether a closer match of the

object presents (if so, T1 is incorrect)Input: image and T1’ output

M2 (monitor for T2)Perform the reverse computation


Demo 2: tracking systemT1: Find the coordinates of the objectT2: Compute the degrees of the angles for the cameraM1’ (alternate monitor for T1)

Prior knowledge of the object speed limitationConsider the object speedUse the previous round position and current round position to

compute the object speedIf the speed is within the limit, then OK

M2’ (monitor for T2)From and , compute new camera positionCheck if T1’s output coordinate is within the camera rangeInput: image and T1’s and T2’s output

Documents

High Assurance SOA-Based Systems Engineering University of Texas at Dallas