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.
Top Related