8. Release Notes¶

8.1. Release Notes v5.3.1¶

8.1.1. Supported Platforms¶

RTI® Web Integration Service is supported on the platforms in Table 8.1.

Table 8.1 Supported Platforms in 5.3.1¶
Platform	Operating System
Linux® (Intel® CPU)	CentOS 6.0, 6.2, 6.3, and 6.4 Red Hat® Enterprise Linux 6.0-6.8 Red Hat® Enterprise Linux 7.0 SUSE® Linux Enterprise Server 11 SP2 and SP3 Ubuntu® Server 12.04 LTS, 14.04 LTS, and 16.04 LTS
Mac®	All OS X® platforms in the RTI Connext DDS Core Libraries Release Notes with the same version number.
Windows®	All Windows platforms listed in the RTI Connext DDS Core Libraries Notes for the same version number.

8.1.2. Compatibility¶

8.1.2.1. Connext DDS Compatibility¶

Web Integration Service can be used to bridge data from applications built with RTI Connext DDS™, as well as RTI Data Distribution Service 4.5[b-e], and 4.4d, except as noted below.

Web Integration Service is not compatible with applications built with RTI Data Distribution Service 4.5e and earlier releases when communicating over shared memory. For more information, please see the Transport Compatibility section in the RTI Connext DDS Core Libraries Release Notes.
Starting in Connext DDS 5.1.0, the default message_size_max for the UDPv4, UDPv6, TCP, Secure WAN, and shared-memory transports changed to provide better out-of-the-box performance. Web Integration Service also uses the new value for message_size_max. Consequently, Web Integration Service is not out-of-the-box compatible with applications running older versions of Connext DDS or RTI Data Distribution Service. Please see the RTI Connext DDS Core Libraries Release Notes for instructions on how to resolve this compatibility issue with older Connext DDS and RTI Data Distribution Service applications.

8.1.3. What’s Fixed¶

8.1.3.1. CRLF Line-Endings in rtiwebintegrationservice Script¶

In the original release of RTI Connext DDS 5.3.1, rtiwebintegrationservice – the script that runs RTI Web Integration Service on Unix-like systems (that is, Linux and OS X) – contained CRLF line-endings, which prevented the script from executing. This issue has been resolved.

8.2. Release Notes v5.3.0¶

8.2.1. Supported Platforms¶

RTI® Web Integration Service is supported on the platforms in Table 8.2.

Table 8.2 Supported Platforms in 5.3.0¶
Platform	Operating System
Linux® (Intel® CPU)	CentOS 6.0, 6.2, 6.3, and 6.4 Red Hat® Enterprise Linux 6.0-6.8 Red Hat® Enterprise Linux 7.0 SUSE® Linux Enterprise Server 11 SP2 and SP3 Ubuntu® Server 12.04 LTS, 14.04 LTS, and 16.04 LTS
Mac®	All OS X® platforms in the RTI Connext DDS Core Libraries Release Notes with the same version number.
Windows®	All Windows platforms listed in the RTI Connext DDS Core Libraries Notes for the same version number.

8.2.2. Compatibility¶

8.2.2.1. Connext DDS Compatibility¶

Web Integration Service can be used to bridge data from applications built with RTI Connext DDS™, as well as RTI Data Distribution Service 4.5[b-e], and 4.4d, except as noted below.

Web Integration Service is not compatible with applications built with RTI Data Distribution Service 4.5e and earlier releases when communicating over shared memory. For more information, please see the Transport Compatibility section in the RTI Connext DDS Core Libraries Release Notes.
Starting in Connext DDS 5.1.0, the default message_size_max for the UDPv4, UDPv6, TCP, Secure WAN, and shared-memory transports changed to provide better out-of-the-box performance. Web Integration Service also uses the new value for message_size_max. Consequently, Web Integration Service is not out-of-the-box compatible with applications running older versions of Connext DDS or RTI Data Distribution Service. Please see the RTI Connext DDS Core Libraries Release Notes for instructions on how to resolve this compatibility issue with older Connext DDS and RTI Data Distribution Service applications.

8.2.3. What’s New¶

8.2.3.1. Changes in XML and JSON Data Representation¶

This release introduces a few changes in the data representation in XML and JSON format.

Octets are now represented using a decimal value. For example:

<data>
     <anOctet>255</anOctet>
 </data>

{
    "anOctet": 255
}

Enumeration literals are now represented as strings by default. You may use the enumsAsIntegers query parameter to enable the old behavior (see Table 5.20).

<data>
    <anEnum>ACE</anEnum>
</data>

{
    "anEnum": "ACE"
}

Characters and Wide Characters now support escape sequences to represent non-printable characters. For example:

<data>
    <myChar1>a</myChar1>
    <myChar2>&#x2605;</myChar2>
    <myWChar1>b</myWChar2>
    <myChar2>&#x2605;<myWChar2>
</data>

{
    "myChar1": "a",
    "myChar2": "\u2605",
    "myWChar1": "b",
    "myWChar2": "\u2605"
}

Likewise, Strings and Wide Strings now support escaped sequences to represent non-printable characters.

<data>
    <aString>El r&#x00ED;o mi&#x00F1;o</aString>
</data>

{
    "aString": "El r\u00EDo mi\u00F1o"
}

An Instance Handle is now represented as a string, where each element of the old sequence is represented in hexadecimal. For example:

<instance_handle>580BA4179B1A6D6B4CD7CE4F54B3B63C</instance>

{
    "instance_handle": "580BA4179B1A6D6B4CD7CE4F54B3B63C"
}

8.2.3.2. New Parameters to Configure Sample Representation¶

This release introduces a new set of parameters to configure sample representation when reading through the GET operation on a DataReader. Before this release, you could only choose the format representation via the sampleFormat query parameter, now you can also use:

prettyPrint, which produces a response body with indentation and line breaks. By default the response body of the read operation is represented in a compact format without indentation and line breaks (i.e., prettyPrint = False).
enumsAsIntegers, which produces a response body where enumeration literals are represented as integers rather than strings. By default, enumeration literals are represented as strings (i.e., enumsAsIntegers = False).

8.2.3.3. New Examples¶

Web Integration Service includes new examples as part of the installation. These can be found under <path to examples>/web_integration_service.

8.2.3.4. Admin Console Support¶

RTI Admin Console has added support for Web Integration Service. You can now use Admin Console to browse the entities created by Web Integration Service and their associated QoS settings.

8.2.3.5. Support for NaN and Infinity in XML and JSON Data Representation¶

This release adds support for the representation of out-of-bound members in XML and JSON data samples.

In XML, not-a-number values (NaN) and infinity values are represented as follows:

<aValue>nan</aValue>
<anotherValue>inf</anotherValue>

In JSON format NaN and Infinity values are represented according to the ECMAScript specification. That is:

{
    "aValue": "\"NaN\"",
    "anotherValue": "\"Infinity\""
}

8.2.3.6. Attribute Kind in <register_type> XML Tag is No Longer Necessary¶

The attribute kind in the <register_type> XML tag is no longer required and its use is deprecated. This change does not affect the way Web Integration Service registers types.

Web Integration Service will still load configurations using the attribute kind, but it will log a warning similar to this:

DDS_XMLRegisterType_initialize:XML attribute 'kind' in tag <register_type> is
deprecated and will be ignored

8.2.3.7. Upgraded to CivetWeb v1.9.1¶

Web Integration Service has upgraded the version of its embedded web server—CivetWeb—to v1.9.1. For more information on CivetWeb, please see the Release Notes document on GitHub.

8.2.3.8. Support for Built-in Heap Monitoring¶

Web Integration Service incorporates a built-in heap memory monitor that provides a way to analyze the heap allocations performed at the service and RTI Connext DDS layers. You can use heap monitoring through the command line with the following options:

heapSnapshotPeriod <sec> Enables heap monitoring and generates a heap snapshot every <sec>.
heapSnapshotDir <dir> Specifies the output directory where the heap monitoring snapshots are dumped. The generated dump files have the following name: RTI_heap_<processId>_<index>.log, where <processId>` is the process ID of the service execution, and ``<index> is an integer that automatically increases each snapshot period.

For details related to the format of the snapshot files, see the API Reference HTML documentation for Connext DDS.

8.2.4. What’s Fixed¶

8.2.4.1. Error Listing Types Defined in Different Configuration Files¶

When listing the types available in the system, Web Integration Service would display only types defined in the default configuration file, RTI_WEB_INTEGRATION_SERVICE.xml, or loaded via the REST API. Types defined in USERS_WEB_INTEGRATION_SERVICE.xml and other configuration files were excluded from the list. This problem has been resolved.

[RTI Issue ID WEBINT-112]

8.2.4.2. Waitsets did not Awaken when Web Integration Service was Closed¶

Client applications can configure a maxWait time to wait for a number of read conditions when calling GET on a DDS DataReader to read data. This functionality blocks the thread that handles the HTTP request using a DDS Waitset.

In Web Integration Service 5.2.3 and earlier, DDS Waitsets used throughout the service did not include a condition that would unblock them upon the reception of a signal to close the service (e.g., a signal generated by a CTRL+c command). As a result, after you entered CTRL+c, Web Integration Service would not exit until all DDS Waitsets had timed out. This problem has been resolved.

[RTI Issue ID WEBINT-127]

8.2.5. Known Issues¶

8.2.5.1. Configurations and Their Applications cannot use Same Name¶

Due to current limitations in Connext DDS’s XML Parser, the name of the Web Integration Service configuration tag and the name of the applications within that configuration cannot be the same. For example:

<web_integration_service name="ShapesDemo">
    <application name="ShapesDemo"/>
</web_integration_service>

To workaround this limitation, use different names for the service configuration tag and the applications within. For example:

<web_integration_service name="ShapesDemo">
    <application name="ShapesDemoApplication"/>
</web_integration_service>

[RTI Issue ID CORE-3542]

8.3. Release Notes v5.2.3¶

8.3.1. Supported Platforms¶

RTI® Web Integration Service is supported on the platforms in Table 8.3.

Table 8.3 Supported Platforms in 5.2.3¶
Platform	Operating System
Linux®	CentOS 5.4, 5.5 CentOS 6.0, 6.2-6.4 Red Hat® Enterprise Linux 5.0, 5.1, 5.2, 5.4, 5.5 Red Hat Enterprise Linux 6.0-6.5 Red Hat Enterprise Linux 7 Ubuntu® Server 12.04 LTS and 14.04 LTS
Mac®	Mac OS X 10.8 Mac OS X 10.10 Mac OS X 10.11
Windows®	All Windows platforms listed in the RTI Connext DDS Core Libraries Platform Notes for the same version number.

8.3.2. Compatibility¶

8.3.2.1. Connext DDS Compatibility¶

Web Integration Service can be used to bridge data from applications built with RTI Connext DDS™, as well as RTI Data Distribution Service 4.5[b-e], and 4.4d, except as noted below.

Web Integration Service is not compatible with applications built with RTI Data Distribution Service 4.5e and earlier releases when communicating over shared memory. For more information, please see the Transport Compatibility section in the RTI Connext DDS Core Libraries Release Notes.
Starting in Connext DDS 5.1.0, the default message_size_max for the UDPv4, UDPv6, TCP, Secure WAN, and shared-memory transports changed to provide better out-of-the-box performance. Web Integration Service also uses the new value for message_size_max. Consequently, Web Integration Service is not out-of-the-box compatible with applications running older versions of Connext DDS or RTI Data Distribution Service. Please see the RTI Connext DDS Core Libraries Release Notes for instructions on how to resolve this compatibility issue with older Connext DDS and RTI Data Distribution Service applications.

8.3.2.2. Command-Line Options Compatibility¶

Starting in Web Integration Service 5.2.3, you must use -cfgName to specify the configuration to be used when instantiating all the applications.

8.3.2.3. XML Compatibility¶

Starting in Web Integration Service 5.2.3, <application> tags are children of <web_integration_service> tags. As a result, only the applications under the configuration indicated via the -cfgName command-line option are instantiated when the service is started. In previous versions, all the applications were children of the <dds> top-level tag and were automatically instantiated when the service was started.

8.3.3. What’s New In 5.2.3¶

8.3.3.1. JSON Support for Writing and Reading Samples¶

Users can now write and read data samples using JSON. This complements the default XML format, making it simpler to map the data samples that are sent and received with Javascript objects. However, the definition of entities and QoS settings must be done in XML.

8.3.3.2. Simple Authentication Mechanism¶

Web Integration Service implements a simple authentication mechanism that ensures—if enabled—that only client applications with the appropriate API key can perform operations via the REST API. API keys are stored in an Access Control List file that can be created with Web Integration Service’s executable. HTTPS must be enabled to ensure that API keys are not intercepted by malicious applications.

8.3.3.3. Service Configurations¶

For consistency with other RTI infrastructure services such as Routing Service or Persistence Service, we have introduced the concept of a Web Integration Service configuration. A service configuration contains a set of applications that are instantiated when the service is loaded. As a result, users need to specify a configuration when starting the service. Applications created via Web Integration Service’s REST API will automatically be appended to the list of applications under the running configuration.

8.3.3.4. Improved Debugging Messages¶

To make it simpler to debug an application, Web Integration Service provides detailed logging information when the service is run with verbosity levels of 5 or greater. These messages are logged via command line and can be enabled using the -verbosity command-line option.

8.3.3.5. Query Strings to Configure Elements to Read from DataReader’s Queue¶

We have added a set of query strings to select the samples from the DataReader’s queue that must be read or taken. This includes filtering samples based on status conditions and filter expressions. We have also added the ability to configure whether to perform a take or a read operation (i.e., whether the samples read must be deleted from the DataReader’s cache or not).

8.3.3.6. Updated REST APIs to Comply with the Latest Revision of Web-Enabled DDS OMG Specification¶

Changed DomainParticipant’s resource name on URLs from participants/ to domain_participants/.
Changed DataWriter’s and DataReader’s resource name on URLs from datawriters/ and datareaders/ to data_writers/ and data_readers/.
Changed the default value of the Content-Type header from application/webdds+xml to application/dds-web+xml.
Added support for OMG-DDS-API-Key header.
Changed XML tags from “camelCase” to “snake_case” in the read data samples in the data and metadata sections.

8.3.4. What’s Fixed¶

8.3.4.1. Error Generating Log Messages with More than 1000 Characters¶

We have normalized the error message representation that we include in HTTP responses. As a result, we have fixed a crash in Web Integration Service when logging error messages longer than 1,000 characters.

[RTI Issue ID WEBINT-88]

8.3.4.2. Error Accessing Web Integration Service Concurrently¶

We have fixed a thread-safety issue in the internal DDS functions that look up entities. Because these functions were not thread safe in previous versions of RTI Connext DDS, concurrent access to Web Integration Service could result in a hang that required a service restart.

[RTI Issue ID WEBINT-98]

8.3.5. Known Issues¶

8.3.5.1. Configurations and Their Applications cannot use Same Name¶

Due to current limitations in Connext DDS’s XML Parser, the name of the Web Integration Service configuration tag and the name of the applications within that configuration cannot be the same. For example:

<web_integration_service name="ShapesDemo">
    <application name="ShapesDemo"/>
</web_integration_service>

To workaround this limitation, use different names for the service configuration tag and the applications within. For example:

<web_integration_service name="ShapesDemo">
    <application name="ShapesDemoApplication"/>
</web_integration_service>

[RTI Issue ID CORE-3542]