Ditto as
Digital Twin
"middleware"

{
  "thingId": "io.foo:car1",
  "policyId": "io.foo:car1",
  "attributes": {
    "manufacturer": "Foo",
    "data": {
      "serialNo": 4711
    }
  },
  "features": {
    "temp": {
      "properties": {
        "value": 23.42
      }
    }
  }
}

JSON repr. of a Thing

• by default, thing attributes and feature properties are "schemaless"
• a thing may be aware of one "definition"
• a feature may be aware of several "definitions"

• devices are not always connected to the net
• applications always need to be able to access their data
• twin vs. live access on API level

• Ditto contains a built-in authorization mechanism (Policies)
• every API call is authorized

{
    "policyId": "io.foo:car1-policy",
    "entries": {
      "owner": {
        "subjects": {
          "oidc:userid": {
            "type": "OpenID connect extracted userid"
          },
          "oidc:/claim": {
            "type": "OpenID connect extracted claim"
          }
        },
        "resources": {
          "thing:/": {
            "grant": ["READ","WRITE"],
            "revoke": []
          },
          "thing:/features/firmware": {
            "grant": [],
            "revoke": ["WRITE"]
          },
          "policy:/": {
            "grant": ["READ","WRITE"],
            "revoke": []
          }
        }
      }
    }
  }

• you must not
• Ditto has you covered

• devices send data in various formats
• Ditto provides structured APIs of things (attributes, features)
• devices don't need to be aware of Ditto

• modular architecture of Ditto services
• horizontal scalability of each Ditto service
• runtime dependency to MongoDB
• included monitoring (JVM metrics, roundtrips, MongoDB)
• codebase written in: Java