The second article in the 7-part Soaring Through the Clouds series, written by Oracle ACE Director Torsten Winterberg and Atilla Nemeth, describes the role Oracle's Internet of Things Cloud Service plays in a demo solution designed by a group of Oracle ACE Directors to allow community voting on the musical acts that might appear at an Oracle OpenWorld Appreciation Night concert.

By Torsten Winterberg and Atilla Nemeth

Table of Contents

2. Internet of Things Cloud Service
7. Mobile Cloud Service

Introduction

In our demo set up, we use Oracle Internet of Things Cloud Service (IOTCS) to consume all incoming data surrounding the vote for candidate artists for the next Oracle OpenWorld conference appreciation concert. This data can be sent by a “voting machine” that allows a user to vote for an artist by pressing a button. This voting machine could be simulated by a Raspberry Pi with buttons and a display attached to it. The “button press events” from each vote can be sent to IOTCS for further processing and pattern detection. This is very similar to the vending machine scenario we discussed during the OTN Virtual Technical Summit ( https://community.oracle.com/docs/DOC-996733).

To make things a bit simpler, and to allow you to reproduce the demo set up, we’ll use another vote input channel that doesn’t need any hardware: a small Java application (with some lines of Scala code) that collects votes from Twitter messages like “#ofmaces I vote for #bruce_newjersey”. This lets the audience participate in voting via Twitter and also generates an interesting enough amount of event data flowing into IOTCS for our demo setting. This small Twitter-collector application plays the role of a “thing” in the sense of the “Internet of Things.”

Figure 1

Figure 1 illustrates how this scenario fits into the full storyline of this series of articles. We collect the “#ofmaces” tweets (i.e., all the votes for artists for next Open World) and send them to IOTCS. When a pattern is detected within IOTCS—for example, if a certain threshold of votes for a single artist is exceeded—we call a process in PCS for further handling of the artist approval process.

Connecting a Thing to IOTCS

The “thing” we want to connect to IOTCS is our small Twitter-collector application. This application handles two SSL connections: one to Twitter to listen for the appropriate tweets and one to IOTCS to send the data for further processing. The Twitter part is handled by Scala filtering code, which, as you can see in the code base, you can download from GitHub: https://github.com/lucasjellema/aced-cloud-demo-ofmw2016-valencia/tree/master/IoTCS-Twitter/twitter-collector .

More interesting is the interaction with IOTCS. The first step is to register the thing—our application—as a new device in IOTCS. This can be done via the browser interface for individual devices or in batch mode for a longer list of devices. Note the shared secret field, which is is necessary later on, together with the generated device id, in order for our thing to establish a connection to IOTCS.

Figure 2

After the device is registered, it occurs in the device list with its state “registered” and type “not activated”.

Now we have to define a device model, the contract that a thing must follow when sending messages to IOTCS. In our case, this is very simple: we need only one attribute of type string named artistName to send the artist name that we extracted from the Twitter stream. You also could define actions here, the means by which the IOTCS would offer callback methods for others (e.g., applications or processes that would like to talk to the device from a “ process 2 device file:///C:/Users/brhubart/AppData/Local/Temp/Soaring%20Through%20the%20Clouds%20Part%201.docx#_msocom_1 [Office1] ” perspective). For simplicity, we show only the “device 2 process” direction here.

Figure 3

To be able to send data to IOTCS from our device, and from our Java class representing the device, we have to make an activation call to IOTCS containing the device ID and the shared secret. If successful, IOTCS answers with a private key that has to be stored by our “thing.” Any further calls are done using this private key. Have a look at the client side code for how this is done via the IOTCS API:

public void connect() throws GeneralSecurityException, IOException {
_// Create the device client instance
_ System.out.println("\nCreating the device instance...");
device = new DirectlyConnectedDevice();

_// Activate the device
_if (!device.isActivated()) {
device .activate(TWITTER_MODEL_URN);
}

_// Create a virtual device implementing the device model
_ DeviceModel deviceModel =
device .getDeviceModel(TWITTER_MODEL_URN);

virtualDevice = device.createVirtualDevice(device.getEndpointId(), deviceModel);
}

In this code, a DirectlyConnectedDevice is created, activated and connected to the device model we created in the previous step. But where have the device id and the shared secret gone? Well, this data is kept in a separate trusted keystore, which we also have to create:

java -cp lib/device-library.jar

com.oracle.iot.client.impl.trust.TrustedAssetsProvisioner -serverHost

iotserver -serverPort 7102 -truststore config/trustStore.jks -

truststorePassword changeit -taStorePassword changeit -sharedSecret

<SHARED_SECRET> -deviceId <DEVICE_ID>

The private key that we receive from IOTCS is also stored In this truststore. After starting the Twitter-collector application and making the first device call to IOTCS, the state of our device switches to “Activated” and our thing is ready to listen for tweets.

Figure 4

Creating an Exploration on the Data Stream

You can watch the incoming data in the “Data and Explorations” section in IOTCS. Note the incoming data with the timestamp and the actual payload that was sent from our “device.” The artist name we found at twitter is “bruce_newjersey”.

Figure 5

Now we want to find popular candidate artists in the incoming stream of data. We need to define a search pattern for this: we look for artists who cross a certain vote threshold in a certain period of time. In order to detect artists for which this is the case, we need to do some event analysis or so-called “stream processing.”

In the “Data and Explorations” section (as shown in Figure 5, above) we have to define a new exploration source by clicking “Add.” Here we chose the name “Artist names” and linked the exploration to the “Twitter Collector Model” device model we created in step 1:

Figure 6

Based on this exploration source, we pressed “Add” to add an exploration. When we open this exploration, the embedded Stream Explorer UI is opened and allows us to create a new exploration based on our newly-created event stream. In the screenshot below, you can see the filter criteria applied to this event stream looking for the occurrence of at least 3 votes for an artist within 60 seconds:

Figure 7

Note that in the table below file:///C:/Users/brhubart/AppData/Local/Temp/Soaring%20Through%20the%20Clouds%20Part%201.docx#_msocom_2 [Office2] you directly can see if the filter applied. What happens here? We listen on the incoming event stream with all artist voting data, filter this data, and let pass only the names of artists that appear at least three times in 60 seconds.

In the same way, you could make use of several aggregation functions or even typical detection patterns –like topN or the famous W-pattern from financial contexts, which looks for falling, rising, falling and rising again values. The “non-occurrence” of events can also be detected easily: do something when a specific event does NOT happen in a specific timeframe.

When your exploration is working fine, use the publish action to make the exploration available to IOTCS. This is the equivalent to the deployment you would have to do in the good old on-premise world.

Exposing the Resulting Data to ICS

We now want to send the data flowing through the newly created event channel containing only our filtered artists to a REST endpoint living in ICS. Therefore we create an “integration” in IOTCS. The only things we have to provide here are a name for the integration, the URL of the REST endpoint and the exploration from which the data is read.

Figure 8

Note that in the small table in the screenshot above you can again monitor the live data flowing through the system. When you tweet at least three times within one minute something like “#ofmaces I vote for #bruce_newjersey” you will see one entry in this table for bruce newjersey that was filtered out by Stream Explorer from the full event stream and sent by our integration to the ICS REST endpoint.

This all happened without writing a single line of code, except for the Java class representing our “thing.” Everything was configurable by the browser interface of IOTCS, which is very impressive.

Conclusion

IoT Cloud Service is great for connecting all kind of “things” to our enterprise backends. These things may be directly connected devices using the IOTCS device library or they may not be that “smart,” so that they have to use a gateway in the field running IOTCS gateway software. IOTCS abstracts from things and allows working with “resources” that can be handled and managed in the platform. Data is flowing into IOTCS and can be analyzed in various ways.

IOTCS provides device management features to handle large amounts of connected devices or gateways. It is the right solution to process high volumes of data flowing through the system, enabling real-time pattern matching and decision making. This feature set is provided by having an event store database under the hood and by leveraging an embedded version of Oracle Stream Explorer (SX) to detect pattern and special event conditions.

Outbound communication is done via “integrations” that abstract endpoints in our backend application landscape (e.g., each detected pattern occurrence can be sent to a new “event channel”). That means you can have more event channels inside of IOTCS than you have incoming data streams from outside. Then you could configure IOTCS in a way that it pushes data from the newly created (or existing) event channels via REST to an integration endpoint. This integration endpoint should be virtualized to prevent tight coupling with real system endpoints and better hide the real endpoints behind, for example, ICS, as we do in the full demo scenario described in this series of articles. Figure 1 in this article illustrates the pattern behind this: all systems as well as the processes running in PCS are hidden behind ICS. This allows for very flexible and decoupled architectures, with the advantage that development can be very decoupled simply by communicating the necessary interfaces. Maintenance gets much easier.

In the near future, we expect to see even more features in the area of fast data and big data technology and analysis within IOTCS, making it even more powerful.

All this is possible with a zero code approach inside IOTCS, which makes developing solutions based on this cloud platform offering very fast and easy.

About the Authors

Oracle ACE Director Torsten Winterberg works for Oracle Advantage Partner OPITZ CONSULTING as director of strategy and innovation and head of the SOA competence center. He has extensive experience as developer, coach and architect with a focus on the design and architecture of complex IT systems involving BPM, BPEL, ESB, BAM and service oriented architecture. He is a frequent speaker in the German Java community and has written numerous articles on SOA related topics.

Atilla Nemeth, lead consultant at OPITZ CONSULTING Deutschland GmbH, is certified as an Implementation Specialist in Oracle Service Oriented Architecture Infrastructure and Oracle Application Grid 11g.

This article represents the expertise, findings, and opinion of the author. It has been published by Oracle in this space as part of a larger effort to encourage the exchange of such information within this Community, and to promote evaluation and commentary by peers. This article has not been reviewed by the relevant Oracle product team for compliance with Oracle's standards and practices, and its publication should not be interpreted as an endorsement by Oracle of the statements expressed therein.