Advanced Middleware IDL Specification¶

Date: 10th October 2015

Version: 0.3.0
Latest version: latest

Editors:

Abstract¶

Ahe Advanced Middleware GE enables flexible, efficient, scalable, and secure communication between distributed applications and to/between FIWARE GEs. The Interface Definition Language (IDL) Specifications allowes to describes the Data Types and Operations supported by a Service. 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.

Status of this Document¶

Date	Description
8-April-2015	Release 0.2.0
10-October-2015	Release 0.3.0

Preface¶

The foundation of the FIWARE Middleware Interface Definition Language (IDL) is the Object Management Group (OMG) IDL 3.5. See Appendix C for the OMG IDL 3.5 grammar.

To maintain backward compatibility, the FIWARE Middleware IDL grammar embraces all OMG IDL 3.5 features. IDL parsers are not required to implement all of the extended OMG features. Check the documentation of the specific parser implementations.

The basic subset needed by DDS and future standard RPC over DDS must be supported.

Syntax Definition¶

The FIWARE Middleware IDL specification consists of one or more type definitions, constant definitions, exception definitions, or module definitions. Some definitions are allowed in the grammar for backward compatibility, but are not used by the FIWARE Middleware IDL and therefore will be ignored by the implmentations.

<specification> ::= <import>* <definition>+
<definition> ::= <type_dcl> ";"
             |   <const_dcl> ";"
             |   <except_dcl> ";"
             |   <interface> ";"
             |   <module> ";"
             |   <value> ";"
             |   <type_id_dcl> ";"
             |   <type_prefix_dcl> ";"
             |   <event> ";"
             |   <component> ";"
             |   <home_dcl> ";"
             |   <annotation_dcl> ";"
             |   <annotation_appl> <definition>

See section Import Declaration for the
specification of <import>
See section Module Declaration for the
specification of <module\>
See section Interface Declaration for
the specification of <interface>
See section Value Declaration for the
specification of <value\>
See section Constant Declaration for the
specification of <const_dcl>
See section Type Declaration for the
specification of <type_dcl>
See section Exception Declaration for
the specification of <except_dcl>
See section Repository Identity Related
Declarations for the
specification of <type_id_dcl> and <type_prefix_dcl>
See section Event Declaration for the
specification of <event>
See section Component Declaration for
the specification of <component>
See section Event Declaration for the
specification of <home_dcl>
See section Annotation Declaration for
the specification of <annotation_dcl>
See section Annotation Application for
the specification of < annotation_appl>

Import Declaration¶

An import statement conforms to the following syntax:

<import> ::= "import" <imported_scope> ";"
<imported_scope> ::= <scoped_name> | <string_lieral>

Import declarations are not supported by FIWARE Middleware. Any FIWARE Middleware IDL parser has to inform users about this and ignore the declaration.

Module Declaration¶

A module definition conforms to the following syntax:

<module> ::= ("module" | "namespace") <identifier> "{" <definition> + "}"

The module construct is used to scope IDL identifiers. FIWARE Middleware IDL supports the OMG IDL 3.5 keyword module, but also adds the modern keyword namespace as an alias.

Examples of module definitions:

namespace MyNamespace {
   ...
};

namespace YourNamespace {
   namespace HisNamespace {
      ...
   };
};

Interface Declaration¶

An interface definition conforms to the following syntax:

<interface> ::= <interface_dcl> | <forward_dcl>
<interface_dcl> ::= <interface_header> "{" <interface_body> "}"
<forward_dcl> ::= [ "abstract" | "local" ] ("interface" | "service") <identifier>
<interface_header> ::= [ "abstract" | "local" ]("interface" | "service") <identifier>
                       [ <interface_inheritance_spec> ]
<interface_body> ::= <export>*
<export> ::= <type_dcl> ";"
          |   <const_dcl> ";"
          |   <except_dcl> ";"
          |   <attr_dcl> ";"
          |   <op_dcl> ";"
          |   <type_id_dcl> ";"
          |   <type_prefix_dcl> ";"

Example of interface definition:

service MyService {
   ...
};

Interface Header¶

The interface header consists of three elements:

An optional modifier specifying if the interface is an abstract interface.
The interface name. The name must be preceded by the old OMG IDL 3.5 keyword interface or the new modern keyword service.
An optional inheritance specification.

An interface declaration containing the keyword abstract in its header, declares an abstract interface. Abstract interfaces have slightly different rules from regular interfaces, as described in section Abstract interface.

An interface declaration containing the keyword local in its header, declares a local interface. Local interfaces are not currently supported by the FIWARE Middleware. Any FIWARE Middleware IDL parser has to inform users about this, and explain the interface will be used as a regular interface.

Interface Inheritance Specification¶

The syntax for interface inheritance is as follows:

<interface_inheritance_spec> ::= ":" <interface_name> { "," <interface_name> }*
<interface_name> ::= <scoped_name>
<scoped_name> ::= <identifier>
            |   "::" <identifier>
            |   <scoped_name> "::" <identifier>

Each <scoped_name> in an <interface_inheritance_spec> must be the name of a previously defined interface or an alias to a previously defined interface.

Interface Body¶

The interface body contains the following kind of declarations:

Constant declarations whose syntax is described in section Constant Declaration.
Type declarations whose syntax is described in section Type Declaration.
Exception declarations whose syntax is described in section Exception Declaration.
Attribute declarations whose syntax is described in section Attribute Declaration.
Operation declarations whose syntax is described in section Operation Declaration.

Abstract interface¶

An interface declaration contains the keyword abstract in its header, declares an abstract interface. The following special rule apply to abstract interfaces:

Abstract interfaces may only inherit from other abstract interfaces.

Value Declaration¶

Value type declarations are supported by FIWARE Middleware IDL, but aren’t by FIWARE Middleware. Any FIWARE Middleware IDL parser has to explain that these declarations are not used and the parser will ignore them.

Constant Declaration¶

A constant definition conforms to the following syntax:

<const_dcl> ::= "const" <const_type>
                <identifier> "=" <const_exp>
<const_type> ::= <integer_type>
             |   <char_type>
             |   <wide_char_type>
             |   <boolean_type>
             |   <floating_pt_type>
             |   <string_type>
             |   <wide_string_type>
             |   <fixed_pt_const_type>
             |   <scoped_name>
             |   <octet_type>
<const_exp> ::= <or_expr>
<or_expr> ::= <xor_expr>
           |  <or_expr> "|" <xor_expr>
<xor_expr> ::= <and_expr>
           |   <xor_expr> "^" <and_expr>
<and_expr> ::= <shift_expr>
           |   <and_expr> "&" <shift_expr>
<shift_expr> ::= <add_expr>
             |   <shift_expr> ">>" <add_expr>
             |   <shift_expr> "<<" <add_expr>
<add_expr> ::= <mult_expr>
           |   <add_expr> "+" <mult_expr>
           |   <add_expr> "-" <mult_expr>
<mult_expr> ::= <unary_expr>
            |   <mult_expr> "*" <unary_expr>
            |   <mult_expr> "/" <unary_expr>
            |   <mult_expr> "%" <unary_expr>
<unary_expr> ::= <unary_operator> <primary_expr>
             |   <primary_expr>
<unary_operator> ::= "-"
                 |   "+"
                 |   "~"
<primary_expr> ::= <scoped_name>
               |   <literal>
               |   "(" <const_exp> ")"
<literal> ::= <integer_literal>
          |   <string_literal>
          |   <wide_string_literal>
          |   <character_literal>
          |   <wide_character_literal>
          |   <fixed_pt_literal>
          |   <floating_pt_literal>
          |   <boolean_literal>
<boolean_literal> ::= "TRUE"
                  |   "FALSE"
<positive_int_const> ::= <const_exp>

Examples for constant declarations:

const string c_str = "HelloWorld";
const i32 c_int = 34;
const boolean c_bool = true;

Type Declaration¶

As in OMG IDL 3.5, FIWARE Middleware IDL provides constructs for naming data types; that is, it provides C language-like declarations that associate an identifier with a type. The IDL uses the keyword typedef to associate a name with a data type.

Type declarations conform to the following syntax:

<type_dcl> ::= "typedef" <type_declarator>
           |   <struct_type>
           |   <union_type>
           |   <enum_type>
           |   "native" <simple_declarator>
           |   <constr_forward_decl>
<type_declarator> ::= <type_spec> <declarators>

For type declarations, FIWARE Middleware IDL defines a set of type specifiers to represent typed value. The syntax is as follows:

<type_spec> ::= <simple_type_spec>
            |   <constr_type_spec>
<simple_type_spec> ::= <base_type_spec>
                   |   <template_type_spec>
                   |   <scoped_name>
<base_type_spec> ::= <floating_pt_type>
                 |   <integer_type>
                 |   <char_type>
                 |   <wide_char_type>
                 |   <boolean_type>
                 |   <octet_type>
                 |   <any_type>
                 |   <object_type>
                 |   <value_base_type>
<template_type_spec> ::= <sequence_type>
                     |   <set_type>
                     |   <map_type>
                     |   <string_type>
                     |   <wide_string_type>
                     |   <fixed_pt_type>
<constr_type_spec> ::= <struct_type>
                   |   <union_type>
                   |   <enum_type>
<declarators> ::= <declarator> { "," <declarator> }*
<declarator> ::= <simple_declarator>
             |   <complex_declarator>
<simple_declarator> ::= <identifier>
<complex_declarator> ::= <array_declarator>

The <scoped_name\> in <simple_type_spec> must be a previously defined type introduced by a type declaration(<type_dcl> - see section Type Declaration).

The next subsections describe basic and constructed type specifiers.

Basic Types¶

The syntax for the supported basic types is as follows:

<floating_pt_type> ::= "float"
                   |   "double"
                   |   "long" "double"
                   |   "float32"
                   |   "float64"
                   |   "float128"
<integer_type> ::= <signed_int>
               |   <unsigned_int>
<signed_int> ::= <signed_short_int>
             |   <signed_long_int>
             |   <signed_longlong_int>
<signed_short_int> ::= "short"
                   |   "i16"
<signed_long_int> ::= "long"
                  |    "i32"
<signed_longlong_int> ::= "long" "long"
                      |   "i64"
<unsigned_int> ::= <unsigned_short_int>
               |   <unsigned_long_int>
               |   <unsigned_longlong_int>
<unsigned_short_int> ::= "unsigned" "short"
                     |   "ui16"
<unsigned_long_int> ::= "unsigned" "long"
                    |   "ui32"
<unsigned_longlong_int> ::= "unsigned" "long" "long"
                        |   "ui64"
<char_type> ::= "char"
<wide_char_type> ::= "wchar"
<boolean_type> ::= "boolean"
<octet_type> ::= "octet"
             |   "byte"
<any_type> ::= "any"

Each IDL data type is mapped to a native data type via the appropriate language mapping. The syntax allows to use some OMG IDL 3.5 keywords and to use new modern keyword. For example, FIWARE Middleware IDL supports both keywords: long and i32.

The any type is not supported currently by FIWARE Middleware. Any FIWARE Middleware IDL parser has to inform users about this.

Constructed Types¶

Constructed types are structs, unions, and enums.

Their syntax is as follows:

<type_dcl> ::= "typedef" <type_declarator>
           |   <struct_type>
           |   <union_type>
           |   <enum_type>
           |   "native" <simple_declarator>
           |   <constr_forward_decl>
<constr_type_spec> ::= <struct_type>
                   |   <union_type>
                   |   <enum_type>
<constr_forward_decl> ::= "struct" <identifier>
                      |   "union" <identifier>

Structures¶

The syntax for the struct type is as follows:

<struct_type> ::= "struct" <identifier> "{" <member_list> "}"
<member_list> ::= <member> +
<member> ::= <type_spec> <declarators> ";"

Example of struct syntax:

struct MyStruct {
    i32 f_int;
    string f_str;
    boolean f_bool;
};

Unions¶

The syntax for the union type is as follows:

<union_type> ::= "union" <identifier> "switch"
                 "(" <switch_type_spec> ")"
                 "{" <switch_body> "}"
<switch_type_spec> ::= <integer_type>
                   |   <char_type>
                   |   <boolean_type>
                   |   <enum_type>
                   |   <scoped_name>
<switch_body> ::= <case> +
<case> ::= <case_label> + <element_spec> ";"
<case_label> ::= "case" <const_exp> ":"
             |   "default" ":"
<element_spec> ::= <type_spec> <declarator>

The <scoped_name> in the <switch_type_spec> production must be a previously defined integer, char, boolean or enum type.

Example of union syntax:

union MyUnion switch(i32)
{
   case 1:
      i32 f_int;
   case 2:
      string f_str;
   default:
      boolean f_bool;
};

Enumerations¶

Enumerated types consist of ordered lists of identifiers.

The syntax is as follows:

<enum_type> ::= "enum" <identifier>
                "{" <enumerator> { "," <enumerator> } * "}"
<enumerator> ::= <identifier>

Example of an enumerated type:

enum MyEnum {
   ENUM1,
   ENUM2,
   ENUM3
};

Template Types¶

Template types are:

<template_type_spec> ::= <sequence_type>
                     |   <set_type>
                     |   <map_type>
                     |   <string_type>
                     |   <wide_string_type>
                     |   <fixed_pt_type>

Lists¶

The FIWARE Middleware IDL defined the template type list. A list is similar to the OMG IDL 3.5 sequence type. It is one-dimensional array with two characteristics: a maximum size (which is fixed at compile time) and a length (which is determined at run time). The syntax is as follows:

<sequence_type> ::= "sequence" "<" <simple_type_spec> "," <positive_int_const> ">"
                |   "sequence" "<" <simple_type_spec> ">"
                |   "list" "<" <simple_type_spec> "," <positive_int_const> ">"
                |   "list" "<" <simple_type_spec> ">"

Examples of list type declarations:

list<string> mylist;
list<string, 32> myboundedlist;

Sets¶

The FIWARE Middleware IDL includes the template type set. At marshalling level it is like the template type list. But at a higher level, contrary to the list type, a set can only contain unique values. The syntax is as follows:

<set_type> ::= "set" "<" <simple_type_spec> "," <positive_int_const> ">"
                |   "set" "<" <simple_type_spec> ">"

Examples of set type declarations:

set<string> myset;
set<string, 32> myboundedset;

Maps¶

The FIWARE Middleware IDL includes the template type map, using the upcoming definition in OMG IDL 4.0. Maps are a collections, similar to lists, but items are associated with a key. Like lists, maps may be bounded or unbounded. The syntax is as follows:

<map_type> ::= "map" "<" <simple_type_spec> ","
                    <simple_type_spec> "," <positive_int_const> ">"
                |   "map" "<" <simple_type_spec> "," <simple_type_spec> ">"

Examples of map type declaration:

map<i32, string> mymap;
map<i32, string, 32> myboundedmap;

In CDR marshalling, objects of type map shall be represented according to the following equivalent OMG IDL 3.5 definition:

struct MapEntry_<key_type>_<value_type>[_<bound>] {
    <key_type> key;
    value_type> value;
};

typedef sequence<MapEntry_<key_type>_<value_type>[_<bound>][, <bound>]>
   Map_<key_type>_<value_type>[_<bound>];

Strings¶

The syntax for defining a string is as follows:

<string_type> ::= "string" "<" <positive_int_const> ">"
              |   "string"

Wstrings¶

The syntax for defining a wstring is as follows:

<wide_string_type> ::= "wstring" "<" <positive_int_const> ">"
                   |   "wstring"

Fixed Type¶

The fixed data type represents a fixed-point decimal number of up to 31 significant digits. The scale factor is a non-negative integer less than or equal to the total number of digits.

The fixed data type will be mapped to the native fixed point capability of a programming language, if available. If there is not a native fixed point type, then the IDL mapping for that language will provide a fixed point data types. The syntax of the fixed type is as follows:

<fixed_pt_type> ::= "fixed" "<" <positive_int_const> "," <positive_int_const> ">"
<fixed_pt_const_type> ::= "fixed"

Complex Types¶

Arrays¶

The syntax for array is as follows:

<array_declarator> ::= <identifier> <fixed_array_size>+
<fixed_array_size> ::= "[" <positive_int_const> "]"

Example of array type declarations:

i32 myi32array[32];
string mystrarray[32];

Native Types¶

The syntax for native types is as follows:

<type_dcl> ::= "native" <simple_declarator>
<simple_declarator> ::= <identifier>

Native types are not supported by FIWARE Middleware. Any FIWARE Middleware IDL parser has to inform users about this and ignore this definition.

Exception Declaration¶

Exception declarations permit the declaration of struct-like data structures, which may be returned to indicate that an exceptional condition has occurred during the performance of a request. The syntax is as follows:

<except_dcl> ::= "exception" <identifier> "{" <member>* "}"

Example of an exception declaration:

exception myException {
   string msg;
   i32 code;
};

Operation Declaration¶

Operation declarations in OMG IDL 3.5 and FIWARE Middleware IDL are similar to C function declarations. The syntax is as follows:

<op_dcl> ::= [ <op_attribute> ] <op_type_spec>
             <identifier> <parameter_dcls>
             [ <raises_expr> ] [ <context_expr> ]
<op_attribute> ::= "oneway"
<op_type_spec> ::= <param_type_spec>
               | "void"

Example of an operation declaration:

service myService {
    void set(i32 param);
    i32 get();
    i32 add(i32 param1, i32 param2) raises (myException);
};

An operation declaration consists of:

An optional operation attribute that is supported by FIWARE Middleware IDL for backward compatibility. Operation attributes are described in section Operation attribute.
The type of the operation’s return result. Operations that do not return a result must specify the void type.
An identifier that names the operation in the scope of the interface in which it is defined.
A parameter list that specifies zero or more parameter declarations for the operation. Parameter declaration is described in section Parameter Declarations.
An optional raises expression that indicates which exception may be raised as a result of an invocation of this operation. Raises expression are described in section Raises Expressions.
An optional context expression that is inherited from OMG IDL 3.5, but FIWARE Middleware will not use. Context expressions are described in section Context Expressions.

Operation attribute¶

The syntax for operation attributes is as follows:

<op_attribute> ::= "oneway"

This attribute is supported in FIWARE Middleware for backward compatibility. But in FIWARE Middleware IDL the preferedby way to define a oneway function is using the @Oneway annotation as described in section Oneway functions.

Parameter Declarations¶

Parameter declarations in FIWARE Middleware IDL operation declarations have the following syntax:

<parameter_dcls> ::= "(" <param_dcl> { "," <param_dcl> }* ")"
                 |   "(" ")"
<param_dcl> ::= [ <param_attribute> ] <param_type_spec> <simple_declarator>
<param_attribute> ::= "in"
                  |   "out"
                  |   "inout"
<raises_expr> ::= "raises" "(" <scoped_name> { "," <scoped_name> }* ")"
<param_type_spec> ::= <base_type_spec>
                  |   <string_type>
                  |   <wide_string_type>
                  |   <scoped_name>

The FIWARE Middleware IDL will not use output parameters, as modern IDLs do. It supports the keywords in, inout, and out, but any FIWARE Middleware IDL parser will inform users all parameters will be input parameters.

Raises Expressions¶

There are two kinds of raises expressions.

Raises Expression¶

A raises expression specifies which exceptions may be raised as a result of an invocation of the operation or accessing a readonly attribute. The syntax for its specification is as follows:

<raises_expr> ::= "raises" "(" <scoped_name> { "," <scoped_name> }* ")"

The <scoped_name>s in the raises expression must be previously defined exceptions.

getraises and setraises Expression¶

The syntax is as follows:

<attr_raises_expr> ::= <get_excep_expr> [ <set_excep_expr> ]
                   |   <set_excep_expr>
<get_excep_expr> ::= "getraises" <exception_list>
<set_excep_expr> ::= "setraises" <exception_list>
<exception_list> ::= "(" <scoped_name> { "," <scoped_name> }* ")"

getraises and setraises expressions are used in attribute declarations. Like in attribute declarations, theses expressions are supported by FIWARE Middleware IDL but not by FIWARE Middleware. Any FIWARE Middleware IDL parser has to inform users about this and it will ignore these expressions.

Context Expressions¶

The syntax for content expressions is as follows:

<context_expr> ::= "context" "(" <string_literal> { "," <string_literal> }* ")"

Context expressions are supported by FIWARE Middleware IDL but not by FIWARE Middleware. Any FIWARE Middleware IDL parser has to inform users about this and it will ignore these expressions.