Open Specifiation¶

Communication Patterns¶

We can distinguish between three main different messaging patterns, Publish/Subscribe, Point-to-Point, and Request/Reply, shown schematically below:

Publish/Subscribe Pattern

Point-To-Point Pattern

Request/Reply Pattern

All available middleware technologies implement one or more of these messaging patterns and may incorporate more advanced patterns on top of them. Most RPC middleware is based on the Request/Reply pattern and more recently, is extended towards support of Publish/Subscribe and/or the Point-To-Point pattern.

W3C Web Service standards define a Request/Reply and a Publish/Subscribe pattern which is built on top on that (WS-Notification). CORBA, in a similar way, build its Publish/Subscribe pattern (Notification Service) on top of a Request/Reply infrastructure. In either case the adopted architecture is largely ruled by historical artifacts instead of performance or functional efficiency. The adopted approach is to emulate the Publish/Subscribe pattern on top of the more complex pattern thus inevitably leading to poor performance and complex implementations.

The approach of the Advanced Middleware takes the other direction. It provides native Publish/Subscribe and implements the Request/Reply pattern on top of this infrastructure. Excellent results can be achieved since the Publish/Subscribe is a meta-pattern, in other words a pattern generator for Point-To-Point and Request/Reply and potential alternatives.

Interface Definition Language (IDL)¶

The Advanced Middleware GE supports a novel IDL to describe the Data Types and Operations. Following is a list of the main features it supports:

• IDL, Dynamic Types & Application Types: It support the usual schema of IDL compilation to generate support code for the data types.
• IDL Grammar: An OMG-like grammar for the IDL as in DDS, Thrift, ZeroC ICE, CORBA, etc.
• Types: Support of simple set of basic types, structs, and various high level types such as lists, sets, and dictionaries (maps).
• Type inheritance, Extensible Types, Versioning: Advanced data types, extensions, and inheritance, and other advanced features will be supported.
• Annotation Language: The IDL is extended with an annotation language to add properties to the data types and operations. These will, for example, allows adding security policies and QoS requirements.
• Security: The IDL allows for annotating operations and data types though the annotation feature of our IDL, allowing setting up security even at the field level.

General Note¶

In contrast to other GEs, the Advanced Middleware GE is not a standalone service running in the network, but a set of compile-/runtime tools and a communication library to be integrated with the application.

The Advanced Middleware (AMi) architecture presented here offers a number of key advantages over other available middleware implementations:

• High-Level Service Architecture: AMi offers applications a high-level architecture that can shield them from the complexities and dangers of network programming. When applications declare services and data structures they can annotate them with the QoS, security, and other requirements while AMi automatically implement them. Thus application developers can exclusively focus on the application functionality.
• Security: The network is the main security threat to most applications today but existing middleware has offered only limited security functionality that has often been added as an afterthought and requires the application developer (who are often not security experts) to configure the security functionality. Instead, AMi offers Security by Design where security has been designed into the architecture from the start. Applications can simply declare their security needs in the form of security policies (security rules) and apply them to data structures and service at development time or even later during deployment definitions. AMi then makes sure that these requirements are met before any communication takes place and applies any suitable security measures (e.g. encryption, signatures, etc.) during the communication.
• Dynamic Multi-Protocol support: The AMi architecture can select at run-time the best way to communicate with a remote service. Thus, an AMi application can simultaneously talk with legacy services via their predefined protocols (e.g. DDS). It also supports various communication patterns, like Publish-/Subscribe (PubSub), Point-To-Point, or Request-/Reply (RPC).
• QoS and Software Defined networking: Where possible the QoS annotations are also used to configure the network using modern Software Defined networking functionality, e.g. to reserve bandwidth.

The Advanced Middleware GE components¶

The following layer diagram shows the main components of the Advanced Communication Middleware GE.

I2ND Middleware Architecture Overview

In the diagram the main communication flow goes from top to bottom for sending data, respectively and from bottom to top for receiving data. As in a typical layer diagram each layer is responsible for specific features and builds on top of the layers below. Some modules are cross cutting and go therefore over several layers (e.g. Security).

Here are some of the highlights of the AMi architecture shown in the diagram:

• AMi clearly separates the definition of WHAT data must be communicated (the communication contract via one of many interface definition languages (IDLs)) from WHERE that data comes from in the application and from HOW that data is transmitted. This separation of concerns is critical to support some advanced functionality and be portable to a wide range of services and their communication mechanisms.
• AMi supports multiple IDLs to define what data needs to be communicated. On establishing the connection the interface definition of a service are obtained (explicitly or implicitly).
• AMi offers annotations for QoS, security, or other features that can be added to the data declared by the application, to the IDL, as well as later during deployment. They are used by the middleware to automatically implement its functionality by requesting QoS functionality from the network layer or automatically enforcing security measures.
• As the connection to a service is established, both sides choose a common mechanism and protocol (negotiation) to best communicate with each other.

The most efficient transport and protocol method supported by both sides will be selected. AMi has been designed to also support Software Defined Networking in order to configure QOS parameters in the network.

• AMi offers an efficient dispatching mechanism for scheduling incoming request to the correct service implementation.

Below we give a short description of the different layers and components.

API versions¶

There will be two versions of APIs provided:

• RPC Static API

  Static compile-time parsing of IDL and generation of Stub-/Skeletons and DataReader/DataWriter
• RPC Dynamic API

  Dynamic runtime parsing of IDL and run-time invocation of operations.

Additionally following features will be provided as API extensions:

• Advanced security policy and QoS parameters
• Publish/subscribe functionality compatible to RPC-DDS and DDS applications

Classification of functions¶

The API-Functions can be classified in the following groups:

• Preparation: statically at compile-time (Static API) or dynamically at run-time (Dynamic API)
  • Declare the local applications datatypes/functions (Dynamic API only)
  • Parsing the Interface Definition of the remote side (IDL-Parser)
  • Generate Stubs-/Skeletons, DataReader-/Writer
  • Build your application against the Stubs-/Skeletons, DataReader-/Writer (Static API only)
• Initialization:
  • Create the context (set up the environment, global QoS/Transport/Security policy,...)
  • Open connection (provide connection specific parameters: QoS/Transport/Security policy, Authentication, Tunnel encryption, Threading policy,...)
• Communication
  • Send Message/Request/Response (sync/async, enforce security)
  • Receive Message/Request/Response (sync/async, enforce security)
  • Exception Handling
• Shutdown
  • Close connection (cleanup topics, subscribers, publishers)
  • Close the context (Free resources)

Detailed description of the APIs and tools can be found in the User and Developer Guide, which will be updated for every release of the Advanced Middleware GE.

Open API Specifications¶

• Advanced Middleware IDL Specification
• Advanced Middleware RPC API Specification
• Advanced Middleware RPC Dynamic Types API Specification
• Advanced Middlware Pub-Sub API Specification