Initially it was attempted to realize the above architecture via the public FIWARE Lab platform but we found some isssues.
In a later stage the above setup was realized within the Geonovum (Ubuntu/Linux) server VPS. Some info follows:

Registering at the international FIWARE Lab worked ok, but could not get
the Orion CB with the IDAS IoTAgent working. The interaction between the two
seemed to be broken. This was reported, see specifics here
on StackOverflow:

After an unsuccessful attempt to compile and run the OCB and IoT Agent on Ubuntu 14.04-3
it was decided to use Docker on the Geonovum SOSPilot VPS (Ubuntu/Linux server VPS).
Via Docker seems the best/recommended option anyway as CentOS is the primary
target platform for FIWARE. See next sections.

Finally a custom Dockerfile was created for OCB to include Rush (and Redis) as an extension of the fiware/orion
Docker file to support HTTPS notifications for OCB subscriptions (see WireCloud below).
This is the content of the geonovum/orionrush Dockerfile:

MQTT is a machine-to-machine (M2M)/”Internet of Things” connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport.

We will use Mosquitto as MQTT-client first:

Mosquitto is an open source (BSD licensed) message broker that implements the MQ Telemetry Transport protocolversions 3.1 and 3.1.1. MQTT provides a lightweight method of carrying out messaging using a publish/subscribe model.

A quick local solution is to manually add the HTTP header using the browser’s Developer Tools to a WireCloud Widget JavaScript (usually main.js)
where the HTTP request to the Orion NGSI API is created. The WC NGSI connector supports adding extra HTTP headers
as per the NGSI documentation.
See for example here below where the Chrome developer tools is used to modify the NGSIConnection :

Quick Fix: modify the HTTP header locally in browser

Another possibility is to download the widget, modify its config.xml and main.js to support configuring the FIWARE-Service header.
This worked as well, but the real fixes should be done within the component source code. The issue affects all WC components
(Operators, Widgets) that interact with Orion NSGI. The following issues have been opened:

Using the NGSI Browser Widget (fixed v1.0.1) with an
NSGI Entity to POI Converter
connected to a Map Widget the temperature could be made visible on a map. The result of the mashup is below.

First WireCloud Mashup: show Temperature from sensor as POI

The wiring for these components was as depicted below.

First WireCloud Mashup: wiring view in editor

Next attempt was to use NGSI Subscriptions such that the widgets receive real-time updates.
For this the NGSI Source Operator
can be applied i.s.o. the NGSIBrowserWidget used above. The NGSISourceOperator will use
NGSI10 Subscriptions to register at an Orion CB using a callback mechanism. The wiring is depicted below.

Second WireCloud Mashup: wiring view in editor

The NGSISourceOperator was first fixed via issue 3
such that the Fiware-service HTTP-header could be applied. But since the Orion CB runs without HTTPS within
a remote (Docker) service, callbacks via HTTPS did not work. Also using HTTP via proxy http://ngsiproxy.lab.fiware.org did not
work because of browser security restrictions. These problems have been documented and discussed
in this issue. Polling mode may be another solution
but possibly too strenous.

Using an HTTPS middleman Relayer, Rush,
is suggested as a solution. This was tried first. The final range of commands is:

In order to facilitate viewing data in standard geo-web viewers, an
OpenLayers NGSI10 Vector Layer
component was developed. This allows
viewers like the existing project HeronViewer to show (real-time)
sensor data.

Below is a screenshot of the HeronViewer showing in blue dots 2 “bot-sensors” and the CityGIS Dustduino-based
sensor. All show a temperature in realtime.

The Short Term History (STH) component stores timeseries data. This is achieved by a subscribeContext on the
Orion CB NGSI10 API. This has to be done explicitly. Documentation can be found here: https://github.com/telefonicaid/fiware-sth-comet

In our setup we fire a curl script to trigger a generic subscription on the thing entity:

This triggers a flow of data from the Orion CB via the STH to MongoDB. Via the STH REST API we can request timeseries
data. As we need to send Fiware-HTTP headers we can invoke the STH API using a (Chrome) REST client as follows:

apt-getinstallcmakesconslibmicrohttpd-devlibboost-all-dev# what about libcurl-dev gcc-c++ ?apt-get-yinstallmakecmakebuild-essentialsconsgitlibmicrohttpd-devlibboost-devlibboost-thread-devlibboost-filesystem-devlibboost-program-options-devlibcurl4-gnutls-devclanglibcunit1-devmongodb-serverpythonpython-flaskpython-jinja2curllibxml2netcat-openbsdmongodbvalgrindlibxslt1.1libssl-devlibcrypto++-devSettinguplibboost1.54-dev(1.54.0-4ubuntu3.1)...Settinguplibboost-dev(1.54.0.1ubuntu1)...

Install the Mongo Driver from source:

mkdir-p/opt/mongodbcd/opt/mongodbwgethttps://github.com/mongodb/mongo-cxx-driver/archive/legacy-1.0.2.tar.gztarxfvzlegacy-1.0.2.tar.gzcdmongo-cxx-driver-legacy-1.0.2scons# The build/linux2/normal/libmongoclient.a library is generated as outcomesudosconsinstall--prefix=/usr/local# This puts .h files in /usr/local/include/mongo and libmongoclient.a in /usr/local/lib

mkdir-p/opt/googlemockcd/opt/googlemockwgethttp://googlemock.googlecode.com/files/gmock-1.5.0.tar.bz2tarxfvjgmock-1.5.0.tar.bz2cdgmock-1.5.0./configuremakesudomakeinstall# installation puts .h files in /usr/local/include and library in /usr/local/libsudoldconfig# just in case... it doesn't hurt :)