• Noser.com
facebook
linkedin
twitter
youtube
  • NOSERmobile
    • Android
    • HTML 5
    • Hybrid Apps
    • iOS
    • Windows Phone
  • NOSERembedded
    • Medizintechnik
  • NOSERprojektmanagement
  • NOSERtesting
  • NOSERlifecycle
    • .NET Allgemein
    • Application Lifecylce Management
    • Apps
    • Architektur
    • ASP.NET
    • Azure
    • Cleancode
    • Cloud
    • Silverlight
    • Visual Studio / Team Foundation Server
    • Windows 8
    • Windows Presentation Foundation
  • NOSERinnovation
    • Big Data
    • Cloud
    • IoT
    • Operations Research
    • Augmented Reality
    • RFID, NFC, Bluetooth LE

The elevator pitch for Data Distribution Services

18. Februar 2022
Stephen Goss
0
.NET, C, C#, C++, Data Distribution Services, DDS, Embedded, Java, Object Management Group, OMG, Publish Subscribe Pattern, PubSub, Python, Real Time, RTOS

Do you have a project with components exchanging data across a network over different operating systems, micro controllers and programming languages?

Do the components have to work well together in a coherent, decoupled way?

Then Data Distribution Services could be for you.

Data Distribution Services (DDS) is an interoperable, scalable middleware for data exchange using the publisher–subscriber pattern managed by the Object Management Group (OMG) . The publisher–subscriber pattern has the advantage that it decouples the structure of data from the specific implementation of each of the components. Data Distribution Services is useful for applications that require interoperability between operating systems, platforms and programming languages. DDS is used in medical, military and automotive instustries amongst others.

Interoperability

DDS allows programs from different vendors platforms and languages to exchange information. Platforms commonly supported : Linux, Windows. Microcontrollers, MacOS, Android, iOS. Languages commonly supported : C++, Dot Net C#, Java, C, Python.

Here are some popular and well supported implementations of DDS and their relative advantages and disadvantages, there are many others you can look up in the DDS foundation link below.

  • RTI : Well developed and expensive but very good support and tooling.
  • Open Splice : Also well developed with an open source version.
  • Twin Oaks : Microprocessor centric, well supported, tooling not as sophisticated as the others.

Publish subscribe pattern

Publish–subscribe is a messaging pattern where publishers, do not send the messages (referred to as samples) directly to specific subscribers, but instead publish samples to DDS.  Similarly, subscribers express interest in one or more message types (referred to as topics) and only receive subscribed topics, without direct knowledge of a specific publisher or publishers. Once a publisher decides that the subscriber has to be called a listener can call code to handle the sample. The conditions under which the subscriber is called depends on the QoS (Quality of service).

High level view of data distribution services.

High level view of data distribution services.

Work flow during project iterations

The interface is derived from the requirements. This is codified into IDL and QoS that is reviewed with the interface description documents. The IDL can be used as input to the vendor and platform and language specific code generators to create the boiler plate code for the topics. (if the vendor tooling supports this).

High level view of data distribution services interface definition and code generation.

High level view of data distribution services interface definition and code generation.

Interface Description Language (IDL)

An interface description language or interface definition language (IDL), is a generic term for a language that lets a program or object written in one language communicate with another program written in an unknown language. IDLs describe an interface in a language-independent way, enabling communication between software components that do not share a language, for example, between those written in C++ and those written in Java.

Example of simple IDL

struct WeatherItem{
     long                   Elevation;
     long                   Temperature;
};

struct Weather {
     string<64>                  Location;
     long                        sampleId;
     sequence<WeatherItem, 127>  WeatherProfile;
};

Quality of service (QoS)

Quality of service in the context of DDS is how the message is sent. Is the sample send periodically without regard to any changes or is it only sent on change. Do you want the sample to be valid 2 seconds after it is written or for ever. Is the current sample the last sample sent of or the last sample received. Various vendors have different methods of specifying or changing the QoS. The most flexible is in a configuration file. Another advantage of this method of specifying the QoS is that it can be used to mitigate issues without changing the code and is treated differently in the Quality control Process.

Below is an example of a simple QoS configuration file to give you some idea of how this can be specified.

Here is a brief description of some terms in this QoS.

Reliable : An attempt will be made to send all samples in the history.

Keep all history : An attempt to keep all samples the until they are taken by the subscriber will be made.

<?xml version="1.0"?>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="http://community.rti.com/schema/6.1.0/rti_dds_qos_profiles.xsd">
    <qos_library name="Weather_Library">
        <qos_profile name="Weather_Profile" is_default_qos="true">
            <datawriter_qos>
                <reliability>
                    <kind>RELIABLE_RELIABILITY_QOS</kind>
                </reliability>                

                <history>
                    <kind>KEEP_ALL_HISTORY_QOS</kind>
                </history>		
            </datawriter_qos>

            <datareader_qos>
                <reliability>
                    <kind>RELIABLE_RELIABILITY_QOS</kind>
                </reliability>
    
                <history>
                    <kind>KEEP_ALL_HISTORY_QOS</kind>
                </history>			
            </datareader_qos>
            <domain_participant_qos>
                <participant_name>
                    <name>WeatherData</name>
                </participant_name>

            </domain_participant_qos>
        </qos_profile>
    </qos_library>
</dds>

Summary

DDS is a useful standard to put structure into the communication between components of a software system. It has the advantage of decoupling the data schema from the applications.  How the data is transported from the publishers to the subscribers can be specified via configuration in some implementations. This can be of great benefit to developers in the quality control process. It is available for a number of platforms and languages, this makes it a good fit for IOT projects.

Links

The DDS foundation

Object Management Group

The pitfalls of CV driven Architecture

25. Juni 2018
Stephen Goss
0

In every project, there is a conflict

The conflict

The conflict is between what the developers want to develop and the product the customer wants to have made for him.

No software development project is without this dynamic.

The trick is to harness the software developer’s enthusiasm for developing good software without endangering the overall success of the project.

This requires that you reconcile the 2 parties.

They have similar but not the same goals.

If you pick technologies that can satisfy these 2 goals enough to keep both sides happy you will have a good basis for a successful project.

For the most part, the customer is not interested in the details of the technology.

The customer wants his software to solve a problem, over a particular period of time and by a particular delivery date.

The software developer is in general interested in the customer’s problem but also has a need to create something new innovative and fun.

CV Driven Architecture

CV Driven architecture or Resume Driven Development refers to the idea of a developer choosing the technology based on what would look good on his resume (CV).

This can be in conflict with what would best suit the goals of the project.

There are 2 extremes that must be avoided

Dead end technology

If the technology is “dead end” you will have a hard time finding developers to carry it out or maintain the project.

Most of all, with dead-end technology you run the risk of diminishing support during the software’s lifecycle.

Bleeding edge technology or pattern bloating

If the technology is too bleeding edge or not appropriate for the problem it is supposed to solve, it may be either over budget, over schedule or not fit for purpose.

Similarly trying to put as many of the 23 Gang of Four patterns into the project as you can without a basis in a customer requirement happens more often than you might think.

I have been involved in projects that have been canceled before completion due to overruns.

I have also been involved in several bleeding edge projects that were considered a success.

But you are left with the distinct feeling that they could have been done with a fraction of the effort.

This would have required the developers to be more compromising with their enthusiasm for the new.

Get the balance right

The solution is to keep a balance between the development team and the customer.

Pick the newest technology that fulfills the following checklist.

How well accepted is the technology?

For instance, are there hosting providers acceptable to your client for the technology your planning to use?

You may be in the embarrassing situation of a major rewrite before you can deploy your solution.

This will have an impact on your effort and delivery date.

How stable is the technology?

If the technology, you are using has less than a 1.0 in its title it may not be stable yet.

Chances are it is going to change before your project is finished.

You possibly will have to rewrite the parts that have been “improved” in 1.0, 1.1 and finally in 1.2 it actually does what you expected.

Are there developers proficient in this technology?

How many software developers are proficient in the technology.

If this is a bleeding edge technology, then it could be the case that there are few developers who are proficient.

In conclusion

There needs to be a balance between cool and fit for purpose when deciding on your technology mix.

Similar to architectural decisions there are no right or wrong answers just benefits and trade-offs.

 

 

Tag Cloud

.NET android Angular AngularJs Arduino ASP.Net automated testing Azure Big Data C# C++ Cloud continuous integration Elm Embedded Führung gRPC Internet of Things IoT Java Javascript M2M OWASP Projektmanagement protobuf Python Raspberry Pi Reactive Programming REST Scrum Security Softwarequalität SPA Testen testing Testmanagement Teststrategie UX Visual Studio WebAPI windows WPF Xamarin Xamarin.Android Xamarin.Forms

Archive

Current Posts

  • Akzente setzen mit der Android Splash Screen API unter .NET MAUI
  • Do You have Your Personal Space?
  • Automated provisioning with ARM Templates
  • Asynchrone Beobachtungen und Versprechungen in Angular
  • Simplify Your Automated Tests With Fluent Syntax

Last Comments

  • Hans Reinsch bei Der Safety-Plan: Die wichtigsten Antworten mit Checkliste
  • George H. Barbehenn bei Modeling Optocouplers with Spice
  • Noser Blog Touch-Actions in Xamarin.Forms - Noser Blog bei Mach mehr aus Animationen in Xamarin.Forms mit SkiaSharp
  • Noser Blog Focus on the Secure Storage service of Trusted Firmware (TFM) - Noser Blog bei First run of the Trusted Firmware (TFM) application
  • Noser Blog First run of the Trusted Firmware (TFM) application - Noser Blog bei Focus on the Secure Storage service of Trusted Firmware (TFM)

Popular Posts

Xamarin.Android Code Obfuscation

6 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 1 - Aufbruch

5 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 2 - Kein Picknick

4 Comments

Contact us

  1. Name *
    * Please enter your name
  2. Email *
    * Please enter a valid email address
  3. Message *
    * Please enter message
© 2013 NOSER ENGINEERING AG. All rights reserved. Datenschutz | Cookie-Richtlinie