Validation of Service Oriented Computing DEVS Simulation Models

Hessam Sarjoughian and Mohammed Muqsith Arizona Center for Integrative Modeling & Simulation School of Computing, Informatics, and Decision Systems Engineering

Dazhi Huang and Stephen Yau Information Assurance Center School of Computing, Informatics, and Decision Systems Engineering

1

2

Motivation A key promise for Service Based Software Systems is

On-demand Quality of Service (QoS)

However, system design with QoS support is challenging QoS depends on

System architecture Interactions among constituent parts under a dynamic environment

Link

Link Link

Voice Communication

Service

EncryptionService

Software Software

Application Application

Software Software

Hardware Hardware

HardwareHardware

Server Server

Client Client

Hub

CommunicationCommunication

3

Motivation Design evaluations addressing QoS in Service Based Software

Systems Difficult to track & inflexible for experimentations Small-scale system QoS can be predicted using analytical

methods Complex interactions in large-scale systems complicate QoS

prediction

Simulation, in contrast to real design and implementation Offers alternate ways of understanding, development, and

experimentation Easier to configure system with repeatable experimentation

capability Early evaluation of system architecture

Simplify complex system design and evaluation Validation is generally a necessity

4

Background Service Oriented Computing (SOC)

A paradigm of computation Based on the concept of

service. Services are software entities

Loosely coupled Publishable Discoverable Composable Platform-independent

PublisherService

BrokerService

SubscriberService

13

4

5

2

publish, subscribe, discover

data service messages

Service Call

Service Response

Service Oriented Architecture (SOA) Concepts and principles toward building SOC systems Software systems based on SOA are known as Service

Based Software System (SBS)

5

SOC-DEVS Co-Design Modeling MethodologySOC-DEVS

Introduces SW/HW co-design modeling concept in SOA-Compliant DEVS (SOAD)

Provides flexible synthesis via assignment of software services to networked hardware. Models service interaction through networked hardware

SW/HW Co-Design

SBS design

Service Based

SoftwareSystem

Partition Flexible Map

SOA Compliant

Service

Hardware

SB

S C

o-Design

6

SOC-DEVS : Component abstractions Software Layer

swService Generic software layer Operations constrained by

hardware resource Broker, Publisher, Subscriber

SOA complaint service models extend basic swService

Hardware Layer Processor

CPU CPU cycles required for service

execution Memory amount consumed

during service execution Transport Unit

Directs messages to/from swServices

Interacts with lower layer Network Interface Controller

Transmits/ receives packets, frames Queue/deque packets, frames

Link Models physical media Interconnects multiple network

switches Network Switch, Router

Interconnects networks Routes packets

System Service Mapping Provides flexible assignment

of services to processors

Hardware

SOA Compliant

Service

Flexible Map

7

SOC-DEVS: Service Interactions swService accounts for two basic aspects

Operations Denotes functionality provided by the service

Communications Denotes service to service interaction capability

SSM

Operations

Communications

Jobs CPU

Transport UnitMessages

Processor 1NIC

swService 1

Models service to service interaction through hardware layer Jobs

Job (cycles/sec, Mbytes of memory) represents computational load for operations Messages

Message (MsgType, Size) represents communication load for communications

SSM

Jobs

MessagesOperations

Communications

swService 1 Processor M

Jobs

Messages

Router/Switch

swService k

Operations

Communications

CPU

Transport Unit

NIC Link

LinkProcessor NNIC

CPU

Transport Unit

swService accounts for two basic aspects Operations – Denotes functionality provided by the service Communications – Denotes service to service interaction capability

Models service to service interaction through hardware layer Jobs – Job (cycles/sec, Mbytes of memory) represents computational load for operations Messages – Message (MsgType, Size) represents communication load for communications

SOC-DEVS: Networked Interactions

9

SOC-DEVS: Simulation Example Real Voice Communication

System Streams End-to-End VoIP audio data to

subscribers Supports audio sampling rates and data

encryption 44.1 ~ 220.5 KHz 256 Key DES encoding 0% or 100% encryption

Supports multiple subscribers simultaneously System QoS is measured by the

VCS throughput Inter data frame delay

VCS Modeling in SOC-DEVS The real VCS is modeled

Models End-to-End VoIP audio data with sampling rates and data encryption 44.1 ~ 220.5 KHz 256 Key DES encoding 0% or 100% encryption

Simulation testbed is configured with similar configurations as in real VCS

Category Real System

Simulation System

Processor (CPU, Memory, Network Card)

2.2 GHz,1024 MB, 100 Mbps

2.2 GHz,1024MB,100Mbps

Network Link Bandwidth 100 Mbps 100Mbps

Subscriber # 1-40 1-40, 100-1000

Data Collection Duration

60 sec (wall clock)

60 sec (logical clock)

Tabl

e 1:

Sys

tem

con

figur

atio

n

Real System web services are developed in C# .NET

10

Testbed The testbed consists of

Real system Voice Communication System

Support up to 40 simultaneous clients

Automated data collection mechanism Throughput Delay

Packet level tracing Netmon 3.4

Simulation system Voice Communication System

Arbitrary VCS configuration Larger scale systems

DEVS-Suite simulator Transducer based data

collection Data analysis system

MATLAB scripts

Real System

Simulation System

Data AnalysisSystem

Testbed

Data

Analysis Output

Supports experimentation, data collection and data analysis

Round Trip Delay Definition

RT (Round Trip ) delay Client request sending event to first data arrival event Consists of

Server processing delay Network delay DelayServer processing + 2xDelayNetwork

Measured at client end ET2 – ET1

VoiceComm Network Client

delaynetworkdelayserver processing

1

2

ET = Event Time

Inter Frame Time

Inter Frame Time Time interval between

two consecutive audio frame events at the VoiceComm Service

Measured at server end IFTK = FTK+1 - FTK

K ={1,…N}

Frame1Frame 2Frame 3Frame 4VoiceComm

FT4 FT3 FT2 FT1

IFT2 IFT1IFT3

Accuracy

Accuracy The ratio of Total Bytes Received w.r.t. Total Bytes Sent

A = TBR / TBS Total Bytes Received (TBR)

Aggregated data bytes received by all the clients TBR = ∑ BR (K) ; K ={1,2,…N} and denotes Client ID

Total Bytes Sent (TBS) Aggregated data bytes sent by the VoiceComm service for all the

clients TBS = ∑ BS (K) K ={1,2,…N} and denotes Client ID

VoiceComm Network Client

Client

Delayserver processing Delaynetwork

Experiment Scenario

Client requests via network for audio data from the VoiceComm service

VCS sampling rate 44.1-220.5 KHz

VCS buffer size 16K

Client number 5-20

3 machines M1, M2, M5 connected via network M2 and M5 acts as clients using

multiple threads VoiceComm service sends data

for 60 seconds to each client Data is collected at probe points

Each configuration has 10 runs Data is averaged over these 10

runs

VoiceCommClient

Network

M1

M2

VCS

1

Probe Point

Audio

2

3

Client

M5

5 ClientClient

ClientClient

15

NetworkCard (NIC)

Probe Point (2,3,5) via NetMon

NIC Driver

NDIS Driver

Probe Point (1) at VoiceCommService

Sound Card (SC)

SC Driver

SC API’s

OS

UDP/IP

HW

Real System Data Probe Points

16

Start Experiment

Invoke/Request Service

Stop Audio Data Output Event Logging

Audio Data Output Event Logging

At Probe Point 1

Service Completed?

No

Yes

Start Audio Data Output Event Logging

UDP/IP Data Event Logging

At Probe Point 2, 3

Start UDP/IP Data Event Logging

Stop NetMon

Stop ?

Yes

No

Real System: Automated Data Collection Process

•Software code•Network packet layer•Windows Performance Objects

Results

17Time accuracy: mili-seconds

18

SOC-DEVS Simulator

SOA DEVS

SOA-DEVS (SOAD) SW/HW Co-Design

SOC-DEVS

+

+SOA-Compliant

Service Models

SOA-Compliant Service Models

HardwareModels

Service model mapping to

hardware model

Experimentation platform / Future Work

19

SBS Experimentation Platform

Conclusion

Developed an approach for validating SOC-DEVS (SW/HW co-design) simulation models Automated real-time data collection Voice Communication case study

Services QoS depends on integrated software and hardware layers Validation of Service-Based Software System simulations is a

grand challenge, especially as the SW and HW interactions grow in complexity and scale

20

http://devs-suitesim.sourceforge.net

Questions?

Thank you

21

22

SOA-DEVS and SOC-DEVS: Contrasts

Limited aspect of hardware representation ( only routing logic)

Formal specification of sw/sw interaction semantics

No SW/HW separation and synthesis Capability

Service models and their interactions are specified with DEVS formalism

Detailed representation of service as well as hardware models

Formal specification of sw/hw and sw/sw interaction semantics

Support SW/HW separation and synthesis capability

Both service and hardware models as well as their interactions are specified with DEVS formalism

SOA-CompliantService Models

SOA-CompliantService Models

Hardware Models

Service timing aspect is directly specified in the

service models

Service execution time, dt = mean delay +/-

sigma

Service timing aspect is indirectly determined by the interactions with the

hardware models.

Service execution time, dt = job comletion time in

CPU= TJobs(out) – TJobs(in)

Jobs(in) Jobs(out)

SOA-DEVS SOC-DEVS

1. 1.

2. 2.