In case we would like to create an external application and we aren't sure what's the best solution to use, below are some useful tips.
Let's say we use a gateway in order to access the external application we want to create. We would like to implement this gateway translating the ThingWorx standard protocol to the SCADA protocol. The system administrator, who manages the grid, has the own secure system, with a standard for communication inside the SCADA system, and we want to be able to get data from our system to the system they have.
Let's also consider that the data is connected on the electrical field.
It is recommended to develop a 3rd party that on one side talks to ThingWorx, and on the other side, talks to the SCADA system.
This external ThingWorx application that we want to implement would have a series-edge-interface allowing to enter in our customer's Ethernet network, in order for both systems to communicate.
JDBC is not recommended - it's mostly for connecting to the data base, which in our case is not the main purpose.
Each REST API call to the platform uses a security accreditation (appkey or user/password); depending of the permissions contained in that token, the access can be allowed to certain parts of the platform. Reasons for using REST API:
REST API is simple and not dependent on any format that the data comes from ThingWorx.
It can be used offline, online, synchronously, asynchronously, and is easy to manage from a formatting point of view.
ThingWorx can give a lot of options: like exporting information via xml to a plain xml file, to parse it to whatever protocol we have on the other hand:
Either our application would have to handle xml inputs from ThingWorx and process it towards SCADA compatible output.
Or our application will have to handle xml input from ThingWorx and process it towards SCADA compatible output.
Or we can talk directly via REST API and read on a per-thing basis (using the web services).
The interface application just has to know how to read xmls or REST API calls (which are provided with an xml formatted response).
SDK has already library written in C, C# and Java.
SDK C, C# and Java use the AlwaysOn protocol (web socket) and are more firewall friendly.
It's mostly like for speed and automated processing, so when known exactly what happens and we trust the other side and we know there are little chances for errors.
If we go with REST API or SDK , the application that is developed will have complete access inside ThingWorx, like change/edit the things.
If we want to have access in both ways, not only in reading data, but also in update/delete information, etc, SDK and REST API can be used, because we have the whole range of commands, like set property values, call on services, etc. We can limit access, if we want, for security reasons. SDK offers access to the same services as REST API, but in a different way.
Otherwise, it's better to go with xml decoupled files.
Conclusion: for this particular scenario, better use SDK.