►
Description
Presentation @ MODELS 2020 (https://conf.researchr.org/details/models-2020)
In this Internet of Things (IoT) era, our everyday objects have evolved into the so-called cyber-physical systems (CPS).
The use and deployment of CPS has especially penetrated the industry, giving rise to the Industry 4.0 or Industrial IoT (IIoT).
Typically, architectures in IIoT environments are distributed and asynchronous, communication being guided by events such as the publication of (and corresponding subscription to) messages.
While these architectures have some clear advantages (such as scalability and flexibility), they also raise interoperability challenges among the agents in the network. Indeed, the knowledge about the message content and its categorization (topics) gets diluted, leading to consistency problems, potential losses of information and complex processing requirements on the subscriber side to try to understand the received messages.
In this paper, we present our proposal relying on \emph{AsyncAPI} to automate the design and implementation of these architectures using model-based techniques for the generation of (part of) event-driven infrastructures.
The prototype that implements this proposal as an open-source project is available at https://github.com/SOM-Research/asyncapi-toolkit
A
Hello,
everybody,
I'm
abel
gomez,
welcome
to
my
presentation
here
in
the
practice
innovation
track
of
models
2020,
I'm
going
to
present
this
work,
a
model-based
approach
for
developing
event-driven
architectures
with
a
sync
api.
This
is
a
joint
work
between
universitato
beta
catalonia
and
I
have
developed
this
work
together
with
marcel
iglesias,
turbieta
and
jordy
cabot.
A
Basically,
as
we
already
know,
there
are
more
and
more
devices
whose
hardware
and
software
parts
are
inherently
intertwined.
These
are
the
so-called
cyber
physical
systems.
These
are,
the
physical
systems.
Systems
are
able
to
communicate
to
each
other
without
requiring
any
kind
of
human
interaction,
but
these
physical
systems
are
normally
quite
limited
in
terms
of
resources,
so
most
of
the
data
they
acquire
must
be
sent
over
the
internet
to
other
services,
for
example
to
the
cloud.
A
Ikerlan,
it's
a
research,
one
of
the
well,
it's
a
research
center
that
belongs
to
one
of
the
largest
industrial
groups
in
spain,
that
is
mondragon
group
and
in
2019
inland,
had
a
revenue
of
21
million
of
euros.
So
here
we
have
an
institute
example
that
has
been
provided
by
ecoram
based
on
one
of
the
project.
They
are
developing
with
one
client,
and
here
what
we
have
is
one
setup
in
a
factory
where
we
have
different
lines
that
contain
presses
that
stamp
different
pieces
of
hardware.
A
So
in
this
case
this
monitoring
data
can
we
can
see
that
is
sent
in
json
to
a
message
broker
that
will
deliver
it
to
interested
parties.
Here
we
have
a
an
example
of
the
json
message
of
the
monitoring
data
that
is
sent,
for
example,
the
timestamp
and
the
value
in
pascals
of
the
press
that
is
being
done
by
the
press
itself.
A
So,
as
I
said,
for
example,
the
information
can
be
sent
to
the
cloud
to
process
them
and
to
detect
if
there
is
some
kind
of
malfunctioning
of
the
system,
but
for
example,
that
could
be
the
case
if
there's
no
care
from
part
of
the
developers
in
the
implementation
of
the
of
the
system.
That,
for
example,
could
be
the
case
that
the
name
of
the
topic
is
introducing
the
wrong
way.
A
For
example,
here
we
see
that
we
are
ending
the
topic
name,
we're
using
monitoring
instant,
monitor
or,
for
example,
that
the
topic,
the
message
is
sent
with
a
different
structure
than
the
one
expected
by
the
receiver,
for,
in
this
case
the
cloud.
So
in
this
case
this
can
cause
all
kind
of
malfunctioning
of
the
system.
We
can
lose
messages,
we
can
inform
a
lose
information.
We
can
have
runtime
problems
that
we
can
have
crash
across
of
the
system,
so
it's
really
difficult
to
maintain
consistency
in
this
kind
of
architectures.
A
So,
for
example,
this
is
the
specification
of
the
system.
I
have
just
shown
you.
It's
not
there's
no
need
to
see
the
details
of
the
specification,
but
you
can
see
that
it's
only
some
tenths
of
code
in
json,
so
we
can
distinguish
different
sections.
In
this
specification.
We
have
first
the
the
definition
of
the
version
of
a
sync
api
standard.
We
are
using
a
section
about
the
information
of
the
api,
a
section
about
the
servers
in
our
infrastructure,
a
section
of
the
channels
or
the
so-called
topics.
A
You
know
that
can
be
publish
and
subscribe
in
our
infrastructure
and,
finally,
some
kind
of
reusable
components
that
can
be
used
in
different
parts
of
our
of
our
definition.
So
if
you
look
into
data
into
the
details
of
this
specification,
for
example,
the
info
section
contains
the
title
of
the
api,
the
version
of
the
api,
the
license
of
the
api
etc,
for
example,
the
service.
As
I
said,
it
contains
the
list
of
servers
that
play
a
role
in
our
infrastructure.
A
A
That
is
also
defined
in
the
other
section
that
it's
a
schemas
of
the
components
section.
So
finally,
we
have
this
schema
for
the
line
info
object.
It
is
this
is
done
using
json
json
schema.
This
is
a
simple
definition:
injection
schema
and
the
same
for
press
info.
So
basically,
this
is
all
the
information
that
we
can
capture
about
the
example.
I
have
just
shown
you,
but
at
the
moment
we
define
it
or
we
decided
to
use
a
sync
api.
A
Api,
so
this
is
basically
our
approach,
so
we
start
from
the
same
kpi
specification
and
we
manually
have
defined
the
async
api
grammar
using
x
text.
We
have
paid
attention
to
do
kind
of
natural
mapping
between
the
specification
and
the
grammar.
So
can
we
can
obtain-
and
I
think,
api
meta
model
that
is
quite
understandable.
A
So
when
a
developer
wants
to
use
our
toolkit,
what
he
or
she
does
is
basically
to
do
the
specification
using
json
and
automatically.
We
obtain
an
api
model
that
is
conformant
to
our
snkvi
metamodel
and
finally,
we
have
implemented
some
model
to
text
transformation
to
generate
an
internal
dsl
that
assists
developers
to
create
or
to
implement
the
client
code.
A
A
What
we
do
is
to
define
the
x
text
grammar,
so
we
have
different
rules
in
this
case.
This
is
the
top
rule
that,
as
we
said,
matches
with
the
top
level
sections.
I
the
essence
api
section,
the
info
section,
the
server
section,
the
channel
section
and
component
section,
and
each
one
of
these
parts
of
the
rule
also
match
with
lower
rules.
For
example,
this
is
the
rule
to
define
the
information
of
the
api.
So
all
these
x
text
rules
of
the
grammar
basically
is
like
a
baker's
nav,
no
grammar.
A
This
is
automatically
transformed
to
a
meta
model,
and
this
metamodel,
as
I
said,
has
been
developed
in
such
a
way.
That
is
quite
high
level,
so
that
we
have
an
element
for
the
async
api
specification.
We
have
the
elements
for
the
or
the
the
classes
for
the
top
level
elements,
for
example
the
information,
the
server,
the
components,
the
channels
etc.
So,
if
we
go
inside
the
channel,
we
have
also
operations
parameters,
schemas,
etc.
A
So
this
is
from
the
in
the
part
that
is
done
at
the
design
time
and
basically,
whenever
the
developer
wants
to
generate
the
code,
what
he
does-
or
she
does
is
to
define
this
sync
api
definition.
This
is
the
same
definition.
I
have
just
shown
a
few
slides,
a
few
slide
slides
before
so
here
we
have
the
sync
api,
with
the
input,
server,
the
channels
and
the
schemas
and
messages.
A
A
Tasks
and
finally,
from
this
model,
we
can
generate
all
the
code.
For
example,
here,
there's
a
small
screenshot
of
the
project
explorer
of
with
the
code
generated
for
this
example.
Here
we
have,
for
example,
that
we
obtain
one
package
for
each
one
of
the
topics,
in
this
case
the
iot
box
id
monitor
topic.
A
Here
we
have
the
schemas
with
the
classes
that
give
support
to
create
the
payloads
of
our
metamodel
of
our
specification
and
so
on,
and,
as
I
said,
what
we
do
is
to
generate
an
internal
dsl
that
eases
the
definition
of
the
client
code
in
our
infrastructure.
So,
let's
see
an
example
of
this,
so,
as
I
said,
basically,
this
is
a
an
example
message
that
is
going
to
be
sent
from,
for
example,
from
line
a
to
the
message
broker
and
later
to
the
cloud
that
is
not
shown
here
for
simplicity
proposes.
A
A
So
we
are
going
to
create
a
main
method
in
a
publish
class
and
we
are
going
to
make
use
of
our
dsl
of
our
internal
dsl.
So,
first,
what
we
are
going
to
do
is
to
start
creating
a
new
payload.
That
is
this
whole
message.
So
what
we
do
is
to
call
the
line
info,
because
we
want
to
create
a
line
info
element.
We
obtain
a
builder
for
line
infos
and
we
said
first
we
specified
that
we
want
an
align
info
with
an
id
of
line.
A
A
we
see
that
here
we
already
have
one
method
that
refers
to
the
name
of
the
property
in
the
json
message.
So
we
have,
we
are
developing.
We
are
creating
the
messages
using
the
same
concepts
that
we
have
in
our
definition
of
the
api.
So
we
are
creating
the
builder.
We
are
setting
the
id
next,
we
say:
okay,
we
are
going
to
create
a
set
of
presses
and
we
are
going
to
add
it
to
add
them
to
the
list
of
presses
of
the
line
info.
A
So
we
call
the
method,
add
to
presses,
and
also
now
we
are
going
to
create
each
one
of
this
press
information
that
is
going
to
be
added
to
the
line
information.
So
now
that
we
have
the
new
builder,
we
set
the
id
of
the
press,
we
set
the
timestamp.
The
time
span
stamp
of
the
press
when
this
measure
is
being
done.
And
finally,
we
set
the
value
of
the
measure
of
the
measurement
in
this
press.
So
this
information
is
built
and
is
added
to
the
process
and
the
same
for
the
next
press.
A
So,
for
example,
here
we
call
the
method
add
to
process
and
again
we
create
a
new
builder.
We
set
all
the
information
with
id,
with
timestamp
with
value
etc.
So
now
we
already
have
in
this
payload
the
message
that
is
going
to
be
sent,
and
this
is
something
that
has
been
done
automatically
or
semi
automatically
semi-automatically
using
our
dsl
and
using
the
dsl.
Also.
We
are
sure
that,
for
example,
we
are
not
messing
up
with
the
data
types.
For
example,
we
know
that
the
values
are
is
a
float
float.
Value
is
a
real
value.
A
A
So
now
that
we
have
this
message
created,
we've
finally
build
it,
and
next,
as
I
we
saw,
for
example,
the
iot
box,
slash
slash,
monitor
it's
a
topic
with
a
parameter
inside,
so,
for
example,
this
part
in
the
middle
that
is
box
one.
It's
a
parameter.
So
now
here
we
are
creating
the
list
of
params
of
parameters,
and
we
are
saying
that
the
id
of
this
parameter
or
the
parameter
id
takes
the
value
box
one.
So
we
also
create
the
list
of
parameters.
A
A
A
Second,
to
obtain
better
code
quality
because
most
of
the
code,
at
least
for
the
dsl
part
for
the
internal
dsl,
the
creation
of
the
messages
and
the
sending
and
receiving
messages
is
automatically
generated
generated.
Also,
we
are
increasing
the
maintainability,
because,
if
the
specification
changes
and.
A
A
So
this
is
one
statement
that
was
saved
by
people
from
meterland,
so
basically
they
see
that
the
sync
api
toolkit
is
supports
most
of
the
phases
of
their
development
cycle
from
requirements
to
code
generation.
So
this
is
something
that
is
going
to
be
used
in
next
projects
there
in
nikerlan
to
develop
iot
applications
for
two
new
clients.