Internet of Things Architecture

Log transactions

Apply circular logging

strategy (DC A.6)

[De 2012]

Information model

needs concepts for

transactions with

unique identifiers

Storage for transaction

logs needed

Apply archive logging

strategy (DC A.7)

[IBM 2012]

Like above, but

transactions need to

be marked as either

active or inactive

additionally

External storage needed

for large logs

Design for failure

Provide functionality

to reserve spare

resources and

replace failed ones

(DC A.8)

[Newtelligence2

012]

No impact

Spare resources are

kept on hold until an

operating resource

needs to be replaced,

requires higher amount

of resources

Prefer Service

Choreography FC

over Service

Orchestration FC

(Section 4.2.2)

Identifiers in

Information model

need to be unique for

clones of FCs and

across distributed

system

No single FC or

centralised FC (DC A.9)

Provide FC that

monitors latency (DC

A.10)

Provide means to

specify latency and

timeout limits

No impact

Allow for
component
replication

Provide FC that

implements State-

machine (active)

replication (DC

A.11) [Wikipedia

2013d]

FC needs to be

modelled as state-

machine

To support F failures

you must have at least

2F+1 replicas of the

component

Provide FC that

Implement

transactional

replication (DC A.12)

[Microsoft

2013]

Also Incremental

changes of information

can be replicated,

leads to inconsistency,

though, if not

completed

Good performance, near

real-time replication

possible

Provide FC that

implements Virtual

synchrony (DC A.13)

[Wikipedia,

2013e]

Make replicated

information

indistinguishable non-

replicated information

Very high performance

Relax
transactional
consistency (DC
A.14)

Requires conflict

resolution

functionality

No impact Needs more resources

through replication