OCI's Middleware News Brief (MNB) features news and technical information about open source middleware technologies (e.g., TAO, OpenDDS, JacORB, OpalORB), including case studies and other technical content.
Articles
Interoperable Internet-Enabled DDS Applications
DDS (Data Distribution Service) is an OMG standard and a potentially excellent technology for the (Industrial) Internet of Things (IIoT), since it allows developers to create robust, secure, and interoperable distributed applications by providing publish/subscribe semantics to a shared cache.
Interoperability for DDS applications is achieved by using the Real-Time Publish Subscribe (RTPS) protocol. However, the discovery procotols in RTPS assume that the underlying network supports multicast and that datagrams are not subject to network address translation (NAT). Both of these assumptions are violated in a typical IIoT application. Thus, in order for DDS and RTPS to become viable technologies for IIoT, we must expand the reach of RTPS to include networks where multicast is not supported and packets are subject to NAT.
This article presents a solution to these problems by introducing a service that relays RTPS messages.
Introduction to OpenDDS
Distributed real-time applications are sometimes more data-centric than service-centric, meaning that the primary objective of the participants in the distributed system is the dissemination of application data rather than access to shared services. The set of suppliers and/or consumers of application data may not be known at design time, and may change through the execution lifetime of the application. Typically, the data-centric paradigm is most efficiently realized by a publish/subscribe…
Reactive OpenDDS, Part I
Reactive programming is a "programming paradigm oriented around data flows and the propagation of change." Relationships can be established between producers, consumers, and transformers of data, with updates occurring asynchronously, rather than by request. This aids in application scalability and better utilization of hardware resources, as threads are not blocked waiting on potentially long-running operations. The result of a database query or the return value from a web service can be…
Reactive OpenDDS, Part II: Operators
Reactive programming is a "programming paradigm oriented around data flows and the propagation of change." Relationships can be established between producers (observables), consumers (observers), and transformers of data (operators), with updates occurring asynchronously, rather than by request. This aids in application scalability and better utilization of hardware resources, as threads are not blocked waiting on potentially long-running operations. In Part I of this article, a method was shown…
Using Reliable Multicast for Data Distribution with OpenDDS
Perhaps one of the most critical decisions application designers face when creating a distributed system is how data should be exchanged between interested parties. Typically, this involves selecting one or more communication protocols and determining the most efficient means of dispatching data to each endpoint. Implementing lower-level communications software can be time consuming, expensive, and prone to error. Too often, after investing a significant amount of time and effort, many designers…
Multi-Platform Serial Interfacing using Boost: A GPS Sensor and OpenDDS Part I
Since the early days of the IBM PC, serial ports supporting the RS-232 standard [1] have been used to connect external devices to computers. While physical serial ports may not be as commonplace on new hardware as they once were, many devices still provide serial connectivity by creating virtual serial ports in the operating system that are associated with USB interfaces.
External modems may be the most familiar serial device, but many devices communicate serially, such as bar code scanners,…
Multi-Platform Serial Interfacing using Boost: A GPS Sensor and OpenDDS Part II
In part I [1] of this article, we used Boost libraries under both Windows and Linux to communicate with a GPS receiver connected to a serial port. Boost Asio [2] was used for asynchronous I/O to read data from the receiver in a platform-independent manner, with other Boost libraries in supporting roles. This article continues the interaction with the GPS receiver by parsing the GPS data, and publishing it via OpenDDS [3].
The source code of the applications presented here is available in the…
Code Generation with OpenDDS, Part I
Applications that use the Data Distribution Service (DDS) typically have two elements in common:
Boilerplate code:
The sequence of steps to initialize the DDS framework, and to create and destroy domain participants, is the same from project to project. Simplifying the code to write for the application's skeleton reduces development time.
Knowledge of IDL and C++:
DDS implementations such as OpenDDS [1] are written in C++ and require structures used as data samples to be described in the…
Code Generation with OpenDDS, Part II
As stated in Part I [1] of this article, applications that use the Data Distribution Service (DDS) typically have two elements in common:
Boilerplate code:
The sequence of steps to initialize the DDS framework, and to create and destroy domain participants, is the same from project to project. Simplifying the code to write for the application's skeleton reduces development time.
Knowledge of IDL and C++:
DDS implementations, such as OpenDDS [2], are written in C++ and require structures…
Interpreting OpenDDS Performance Testing Results
This document discusses the measurements, statistics, and charts used to describe the performance of OpenDDS. Performance tests can be executed using the OpenDDS-Bench[2] performance testing framework. The framework includes preconfigured tests that can be executed by any user in their own environment. Test results obtained using this framework include the measurements and data described here. OpenDDS-Bench provides scripts to reduce the raw data produced to plottable form and also scripts for…
Using TAO and OpenDDS with .NET, Part 1
This article provides a step-by-step tutorial on how to use TAO in a .NET application to implement both a CORBA client and a CORBA server.
Using TAO and OpenDDS with .NET, Part II
Learn how to mix TAO and OpenDDS in a .NET application to implement a client-server system in this step-by-step tutorial.
Using TAO and OpenDDS with .NET, Part III — DCPSInfoRepo Collocation
For several years, OCI has been engaged with a customer in the maintenance of a legacy data-acquisition application. Data is collected by remote sensing devices and stored in a database, and the sensing devices are managed, and the data viewed, by an application written for Microsoft Windows.
Although originally a single-user application referencing a local database, over time the application has evolved into one where multiple users can simultaneously connect to a single centralized…
Using QuickFAST and OpenDDS for a Low Latency Market Data Feed
For security traders, having up-to-date and accurate information has always been critical. The financial industry was an early adopter of electronic communication to distribute market data going back to the days of the stock ticker, and continues to push the limits of the technology today.
In recent years, the volume of market data generated by exchanges around the world has skyrocketed. Not only is the amount of data increasing, but so are the types of data being tracked and published. The…
MPI and DDS (Not?) So Different
There are a number of frameworks, middleware, and libraries for distributed computing that have emerged since the 1990s. Two of these are Message Passing Interface (MPI) [1], and the Data Distribution Service (DDS) for Real-Time Systems [2]. On the surface, these have distinct, incompatible models of computation. An MPI computation consists of message passing between a fairly rigid set of processes each of which is identified by number, while DDS provides a decoupling between publishers and…
Comparing OpenDDS and ZeroMQ Usage and Performance
High-performance messaging middleware is an increasingly important infrastructure component of any distributed application. A well-designed messaging infrastructure can minimize dependencies between application components, enabling evolution of the software as requirements change and as new components are integrated.
There are many such messaging middleware systems. One is OpenDDS (www.opendds.org), OCI's open source implementation of the Object Management Group (OMG) Data Distribution…
Using Erlang with CORBA and DDS
The trend in modern computer systems is toward increased numbers of processing units — more cores on a single die, multiple processors in a single machine, or linking machines into larger and larger clusters. As a consequence, complex concurrent applications that are difficult to develop are becoming the norm. The Erlang [1] language can simplify the task of writing distributed concurrent applications. Although a system can be developed entirely in Erlang, interaction with non-Erlang systems is…
Introduction to Fault Tolerant CORBA
Introduction
CORBA is used in a wide variety of application domains--aerospace and defense, banking and finance, telecommunications, manufacturing, healthcare, even multimedia and entertainment [http://www.corba.org/success.htm]. CORBA's inherent benefits, such as location transparency, platform portability, network transparency, and language independence are important factors in its wide-ranging success.
Unfortunately, traditional CORBA-based middleware often cannot meet the demanding…
CORBA Security: An Overview
Introduction
CORBA began life without security. However, in recent years there has been increased focus on adding security features into the palette of tools CORBA offers middleware developers. Unfortunately, the add-on nature coupled with lack of widespread, credible implementations fostered confusion regarding CORBA Security's use and utility. In this article we scratch the surface and lay the groundwork for demystifying security as it relates to CORBA middleware.
The specification for…
CORBA, Part I: Java and the Web using the Play Framework
Explore the development of a simple CORBA-based client-server system in Java under Linux, using both command-line-based and web-based clients.
CORBA, Part II: .NET Development using IKVM, Topshelf and IIOP.NET
In part I of this article [1], we designed a simple CORBA-based client-server system in Java where clients use remote objects that implement the Adder interface to sum two numbers. The Naming Service was used to allow clients to locate objects that implemented desired functionality. Command-line-based client and server applications were shown, as well as a web-based client using the Play Framework [2], running under Linux.
This article builds upon the former by continuing development under…
Using Futures to Simplify CORBA AMI
Many applications perform actions that take a significant amount of time — perform a database query, retrieve data from a web server, generate a report, and the like. It is beneficial to run these actions separately from the main thread of the application. Multiple tasks may be able to be executed simultaneously, improving overall application performance. In addition, moving long-running operations out of the thread that manages the user interface yields a better user experience — the…
Footprint Reduction of CORBA Client and Servers
Introduction
CORBA clients and servers can be used on a variety of computer systems ranging from small devices such as embedded systems and handheld computers to large mainframes. Typically, on smaller computers CORBA is used to support clients. Because of the memory constraints of these smaller systems it is often necessary to identify ways to reduce the memory footprint of the client code. Likewise, larger systems are typically used for running CORBA-based servers. Even though there may be…
Real-Time CORBA Priority and Threadpool Mechanisms
Introduction
The Real-Time CORBA specification [1] defined several mechanisms to provide for end-to-end deterministic performance for CORBA operations. This specification was originally defined as an extension to CORBA 2.3 and the CORBA messaging specification. The RT CORBA extensions utilized and extended the quality-of-service (QoS) mechanisms defined in the CORBA messaging specification. The extensions defined by RT CORBA are used to support many distributed real-time and embedded (DRE)…
The CORBA Notification Service: JacORB and TAO Interoperability
This month's CORBA News Brief from OCI provides a high-level overview of the OMG Notification Service and illustrates using the TAO 1.2a Notification Service interoperating with a JacORB v1.4 consumer.
Overview of the Notification Service
The Notification Service Specification was originally produced by the Telecommunications Working Group within the Object Management Group (OMG), an international consortium of over 800 companies, and was later adopted as a standard service. The goal was…
Request Processing Aspects of CORBA and TAO (Part 1 of 2)
Introduction
CORBA ORBs are used in software systems that span a variety of problem domains including finance and banking, telecommunications network provisioning and maintenance, media collection and dissemination, aerospace, and defense [http://www.corba.org/success.htm]. Consequently, CORBA ORBs [formal/02-12-06] are subject to wide-ranging performance requirements, used in sequential as well as concurrent processing scenarios, and deployed on many different platforms. To be successful…
Multi-Language CORBA Development with C++ (TAO), Java (JacORB), Perl (opalORB), and C# (IIOP.NET)
The most significant benefit of the Common Object Request Broker Architecture (CORBA) is interoperability — applications can be written in a multitude of languages, on distributed platforms with varying physical architectures. Over a dozen mappings from CORBA's Interface Definition Language (IDL) to common programming languages are defined by the Object Management Group (OMG) [1], plus additional custom mappings also exist. Interoperability at the data transmission level is also defined by the…
An Introduction to TAO's Asynchronous Message Handling
Introduction
CORBA ORBs typically offer application developers a variety of mechanisms to control request processing. Mechanisms such as POA threading models, which control concurrent request processing, Real-Time CORBA's priority mechanisms, which provides platform-independent control of native thread priorities, Real-Time CORBA's threadpool mechanisms, which controls allocation of threads to requests at the POA level, and Asynchronous Message Invocation (AMI), which allows a client to…
Integrating Native Mobile Applications and Rails
The increasing power and popularity of today's smart phones are driving many companies to build mobile applications to support their mobile workforce. Both the Android [1] and iPhone [2] platforms present opportunities to empower mobile employees with real-time information. Mobile applications are those which run directly on a mobile device. There are three basic categories of mobile applications:
OpenMP
The OpenMP [1] specification describes a collection of compiler directives for marking regions of code for parallel execution and synchronization. These directives are expressed as pragmas in C/C++, and as comments in FORTRAN. A function-call-style API is also available which provides additional functionality.
The development of the OpenMP specification is under the purview of the OpenMP Architectural Review Board, a non-profit corporation whose members include HP, IBM, Intel, Sun…
An Introduction to OVATION (Object Viewing Analysis Tool for Integrated Object Networks)
Introduction
Object Viewing Analysis Tool for Integrated Object Networks (OVATION) is a freely available, open-source tool set developed to assist in the debugging, diagnosis, and analysis of distributed applications. OVATION permits the collection of information about interactions between application components and facilitates the presentation of this data in a graphical tool. Specifically, the OVATION collector tool accumulates remote method invocations and event channel events between…
Object References, Memory Management, and Parameter Passing in C++ -- Part 1
Introduction
Correct use of object references is an essential skill for CORBA developers. Object references are largely a client-side issue but there are server-side implications arising from the C++ language mapping that defines how object references are exchanged during CORBA request invocations. This is certainly not "news" but a periodic review of this topic is useful for most CORBA developers. This article, the first of two parts, discusses the C++ language mapping for object references,…
Attaining CORBA Interoperability Through Codeset Translation
Introduction
CORBA interoperability means different things at different levels. At the level of the network, it means that processes may be able to communicate using varying transport mediums. At the messaging layer, interoperability means that the participating ORBs use a common protocol, such as GIOP. At the presentation layer, interoperability means that information contained in data may be interpreted and presented consistently. This CORBA News Brief is intended to discuss…
Bootstrapping Techniques
Introduction
When developing a CORBA application, you must eventually tackle the issue of how to locate your CORBA objects. This issue is sometimes referred to as bootstrapping. In this CORBA News Brief we will discuss the issues raised by, and choices available for bootstrapping a CORBA application so that each of the processes may access the services of its peer processes. We will describe the options for developers and consider the performance, and reliability/fault tolerance tradeoffs of…
Local Interfaces
Introduction
The Object Management Group (OMG) defines the Interface Definition Language (IDL) as part of the CORBA specification. The OMG has always used IDL to not only define unconstrained ( potentially remote) interfaces, but also those local to a particular process (or part of CORBA's API). Originally, this was done in an informal manner with what was described as Pseudo IDL (PIDL). For example, in CORBA 2.4 the PortableServer::ServantManager object has its interface defined with the…
