SERVICEDDS A framework for soft real-time systems

integration into dynamic P2P architectures

Tesis realizada por: Jose Ángel Dianes Santos

Dirigida por: Manuel Díaz Rodríguez Bartolome Rubio Muñoz

CONTENTS

ServiceDDS 3

• Part I – Introduction

• Enterprise Integration and Quality of Service (QoS)

•  Integration issues

• Existing solutions

• Data Distribution Service (DDS)

•  eXtensible Mesaging and Presence Protocol (XMPP)

• Real Time Specification for Java (RTSJ)

ServiceDDS 4

• Part II - The ServiceDDS framework

• Overview

• Service Model

•  Topic Transformation Functions (TTF)

• Web Access

• Real Time Support

• Performance

ServiceDDS 5

• Part III – Conclusions

• Contributions

• Weaknesses

•  Future Work

• Published Papers

ServiceDDS 6

ENTERPRISE INTEGRATION AND QUALITY OF SERVICE Part I - Introduction

ServiceDDS 7

Integrated applications are independent applications that can run by themselves but that coordinate with each

other in a loosely coupled way.

An enterprise is a collection of organizations having a common goal.

ServiceDDS 8

We refer to QoS when talking about:

•  Missing service or data

•  Service or data delivery timing and delay

•  Service and data delivery reliability

ServiceDDS 9

Quality of Service can be:

•  Specified

•  Negotiated

•  Monitored

•  Enforced

ServiceDDS 10

ENTERPRISE INTEGRATION ISSUES Part I - Introduction

ServiceDDS 11

Heterogeneity

Independent business processes Heterogeneous applications

Different technology infrastructure (HW & SW)

ServiceDDS 12

Independent parts

Third party applications They can change independently (third party)

They cannot be changed by the integration engineer

ServiceDDS 13

Scalability

Data throughput Participants

ServiceDDS 14

QoS Semantics/Negotiation

QoS specification QoS Negotiation QoS monitoring

QoS enforcement

ServiceDDS 15

Information Scope

where is the information available? or

who will receive it? in

dynamic and densely distributed systems

ServiceDDS 16

Access Control

who has the right to access the information?

ServiceDDS 17

Transient Behaviour

how to deal with intermittent and faulty applications?

ServiceDDS 18

EXISTING SOLUTIONS Part I - Introduction

ServiceDDS 19

File Sharing

allows very loosely coupled interaction

But lacks of: operation semantics

timeliness (i.e. notify new data) naming or format agreements

data format enforcement

ServiceDDS 20

Shared Database

improves data consistency and semantics

Problems: unified enterprise data schema definition

performance bottleneck low general performance

ServiceDDS 21

Remote Procedure Invocation

encapsulates application data using operations direct interaction (not bottleneck)

Problems:

tightly coupled synchronous interactions ->

less fault tolerance and scalability

ServiceDDS 22

Messaging

Asynchronous Well formatted

Reliable Application independent

High performance

ServiceDDS 23

DATA DISTRIBUTION SERVICE (DDS) Part I - Introduction

ServiceDDS 24

OMG standard Real-Time Publish/Subscribe (RTPS)

Data Centric Publish Subscribe Pub/Subs

App

Data Logic Recosntruction Layer OO Pub/Subs App

RTPS Wire Interoperability RTPS Wire Interoperability

UDP

ServiceDDS 25

QoS-enabled distributed data bus

ServiceDDS 26

Allows multiple QoS parameters

Reliability/Best effort Deadline

Transport priority Persistence

History

ServiceDDS 27

EXTENSIBLE MESSAGING AND PRESENCE PROTOCOL (XMPP) Part I - Introduction

ServiceDDS 28

eXtensible Messaging and Presence Protocol

also know as Jabber used in Google Talk (among others)

ServiceDDS 29

“Real-Time” oriented

XMLStream – Connection sending a XML document Promotes frequent interactions

ServiceDDS 30

Extensible

Stanzas – XML elements interchanged in a XMLStream

Types:

message, presence, info/query, errors. They can be extended

ServiceDDS 31

Symmetric

Client-Server – Different roles same interactions: Create a XMLStream + send Stanzas

Push interactions: allow one way messages

ServiceDDS 32

REAL-TIME SPECIFICATION FOR JAVA (RTSJ) Part I - Introduction

ServiceDDS 33

Summary of RTSJ additions:

• Real-Time memory management • High resolution clocks and time values • Schedulable objects and real-time scheduling • Real-time priorities • Asynchronous timers and event handlers • Asynchronous transfer of control • Physical memory access

ServiceDDS 34

OVERVIEW Part II – The ServiceDDS Framework

ServiceDDS 35

ServiceDDS is a framework for the integration of QoS independent applications

Based on standards:

DDS, RTSJ, and XMPP, XML Schema

Multi-paradigm: publish/subscribe, CEP, SOA

ServiceDDS 36

ServiceDDS Layered View

ServiceDDS 37

Purpose

ServiceDDS provides run-time mechanisms that allow independent applications

with QoS requirements to interact in a loosely coupled way

ServiceDDS 38

Infrastructure

ServiceDDS mechanisms are based on DDS and other standard technologies (XMPP, RTSJ, XML)

ServiceDDS 39

Paradigms

together with data-centric publish/subscribe, it offers SOA and EDA.

ServiceDDS 40

Mechanisms

Peers and groups: organize participants and control access.

ServiceDDS 41

Mechanisms

Topic Transformation Functions: allow complex event detection and processing.

ServiceDDS 42

Mechanisms

Services: allow synchronous interactions and remote

functionality execution.

ServiceDDS 43

Mechanisms

Web access: Allow publish/subscribe

in DDS data space using XMPP

ServiceDDS 44

Mechanisms

Real-Time Support: Latency calculation support

and Memory management support

ServiceDDS 45

SERVICE MODEL Part II – The ServiceDDS Framework

ServiceDDS 46

Peer - basic entry point for deploying ServiceDDS apps: ◦  A peer can use every ServiceDDS interaction

mechanism. Peers belong to groups where they interact with other peers: ◦  Groups provide access control* and organization.

ServiceDDS 47

Join group implementation using topics

ServiceDDS 48

Services define operations that can be synchronously invoked by other peers

Can have associated QoS parameters

ServiceDDS 49

Services are described by contracts

• Serice name • Operations and QoS params • Properties (<key,value>, used for discovery) • Etc.

Are defined using XML

(syntax checked using XSD/JAXB)

ServiceDDS 50

Service use requires two previous steps

1.  Discovery: service contract vs contract template matching.

2.  Negotiation or admission control.

ServiceDDS 51

Service discovery and invocation is implemented using DDS topics

Decoupled services: service binding is absolutely dynamic

ServiceDDS 52

NtoN services

Multiple providers can attend and answer to the same invocation.

Multiple clients can be waiting or listening to the result of a single invocation (waitForResult and listenForResult).

ServiceDDS 53

Service invocation implementation

ServiceDDS 54

Service discovery implementation

ServiceDDS 55

TOPIC TRANSFORMATION FUNCTIONS Part II – The ServiceDDS Framework

ServiceDDS 56

TTFs bring EDA and CEP concepts to ServiceDDS

Event: a new topic sample is written Complex events: inferred from multiple events

ServiceDDS 57

TTF structure:

•  Input topics: simple event detection • Output topics: complex event generation •  Transformation function: the inference

ServiceDDS 58

WEB ACCESS Part II – The ServiceDDS Framework

ServiceDDS 59

Goal: web access to DDS global data space

Under the following conditions: • QoS friendly •  based on standards - no need of external libraries •  no session information on the client side •  reliable connections •  allow DDS usual interactions

ServiceDDS 60

Architecture – XMPP Server Plugin

ServiceDDS 61

Standard XMPP stanzas:

<message/> point-to-point data push mechanism, similar to email

<presence/>

broadcast mechanism about source entity availability

Info/Query <iq/> request-response mechanism similar to HTTP

(get, set, result, and error).

ServiceDDS 62

ServiceDDS Web access commands are extensions of the standard XMPP stanzas

<iq type=”result or error” from=”source_peer_id”> <sdds>

Additional command info…

</sdds>

</iq>

ServiceDDS 63

Group Management

<xs:element name=”join”> <xs:complexType> <xs:element name=”group” type=”xs:string”/> <xs:element name=”user” type=”xs:string”/> <xs:element name=”password” type=”xs:string”/> </xs:complexType> <xs:element>

<xs:element name=”leave”> <xs:complexType> <xs:element name=”group” type=”xs:string”/> <xs:element name=”user” type=”xs:string”/> <xs:element name=”password” type=”xs:string”/> </xs:complexType> <xs:element>

ServiceDDS 64

Topic management: New

<xs:element name=”new”> <xs:complexType> <xs:element name=”servicetopic” type=”xs:string”/> <xs:element name=”topicname” type=”xs:string”/> <xs:element name=”group” type=”xs:string”/> <xs:element name=”datatype” type=”named_struc”/> <xs:element name=”qos” minOccurences=”0”> <xs:complexType> <xs:element name=”deadline” type=”xs:duration” minOccurences=”0”> <xs:element name=”reliability” type=”xs:string” minOccurences=”0”> <xs:element name=”history” type=”xs:integer” minOccurences=”0”> <xs:element name=”latency_budget” type=”xs:duration” minOccurences=”0”> </xs:complexType> </xs:element> </xs:complexType> </xs:element>

ServiceDDS 65

Topic Management: read/write

<xs:element name=”read”> <xs:complexType> <xs:element name=”servicetopic” type=”xs:string”/> </xs:complexType> <xs:element>

<xs:element name=”write”> <xs:complexType> <xs:element name=”servicetopic” type=”xs:string”/> <xs:element name=”sample” type=”named_struc”/> </xs:complexType> <xs:element>

ServiceDDS 66

Topic Management: read result

<xs:element name=”read_result”> <xs:complexType> <xs:element name=”servicetopic” type=”xs:string”/> <xs:element name=”sample” type=”named_struc”/ minOccurences=”0” maxOccurences=”unbounded”> </xs:complexType> </xs:element>

ServiceDDS 67

Topic Management: listen

<xs:element name=”listen”> <xs:complexType> <xs:element name=”servicetopic” type=”xs:string”/> </xs:complexType> <xs:element>

ServiceDDS 68

Topic Management: listen (events)

<message/> extension

<xs:element name=”on_data_available”> <xs:complexType> <xs:element name=”servicetopic” type=”xs:string”/> <xs:element name=”sample” type=”named_struc”/ minOccurences=”0” maxOccurences=”unbounded”> </xs:complexType> </xs:element>

… <xs:element name=”on_requested_deadline_missed”> … … <xs:element name=”on_sample_lost”> …

ServiceDDS 69

SCHEDULING ANALYSIS SUPPORT Part II – The ServiceDDS Framework

ServiceDDS 70

ServiceDDS provides

scheduling support to calculate latency

of DDS-distributed systems

ServiceDDS 71

ServiceDDS itself doesn’t provide:

•  analysis algorithms, •  schedulers, •  or priority assignment policies.

Just the runtime information

for them to work!

ServiceDDS 72

Priority-based network access [Davis et al 2007]

Parameters (worst case latency time):

•  Pm: the priority of message m. •  Jm: the jitter of queuing message m. •  Dm: the deadline of message m. •  Cm: the cost of transmitting message m. •  Tm: the period of message m. •  τbit: the time resolution

ServiceDDS 73

Latency to DDS parameter mapping:

• Pm : DDS transport_priority • Dm = Tm : DDS deadline • Cm : will depend on the sample size (Sm), on DDS

implementation, on the transport bandwidth, and on the number of topic subscribers to the topic.

ServiceDDS 74

RTSJ Entities & Parameters

ServiceDDS 75

Internal Topics (distributed system state propagation)

ServiceDDS 76

State propagation

ServiceDDS 77

Service Support (summary, don’t explain)

ServiceDDS 78

MEMORY MANAGEMENT Part II – The ServiceDDS Framework

ServiceDDS 79

ServiceDDS uses RT garbage collection for memory management in dynamic systems.

ServiceDDS 80

It is based on garbage calculation using: • Memory contracts for services

• Profiling of client code before deployment

• Setting GC cycle on runtime based on load

• Admission control of new requests

• Memory enforcement mechanism

ServiceDDS 81

ServiceDDS 82

ServiceDDS 83

ServiceDDS 84

ServiceDDS 85

PERFORMANCE: TOPICS Part II – The ServiceDDS Framework

ServiceDDS 86

Test deployment

ServiceDDS 87

Hardware details

ServiceDDS 88

Effects of KEEP_LAST_HISTORY_QOS Increasing server writing frequency (dec. Period)

ServiceDDS 89

Deadline misses: Server Period vs Number of readers

ServiceDDS 90

PERFORMANCE: SERVICES Part II – The ServiceDDS Framework

ServiceDDS 91

Test conditions

•  An operation ‘delay()’ simulates the WCET in ms.

•  A server provides this operation: •  either as a remote RMI interface •  or as a ServiceDDS service operation.

•  A client invokes this operation using RMI or ServiceDDS.

•  Operation invoked 300 times. Total computation time: •  300 * WCET + overhead introduced by RMI/ServiceDDS. •  This overhead is represented in the Y axis of Fig. 28.

•  Test repeated 100 times to avoid extreme situations.

•  Test performed for different delay/WCET values (X axis of Fig. 28).

ServiceDDS 92

Overhead

ServiceDDS 93

Parallel execution (ServiceDDS only)

ServiceDDS 94

CONTRIBUTIONS Part III – Conclusions

ServiceDDS 95

• A framework for enterprise integration of QoS applications

• A loosely coupled Service Model for DDS based systems

• A push & standard-based Web access mechanism to the DDS global data space

• Support for complex event processing

• Distributed RT systems support thanks to latency calculation support and real-time garbage collection.

ServiceDDS 96

WEAKNESSES Part III – Conclusions

ServiceDDS 97

•  Implementation dependencies (DDS, RTSJ, garbage collectors)

•  Lots of proof-of-concept code

•  Tied to Java, despite DDS/XMPP being platform independent

• XMPP is not the most used web standard… but is very convenient in our application domain!

ServiceDDS 98

FUTURE WORK Part III – Conclusions

ServiceDDS 99

•  Implementation efforts

•  RT analysis fine details (e.g. Discovery time)

•  Experiment with RTSJ-based DDS implementations (e.g. RTI-DDS)

•  Alternatives to Java (i.e. POSIX) for applications

ServiceDDS 100

Published Papers •  J. A. Dianes, M. Díaz, B. Rubio, “Using standards to integrate soft-

real time components into dynamic p2p distributed architectures” en Computer Standards & Interfaces (Elsevier). Feb 2012.

•  J. A. Dianes, M. Díaz, B. Rubio, “ServiceDDS: A framework for real-time systems integration” en IEEE ISORC 2010. Carmona, Sevilla. Mayo 2010.

•  J. A. Dianes, M. Díaz, B. Rubio, “Habitat: A DDS-based service framework for smart spaces” en IEEE International Conference on Intelligent Computer Communication 2010. Cluj-Napoca, Romania. Agosto 2010.

•  M. Albano, A. Brogi, R. Popescu, M. Díaz, J. A. Dianes, “Towards Secure Middleware for Embedded Peer-to-Peer Systems: Objectives & Requirements” en UbiComp 2007. Innsbruck, Austria.

ServiceDDS 101

Published Papers •  T. Richardson, A. Wellings, J. A. Dianes, M. Díaz, “Providing Temporal

Isolation in the OSGi Framework” Proc. ACM International Workshopt on Java Technologies for Real-Time and Embedded Systems (JTRES 09). Sept. 2009, pp. 1-10.

•  T. Richardson, A. Wellings, J. A. Dianes, M. Díaz, “Towards Memory Management for Service-Oriented Real-Time Systems” Proc. ACM International Workshop on Java Technologies for Real-Time and Embedded Systems (JTRES 10). Aug. 2010

ServiceDDS 102

QUESTIONS

ServiceDDS 103