Oh I wondered how good the security questions and availability questions are solved here for IoT. Now I know: "Error displaying the error page: Application Instantiation Error: Could not connect to MySQL."
Dart is still very much alive and well. The original plan to integrate it into Chrome was cancelled, however the plan has changed to focus on more than just the web as well.
And while we love Dart, we don't depend on the language. We can (and have, and will continue to) write SDKs for other languages. Current ones are Dart, JavaScript, Ruby, Java, and a Python SDK is in the works. Also on our list is a C SDK.
One thing that will set us aside is we want to integrate ALL of these protocols (provided we are able to) with DSA. DSA will be able to interact with them seamlessly. DSLinks allow you to write a sort of 'protocol translator' into our protocol. We aren't device based, we are service based.
yet another iot platform/framework, who is behind this project? quite some code are there, but document is rare.
it's using dart and java after a quick look at the github pages.
also I agree DSA is a bad name when this platform is addressing security for IoT, the NodeAPI also is a bit misleading, I would feel it has something to with NodeJS.
On the main page of DGLogik's website, Schneider Electric and Cisco are listed as users of DGLogik's technology. Both companies are part of the IEEE P2413 working group:
While I appreciate the intent, the problem with all of these "IoT frameworks" is that they were designed by people with a device view. They are oblivious to, and typically poor for, what the aggregate architectures look like at scale where you bring all of this IoT data together either logically or physically.
To get in the right frame of mind for IoT platform design, think of a mobile carrier network with 100 million subscribers as a single geographically-distributed computing system that extends all the way to the mobile phone. The complex topological constraints implied by that means, from top to bottom, making systems scale requires software architectures that are substantially different from the web. For starters, they need to be deeply aware of the spatial, temporal, and topological relationships between nodes, which is much closer to massively parallel computing models than a traditional web-oriented distributed system. (In massively parallel systems computation is literally and noticeably relativistic, and with topologies that place complex restrictions on how computations can flow between compute nodes. If you do not explicitly account for this in your architecture, scaling will be significantly sublinear.)
This leads to the situation today where you have a dozen different "IoT platforms/protocols" all being furiously pushed into the market as de facto or actual standards, but if you look at the companies with real experience building large-scale IoT architectures they use none of it because it doesn't deliver for real-world systems. A lot more thought needs to go into the requirements for an IoT platform; it looks nothing like a web architecture.
The basis of DSA is to integrate all these protocols into a single protocol that can be spoken. This is evident by our support of existing protocols. We don't aim to become device based. We are completely distributed. DSLinks can run on any machine and can connect to the broker to communicate data.
> They are oblivious to, and typically poor for, what the aggregate architectures look like at scale where you bring all of this IoT data together either logically or physically...
> For starters, they need to be deeply aware of the spatial, temporal, and topological relationships between nodes...
I'm not totally clear on what you mean by this. Can you elaborate? It sounds to me like you're commenting on the difficulties of implementing distributed sensor grids using existing IoT platforms (which is a very valid complaint), but not all IoT applications are meant for that. Yes, on the one side, smart electric meters connect to a smart grid, but on the other hand, smart thermostats may only need to connect to smart heaters (in the same home). Ideally the latter connection happens without ever talking to some server on the internet.
I agree, though, that IoT entirely breaks web architecture, even just on a logistical level. Forbes put out a meta-analysis last year (http://goo.gl/S0IqvF) projecting a doubling of internet-connected devices by 2020, with 75% of the expansion coming from non-traditional devices like sensor grids. Those tend to "want" to be servers a whole lot more than traditional devices, and assuming even 1% of that growth needs to be secured, you're looking at about 50 times as many SSL certificates as have been issued total, to date, in the history of the internet.
We don't just need new platforms, we need entire new protocols.
Aggregation at scale is even more complicated than just the number of devices. If you want the conversation to be bidirectional over the highly NAT-driven internet, you will probably want the connection to be persistent. This means you can poll or command a device from the server as well as have your device send requests to the server. This is not directly similar to a web service model, which is based on many fast, transient connections. Latency might also be a question for you, if you have human real time users. We haven't even spoken about sensor data streaming in from millions of devices while you're trying to talk to them. Then you get into availability and redundancy and other guarantees, it gets really interesting. Did I mention security (hello, Samsung?), unless you want miners and spambots running on all your devices, you're now talking secure images and real crypto on a flyweight embedded device.
Yes, there are bigger real world issues for IoT than the protocol.
Well, for starters, it's designed to be completely distributed. I only had time to glance at openHAB a bit, but from what I see, it's rather centralized with the services being distributed. DSA is entirely distributed. All DSLinks (Protocol Transformers, Data Providers, and Data Readers) can run completely remote of the server. The DSA broker (what connects all these DSLinks together) is distributed too, it can switch DSLinks over to other brokers if it fails by using a system that assigns backup brokers. Also, DSA supports binary data like images, videos, etc. DSA also can form a network of brokers. Brokers can connect to other brokers, to multiple brokers as well.
29 comments
[ 16.8 ms ] story [ 90.4 ms ] threadGoogle Will Not Integrate Its Dart Programming Language Into Chrome
http://techcrunch.com/2015/03/25/google-will-not-integrate-i...
- HomeKit - Apple - https://developer.apple.com/homekit/
- Weave (& Brillo) - Google - https://developers.google.com/brillo/ (corrected - Thank you, @asciimike)
- AllJoyn - Started by QualCom, now backed by the AllSeen alliance (hosted by the Linux Foundation) - https://allseenalliance.org/
- IoTivity - Open Interconnect Consortium (OIC) (also hosted by the Linux Foundation) - https://www.iotivity.org/
http://www.mbed.com/en/
it's using dart and java after a quick look at the github pages.
also I agree DSA is a bad name when this platform is addressing security for IoT, the NodeAPI also is a bit misleading, I would feel it has something to with NodeJS.
http://www.dglogik.com/
Given the nature of their products, I think it's reasonable to conclude that DGLogik is behind the project.
In Spring 2014, they were part of a startup incubator sponsored by Cisco:
http://newsroom.cisco.com/press-release-content?type=webcont...
On the main page of DGLogik's website, Schneider Electric and Cisco are listed as users of DGLogik's technology. Both companies are part of the IEEE P2413 working group:
http://grouper.ieee.org/groups/2413/member-list.html
It will be interesting to see if DSA's design ends up influencing the direction of P2413.
Any thoughts on IEEE P2413?
To get in the right frame of mind for IoT platform design, think of a mobile carrier network with 100 million subscribers as a single geographically-distributed computing system that extends all the way to the mobile phone. The complex topological constraints implied by that means, from top to bottom, making systems scale requires software architectures that are substantially different from the web. For starters, they need to be deeply aware of the spatial, temporal, and topological relationships between nodes, which is much closer to massively parallel computing models than a traditional web-oriented distributed system. (In massively parallel systems computation is literally and noticeably relativistic, and with topologies that place complex restrictions on how computations can flow between compute nodes. If you do not explicitly account for this in your architecture, scaling will be significantly sublinear.)
This leads to the situation today where you have a dozen different "IoT platforms/protocols" all being furiously pushed into the market as de facto or actual standards, but if you look at the companies with real experience building large-scale IoT architectures they use none of it because it doesn't deliver for real-world systems. A lot more thought needs to go into the requirements for an IoT platform; it looks nothing like a web architecture.
> For starters, they need to be deeply aware of the spatial, temporal, and topological relationships between nodes...
I'm not totally clear on what you mean by this. Can you elaborate? It sounds to me like you're commenting on the difficulties of implementing distributed sensor grids using existing IoT platforms (which is a very valid complaint), but not all IoT applications are meant for that. Yes, on the one side, smart electric meters connect to a smart grid, but on the other hand, smart thermostats may only need to connect to smart heaters (in the same home). Ideally the latter connection happens without ever talking to some server on the internet.
I agree, though, that IoT entirely breaks web architecture, even just on a logistical level. Forbes put out a meta-analysis last year (http://goo.gl/S0IqvF) projecting a doubling of internet-connected devices by 2020, with 75% of the expansion coming from non-traditional devices like sensor grids. Those tend to "want" to be servers a whole lot more than traditional devices, and assuming even 1% of that growth needs to be secured, you're looking at about 50 times as many SSL certificates as have been issued total, to date, in the history of the internet.
We don't just need new platforms, we need entire new protocols.
Yes, there are bigger real world issues for IoT than the protocol.
http://www.openhab.org/