DDS Based Communication Middleware

CHAPTER 1

INTRODUCTION

“Data Distribution Service based communication middleware” to addresses the communication needs of distributed applications. Middleware placed between a software application and the operating system as shown in Figure 1.1[33]. Network middleware segregates the application from the subtle elements of the underlying computer architecture, operating system and network stack.

Figure1.1 Middleware (Software layer between OS and application)

Network middleware simplifies the development of distributed systems by allowing applications to send and receive information without having to program using lower-level protocols such as sockets and TCP or UDP/IP.

Key benefits of a middleware are:

• Reduce the likelihood of a fault.
• Perform complex one-to-many and many-to-many network communications.
• Customize application operation to meet various real-time, reliability, and Quality-of-service goals.
• Communicating application is entirely decoupled.
  1. Middleware Technology Overview

Most of the contemporary Message Oriented Middleware has been built around a well-defined and much accepted standard from OMG namely the OMG DDS (Data Distribution Services).

This section attempts to give a brief overview of this technology. The Data distribution service is an Object Management Group’s middleware standard that specifically aims to enable high-performance, real-time data between publisher and subscriber.

Advantages

• The DDS middleware is well known “publish-subscribe” communication paradigm.
• The middleware is adaptable and has a versatile structural planning that backings “auto-discovery” of new endpoint applications.
• DDS middleware has low overhead is utilized with elite systems.
• DDS based middleware supports Deterministic data delivery.
• DDS middleware is dynamically scalable depending on requirement.
• DDS middleware is productively utilizes the more data transfer capacity.
• DDS middleware not only supports one-to-one it should also provide communication for one-to-many, many-to one, and finally many-to-many communications.

Publish-subscribe applications are commonly dispersed applications with endpoint nodes that communicate with one another by sending (publishing) information and accepting (subscribing) information namelessly. Generally the main property a publisher needs so as to communicate with a subscriber is the name and meaning of the information. The publisher does not require any data about the subscriber, and the other way around.

The length of the intrigued applications recognize what information is being conveyed, publisher subscribe framework is fit for conveying that information to the fitting nodes without needing to set up individual associations. Publisher is in charge of get-together the fitting information and sending it out to every single enrolled subscriber. Subscribers are in charge of getting data from the proper publishers and exhibiting the information to the intrigued client application.

Data-centric driven correspondence gives the capacity to indicate different parameters like the rate of production, rate of membership, to what extent the information is legitimate, and numerous others. These Quality of Service (QoS) parameters permit framework architects to develop a disseminated application in view of the prerequisites for, and accessibility of, every particular bit of information.

1.2 Problem Statement for the project

The most existing conventional middlewares which are used for exchanging the data are broker oriented approach (Fig 1.2). Publishers sends the message to the most error free delivery service and more over it is send to broker and subscribers which meant to read the message should register memberships with the broker before reading the message sent by the publisher. The membership is applicable for specific message. Here the functionality of the broker is to hold and send the message from sender to receiver. The Subscribers to read the message enroll for membership for particular messages either at build, initialization or runtime. In short without the broker there is no chance for sender and receiver to exchange the message which is not a better option.

Figure 1.2 Existing Broker based Architecture

1.3 Aim of the present Project

The project aims to design communication middleware based on a data-distribution service which supports a decentralized broker-less architecture. DDS standard is a absolute data-centric publisher-subscriber message exchange approach. Here the emphasis is on client characterized information (the information model). The unit of exchange in this sort of framework is information esteem. The middleware comprehends the connection of the information and guarantees every intrigued subscriber has a right and reliable perspective of the data.

1.4 Proposed System

The proposed system for this project is a decentralized no broker approach building design for empowering consistent messages are exchanged between publisher and subscriber. Data Distribution Service is in view of the thought of a virtual “Global data space” where publishers enter the new values to the data space and subscribers read the values from the data space. A data model comprising of named topics, their client characterized information sorts and related QoS is utilized to by the DDS framework to control how data is shared. DDS connects publishers to subscribers over the information transport as demonstrated as follows.

Figure1.3 Global Data Space for DDS middleware

1.5 Purpose of this Project

The purpose of this project is development of technologies and solutions that can be leveraged for the Integration of various components built on different platform. Integration solution should be scalable to accommodate futuristic requirements in the distributed computing.

• The objective includes development of Message oriented middleware (MoM) leveraging suitably ruggedized versions of Internet protocols (TCP/IP) that are robust under tactical networking constraints which will provide seamless communication between the heterogeneous systems.

• The middleware should expose standard interfaces to which the application can be hooked and achieve desired levels of interoperability and integration with the help of XML format of messages.
• The middleware should be portable for the various operating systems.
• MoM should benefit the end user in supporting large scale system integration via communication infrastructure.

1.4 Organization of the report

This section is intended to give a brief overview of the structure of this document and the composition of each chapter.

1.5 Summary

In this chapter an overview of the project is described namely, Introduction about Data distribution service communication middleware involving definition and key benefits of middleware, Problem statement which gives main drawback of existing approach for communication between publisher and subscriber i.e. existing approaches are broker based, Aim of the project proposed system is broker less approach between publisher and subscriber i.e. there are no intermediate messaging agents between publisher and subscribers and Purpose of this Project development of technologies and solutions that can be leveraged for the Integration of various components built on different platform.

Dept of ISE, NHCE 2014-15Page 1