►
Description
In this latest Jakarta Tech Talk, John Clingan delivers an update regarding the latest edition of the Microprofile specification: MicroProfile 3.3.
///GET SOCIAL!
Subscribe: https://www.youtube.com/user/EclipseFdn
Follow us on Twitter: https://twitter.com/JakartaEE
Like us on Facebook: https://www.facebook.com/JakartaEE/
Join us on LinkedIn: https://www.linkedin.com/groups/13597
Tag us: #JakartaEE
Want more great Eclipse Community webinars? Become a member of our Jakarta Tech Talks Meetup: https://www.meetup.com/jakartatechtalks
A
Hey
everyone
welcome
to
another
Jakarta
Tech
Talk
I'm
today,
here
John,
Klingon
and
John
will
talk
to
us
about
the
micro
profile
in
the
news
in
the
micro
profile
world.
So
we
are
struggling
just
a
little
bit
with
who
is
going
to
share
the
screen
and
I
think
I'm
the
one
sharing
the
screen.
So
let
me
just
bring
out
the
presentation.
B
A
B
Well,
thanks:
everyone
for
joining
and
I
apologize
we're
a
little
bit
late
because
we
had
some
technical
difficulties.
Chrome
was
not
being
honorable
about
sharing
my
screen,
so
we
figured
it
out.
Let's
see
if
we
can
go
to
the
next
slide,
please,
oh!
Well.
Actually
it
looks
like
a
profile,
3-3
and
update
right.
That's
pretty
clear
from
the
session
title
so
looks.
Let's
move
on
to
the
next
one
who
the
heck
am
I.
I
am
a
macro
profile.
B
You
know
co-founder
because
involved
a
one
help
kind
of
create
the
micro
profile
project
in
the
early
days
and
one
with
a
bunch
of
other
folks,
so
I've
been
a
committer
mainly
around
the
releases.
So
you
can
see
the
releases
that
I've
kind
of
been
a
co-lead
of
more
recently
well
in
the
past,
with
Kevin
Sutter
and
more
recently,
with
Kevin
and
Edwin
Dirk's.
B
Pork
is
miscellaneous,
other
things,
I
used
to
be
a
product
manager
of
Java
EE
and
in
GlassFish
at
Sun,
Microsystems
and
Oracle,
and
let's
see
I've
been
using
Java
EE
since
before
j2ee,
so
I
was
playing
around
with
individual
technologies
like
surplus
before
Java
EE
was
even
formed,
but
really
didn't
start
using
Java,
EE,
I
think
until
probably
warmed
up
2
or
1.3.
The
j2ee
days
and
I
also
do
a
little
bit
of
instruction
and
training
at
UC,
Irvine
extension
and
all
Riley
live
trainings.
B
All
right,
so
what
is
Eclipse
Micah
profile
at
its
simplest
description
and
remove
this
slide
over
here
so
I'm,
looking
more
toward
the
camera,
I've
got
multiple
monitors
set
up
here.
It's
an
open
source
community
that
creates
enterprise,
Java
micro
services
specifications.
So
most
people
tend
to
think
of
specifications
and
standards,
organizations
as
being
very
processed
driven-
and
you
know
only
a
certain
few-
can
kind
of
participate
historically
right,
the
experts
per
se,
but
with
Micah
profile
we
really
are
an
open
source
community.
B
B
B
All
right
so
the
current
micro
profile,
implementations
and
by
the
way,
these
last
three
slides
here
and
some
of
these
other
slides,
were
created
by
the
marketing
the
market
profile
marketing
team.
So
when
you
work
with
in
the
community,
you
don't
have
to
just
create
specifications,
there's
other
ways
to
participate.
B
So
we
have
folks
folks
that
are
very
active
in
marketing
and
one
of
the
things
they
do,
for
example,
is
produce,
slides
like
this,
so
you
can
see
a
list
here
of
the
implementations
of
Micra
profile
and
one
that's
not
here
yet,
but
has
started
to
support
micro
profile
specifications
is
peretta.
So
if
you
look
at
front
of
that
cloud,
that's
a
new
project
for
I,
think
creating
micro
services
and
they
support
I,
think
magnet
profile,
health
and
market
profile,
GWT
and
I.
B
Think
they're
gonna
keep
growing
support
for
micro
profile
specs,
so
a
little
bit
of
shout
out
to
the
up-and-coming
members
of
the
micro
profile
community
from
an
implementation
perspective.
So
what
do
we
have
here?
Four,
five:
six:
seven,
eight,
nine
and
nine
current
implementations,
and
if
you
you
know
tack
on,
for
example,
piranha.
That's
that's
up
to
ten.
So
next
slide.
B
So
if
we
look
at
you
know
what
exactly
is
micah
profile
from
a
specification
perspective,
there
is
a
set
of
four
specification.
So
if
you
look
at
the
box,
it
says
micro
profile
3
through
P
and
the
lower
left-hand
kind
of
row,
you'll
see
specifications
that
have
been
developed
in
the
Java
EE
community
right
so
CDI,
the
Jason
specs
and
Jack's
arrest,
and
that
kind
of
defines
a
core
programming
model
for
micro
profile,
meaning
that
the
specifications
in
terms
of
dependencies
only
rely
on
or
specifications.
B
If
you
look
at
all
the
other
boxes,
those
are
boxes
that
have
been
developed
inherently
within
the
Micra
profile
community.
So
if
you
count
them
up
here,
we
got
eight
in
the
micro
profile,
3-3
box
and
in
the
right-hand
side
you
got
four
more
so
so
far.
We've
developed
twelve
homegrown
specifications
and
there's
another
one
in
the
works
called
long-running
actions
and
I'm
not
really
gonna
cover
that
one.
B
B
So
you
see,
vest
client,
config,
hollerin,
s--,
metrics
and
health
all
had
some
kind
of
update
to
it
and
if
you
look
at
new
specifications,
I
think
this
is
the
first
time
in
kind
of
a
market
profile
tech
like
this.
We
have
graph
QL,
I'm
gonna
talk
about
graph
QL
a
little
bit
later
so
and
I'm
also
going
to
talk
a
little
bit
about
what
does
it
mean
to
be
part
of
the
platform
which
is
the
Box?
B
B
And
I
should
mention
that
I
did
put
a
link
to
this
presentation
in
the
chat
so
feel
free
to
you
know
to
take
a
look,
make
copies
of
the
presentation,
steel,
slides
and
all
that
ok.
So
what
you'll
find
is
when
you
look
at
the
change
log
for
specifications
well,
first
of
all,
reading
specifications
is
for
the
typical
Java
developer
is
kind
of
boring.
It
just
talks
about.
You
know
the
very
details
of
specs
the
tcks
get
covered
and
how
to
do
the
testing
to
ensure
compatibility.
So
what
you'll
find
at
the
changelog
is
features.
B
Descriptions
you'll,
see
clarifications
of
the
spec
modifications
to
the
TCK.
If
someone
says
hey,
there's
a
bug
in
the
t,
ck
so
you'll
see
that
not
necessarily
all
the
updates
in
a
micro
profile.
Spec
are
something
that
a
developer
will
consume
on
a
day
to
day
basis
right,
but
there
are
functional
updates
and
so
I've
kind
of
pulled
some
of
these
out
of
some
of
the
specs.
To
give
you
an
idea
about
what
some
of
the
functional
updates
are
and
for
this
release
and
let's
go
on
to
the
next
slide,
please
so.
B
B
One
of
the
things
I've
done
is
I've
kind
of
oh
yeah
up
one
on
one
more
slide
7.
So
what
I've
done
is
I've
kind
of
color
color
coded
in
red.
Some
of
these
things
that
are
more,
you
know,
developer
functionality
that
you
might
use
and
you'll
see
here.
It's
insurer,
CDI
and
optionally
jax-rs
injection
into
client,
headers
factory.
You
might
be
thinking
to
yourself!
Well
what
you
know
what
the
heck
is
that
next
slide,
please
so
within
microphone
file
restclient
if
you're
not
familiar
with
the
rest
client.
B
Basically,
it's
a
type
safe
way
of
making
restful
calls
to
back-end
restful
services.
So,
if
you
think
about,
if
you
write
a
jax-rs
resource,
if
you
strip
out
all
the
implementation
code,
that
basically
turns
a
jax-rs
resource
into
a
into
an
interface
as
long
as
you
also
changed
the
class
keyword
to
interface.
So
in
a
lot
of
ways,
that's
what
the
jacket!
The
rest
client
is
you're,
defining
an
interface
to
call
backend
restful
services,
and
so
one
of
the
things
that
you
can
do
with
the
rest
of
client
is
propagate
headers.
B
So,
as
you
go
from
your
client
to
a
service
that
you
may
have
written
in
the
service
that
you've
written,
you
may
have
to
call
other
back-end
jax-rs
resources,
there's
the
potential
on
a
desire
to
propagate
headers.
So
you
can
think
about
propagating
a
bearer
token
that
you
know
if
you've
authenticated
with
some
authentication
service.
You
might
have
this
token
that
you
want
to
pass
between
services.
You
want
to
propagate
it.
B
So
the
way
you
do
that
in
in
my
core
profile,
as
you
add
the
at
register,
client
headers,
annotation
to
a
rest,
client
and
that
basically
provides
by
a
default
implementation
that
propagates
the
headers
right.
And
if
you
don't
like
the
default
implementation,
you
can
write
your
own
and
you'll,
see
the
client
headers
Factory
below,
and
that's
just
a
very
simple
example
of
where
I've
kind
of
defined
a
very
simple
outline
of
a
client
header,
Factory
right.
You
can
implement
your
own
and
define
your
own
strategy
about
how
you
want
to
propagate
a
header.
B
What
headers
you
might
want
to
propagate,
maybe
manipulate
a
header
in
between
the
browser
that
talks
to
your
service
and
the
service
in
the
backend,
and
so
basically
now,
if
you
annotate
that,
with
an
application,
scope,
it'll
be
automatically
discovered,
otherwise
you'd
have
to
provide
it
as
a
parameter
to
the
annotation
register.
Client
headers.
So
this
is
just
an
example
with
mica
profile.
What
you'll
find
is
we
don't
tend
to
have
these
big
bang
releases
of
specs?
What
we
do
have
is
a
lot
of
incremental
releases
that
add
functionality
along
the
way.
B
B
They'll
talk
to
the
the
folks
that
implements
Myakka
profile
and
then
they'll.
Take
that
customer
or
use
your
feedback
and
provide
these
this
feedback
to
the
Micra
profile
community,
and
then
these
get
you
know
eventually
pushed
in
to
mica
profile,
spec
updates.
So
this
is
not
necessarily
a
feature
that
you
would
use
all
the
time
with
in
Mecca
profile,
it's
a
little
bit
one
of
the
more
infrequently
used
one,
but
when
you
need
it,
you
need
it
and
you
want
to
be
able
to
customize
it
right.
So
that's
kind
of
what
this
facilitates
next
slide.
B
B
So,
with,
let's
see,
risk
clients
this
and
I
apologize.
This
is
a
bug.
Breast
client
here
this
should
show
this
should
be
the
configuration
microphone
profile,
config,
so
I
apologize
for
that.
That's
not!
This
I'll
fix
the
slide
title
after
after
the
talk,
but
basically
again,
you'll
see.
There's
you
know
lots
of
kind
of
esoteric
updates
around
API
SPI
and
in
TC,
keys
and
stuff.
But
one
of
the
things
you'll
see
is
that
again
in
bold
red
you'll
see
that
we've
added
additional
converters
so
with
market
profile
config
it
lets
you
externalize
your
configuration.
B
So
that
means
you
know
in
your
application.
You
can
inject
a
property
value
and
their
property
value
could
be
in
an
environmental
variable,
a
property
file
on
the
command
line
and
a
database
write
what
it
were
ever
and
it's
assumed
that
those
are
basically
ask
you,
sorry,
a
string
right,
environmental
variable,
you
know
property
files,
and
so
what
you
want
to
be
able
to
do
is
convert
those
trees
into
some
kind
of
native
made
of
data
type
within
micromo
file.
A
new
java
app.
B
B
There
are
a
couple
of
missing
ones
and
you
can
see
those
here,
bytes,
shorts
and
characters,
so
you
could
have
I
already
have
done
the
numeric
type
strings,
boolean's,
even
lists
and
arrays,
but
we've
kind
of
closed
the
loop,
not
where
you
got
basic
support
for
all
the
base
types
within
Java
right
and
you
can
see
a
very
simple
injection
of
a
simple
property,
a
character
into
an
instance
variable
within
your
class.
So
again,
another
incremental
style
update
next
slide.
Please.
B
Okay,
fault,
tolerance,
so
within
micro
profile
you
have
the
ability
to
react
to
I.
Don't
wanna
say
that
this
troublesome
situations
right,
if
you
have
some
kind
of
issue
within
your
application,
then
there's
ways
to
kind
of
deal
with
these
issues
using
fault
tolerance,
annotation.
So
what
does
that
mean?
We
have
timers.
So
if
a
method
is
taking
too
long
to
invoke
a
back-end,
you
can
basically
throw
a
timeout
exception
right.
It
took
too
long,
there's
a
fallback.
So
if
something
takes
too
long,
maybe
you
want
to
provide
alternative
or
fallback
logic.
B
So,
there's
a
fallback
annotation.
We
have
circuit
breakers,
bulkheads
asynchronous
annotation
for
running
code
in
a
separate
thread,
so
there's
lots
of
strategies
for
dealing
with
potential
failures
in
your
application,
and
so
what
I've
done
here
is
I
called
out
on
this
slide
again
in
red,
a
couple
of
more
functional,
developer,
functional
features
that
were
updated
in
fault
tolerance
to
one.
So
what
you'll
find
is
with
fault
tolerance.
A
lot
of
the
functionality
is
influenced
by
exceptions
right
so
yeah,
it's
10
cycles.
B
Thank
you
and
what
that
means
is
that
when
something
goes
wrong,
you
might
want
to
throw
an
exception,
or
if
something
goes
wrong,
then
one
of
these
annotations
might
throw
an
exception.
So,
for
example,
if
a
timer
sorry,
if
you
have
a
timeout
and
your
code
takes
too
long,
it'll
throw
a
timeout
exception
right.
So
what
you'll
want
with
fault
tolerance?
Is
the
ability
to
have
some
level
of
flexibility
and
control
over
how
to
deal
with
exceptions?
B
So
if
you
go
on
to
the
next
slide,
please
this
is
an
example
with
you
know
the
fall
back
annotation.
Basically,
if
you,
through
any
kind
of
exception,
it
would
automatically
kind
of
it.
If
it
wasn't
caught
with
the
error
within
your
code,
it
would
call
the
fall
back,
but
what
you
might
want
to
have
is
some
additional
control
over
your
fall
back.
So
in
this
case,
what
we're
saying
is,
first
of
all.
B
Well
what
I'll
do
is
talk
a
little
bit
about
this
code
in
my
unstable
method,
so
one
of
the
things
it
does
is
it
sleeps
for
a
random
amount
of
time
between
zero
and
two
seconds
right.
The
second
thing
it
will
do
is,
if
some
you
know
some
business
logic.
If
some
error
condition
occurs,
this
will
throw
a
custom
exception
right.
So
what
what
this
means
is
that
there's
some
cases
here
where
some
exceptions
are
gonna
be
through
and
you
want
to
have
some
control.
B
So
if
you
look
at
the
timeout
exception,
this
is
a
fault
tolerance,
annotation
in
micro
profile
by
default
at
timeout
sleeps
for
one
second
or
a
thousand
milliseconds.
So
if
you
look
at
that
code,
half
the
time
because
of
the
the
random
sleep
half
the
time,
that's
gonna
fail
and
half
the
time.
That's
gonna
succeed.
So
what
we
want
to
do
is
we
want
to
make
sure
that,
for
that
exception
we
call
the
callback
method
right.
B
But
if
we,
if
I
run
into
some
business
logic
exception,
maybe
I
don't
want
to
call
the
fall
back,
maybe
I
wanna
that
exception
to
propagate
up
to
you,
know
somewhere
else
in
my
stack
to
some
other
method.
So
what
we're
saying
in
this
you
know
what's
a
new
skip
on
parameter?
What
we're
doing
is
we're
saying
you
know
skip
on
the
my
customer
exception.
Next
class,
don't
don't
call
a
fall
back
on
my
custom
exception,
only
call
the
fall
back
on
the
time.
B
Art
exception
right,
so
it
gives
you
some
flexibility
and
there's
a
again
additional
flexibility
in
the
circuit,
breaker
annotation
as
well.
So
that's
very
useful
functionality
for
day-to-day
fault,
tolerant
style,
marker
services,
coding
next
slide,
and
it
said
restclient
boy
I
really
have
to
fix
my
slightly
titles
I
apologize
that
should
have
been
a
fault-tolerance
example.
All
right.
B
Here's
metrics
to
three
metrics
to
three
again:
lots
of
TCK
enhancements
clarifications
around
the
spec
and
I
called
out
a
couple
of
functional
API
changes
that
might
be
useful
for
a
developer
on
kind
of
a
day
to
day
basis.
One
is
the
introduction
of
a
simple
timer,
so
micro
profile,
metrics
already
has
an
add
timed
annotation.
But
it's
pretty
verbose
and
you'll
see
an
example
of
that,
and
sometimes
you
just
want
to
see
how
long
did
a
method
take.
B
You
know
give
me
a
time
and
not
a
lot
of
verbose
output
and
so
there's
a
new
annotation
at
simply
timed
that
oldest
time,
for
example,
a
method
call
or
constructor
or
you
can
do
it
at
the
class
level,
a
little
time
every
method
and
then
there's
another
added
to
my
profile.
Metrics
is
process
CPU
time
so,
with
micro
profile,
metrics,
there's
three
classes
of
metrics
one
is
base.
That
means
every
market
profile.
Implementation
has
to
find
a
base
set
of
metrics.
Typically
it's
around
class.
B
You
know:
class
loading,
metrics
memory,
utilization
like
heap
size
and
heap
utilization
in
process
or
CPU
utilization
on
the
system.
So
there's
a
new
basic
metric
and
it
says
well
for
this
process.
That's
executing!
You
know
your
code.
How
much
CPU
time
is
this
process
using,
and
so
what
you
can
do,
then,
is
take
that
information
and
there's
also
a
CPU
count
metric.
That
tells
you
how
many
CPUs
are
in
the
system.
B
You
could
push
both
of
those
that
sum
back
and
metrics
collection
system
like
prometheus
and
then
Prometheus
can
maybe
do
some
calculation
on
that
and
say
well.
What
percentage
of
the
CPU
is
your
process
user
right,
so
it
takes
the
calculation
outside
of
your
code
and
moves
it
off
to
some
kind
of
back-end
system.
B
So,
let's,
let's
take
a
look
at
the
next
slide.
Please,
and
so
this
is
that
verbose
up
when
I
was
telling
you
about
right
if
I
add
at
timed
to
a
method
in
this
case
is
called
the
students.
You
can
see
that
it
gives
you
an
awful
lot
of
data
right.
If
all
you
want
to
find
out
is
how
long
did
that
method?
Take
right.
You
look
at
this.
It's
like
you
know,
good
luck
right.
B
So
what
what
simply
timed
will
do
is
is
just
take
a
look
at
one
of
these
one
of
these
lines
or
I,
don't
say:
okay.
This
is
how
long
this
method
took
right,
so
my
Haven
actually
run
the
code
is
to
at
the
output,
looks
like
yet
and
because
the
implementations
I
use
haven't
implemented
this
quite
yet
keep
in
mind.
My
current
profile
is
only
about
a
week.
Three
three
is
only
about
a
week
old
with
a
week
or
two
weeks
18,
so
yeah
18
is
when
it
was
released.
B
So,
but
you
could
imagine
this
being
a
very
short
output,
just
maybe
one
line,
so
that
was
added
basically
to
do
two
things
again.
Take
the
calculation
all
this
calculation
out
of
your
micro-service,
and
if
you
don't
need
all
of
this
detailed
information
and
provide
for
just
one
line
of
output,
that
makes
it
a
lot
simple,
as
I,
simpler,
more
targeted
to
the
use
case
that
you're
trying
to
do,
which
is
how
long
does
it
have
to
take?
Okay
next
slide,
please.
B
Health
to
two
so
health
to
two
went
through
an
update,
so
you
can
see
there's
a
couple
of
again
examples
around
whether
it's
a
spec
update
or
a
TCK
modification.
These
are
important
things
for
for
implementations
that
want
to
implement
micro
profile,
specs
and
but
not
again,
not
necessarily
for
you.
The
end
developer,
one
of
the
things
and
I
apologize
I
didn't
actually
get
them
an
example
of
for
this
one,
but
make
health
check
response
a
concrete
class.
What
this
means
is
health
check
response.
B
Well,
so,
first
of
all
health,
my
profile
health-
it
is
an
API
that
lets
you
expose
the
health
of
your
service
to
the
underlying
platform,
so
think
docker
think
kubernetes.
It
can
expose
whether
your
services
alive
right
is
it.
Is
it
up
and
running
without
any
kind
of
issues
and
there's
also
a
readiness
health
definition
is
like?
Is
my
service
ready
to
accept
traffic?
B
There's
nothing
wrong
with
it,
but
it's
not
ready
to
serve
traffic
sort
example
is
maybe
it's
gonna
read
some
data
out
of
a
database
and
cache
it
within
the
service
right,
and
it
takes
time
to
do
that
during
that
time
you
don't
want
to
receive
traffic,
so
you
say:
I'm
not
ready
yet
right
and
once
you've
maybe
primed
the
cache.
Then
you
say:
ok,
I'm
ready
and
then
the
underlying
infrastructure
will
direct
traffic
your
way.
B
So
the
way
you
reply
to
the
underlying
infrastructure
is
using
the
Health
Check
response
object
and
that's
where
you
basically
define
the
state.
Yes,
I'm,
ready
or
no
I'm,
not
ready
or
there's
an
issue.
You
know
status
is
good
or
bad.
Here's
some
additional
data
that
you
might
want
to
provide
as
well.
Think
of
this
is
just
like
a
hash
map
and.
B
It's
an
abstract
class,
which
means
you
can't
use
it
and
all
in
all
the
cases,
and
when
I
looked
at
the
issue,
it
basically
says
you
want
to
use
it
inside
at
risk.
The
Micra
profile,
rest
client
and
you
can't
because
it's
an
abstract
class,
so
basically
they
make
it
a
concrete
class,
and
now
you
can
use
a
health
check
response
in
your
micro
profile.
Rest
client
interface.
So
this
is
one
again
that
you
know
you
might
want
to
to
utilize.
B
The
exact
exact
use
case
where
this
popped
up
was
what,
if
I
don't
want
to
rely
on
kubernetes
or
docker,
to
receive
my
health.
What,
if
I
want
to
run
a
custom,
Java
client
that
pings
my
service
and
gets
the
status
out
that
the
health
of
the
service
out
I'm
using
a
Java
client?
You
want
to
use
the
market
profile
breast
client
to
do
that.
Well,
this
actually
allows
you
to
do
that.
I,
apologize,
I
didn't
have
time
to
actually
get
a
code
sample
in
there.
B
So
my
description
may
not
do
it
justice
next
slide.
Please.
B
So
one
of
the
things
that
I
think
people
don't
think
about
from
us
as
a
user,
but
becomes
very
apparent.
You
know
when
you're
working
on
the
specs
is
the
amount
of
integration
that's
been
and
the
thought
that's
put
into
how
specs
can
work
together
right.
So,
while
you
have
these
specifications
that
are
completely
independent,
if
they're
used
together,
then
some
function
it
some
additional
functionality
comes
into
play
all
right.
B
So
the
one
example
is
market
profile
config,
so
I
didn't
check
every
single
micro
profile
spec,
but
virtually
all
of
them,
if
not
all
of
them.
Utilize
market
profile,
config
to
configure
aspects
of
functionality
that
are
provided
by
the
specification
right
so
with,
for
example
with
is
it
fault,
tolerance,
I,
think,
I,
think
it's
fault,
tolerance
where
you
can
override?
Yes,
fault
tolerance!
You
can
override
every
annotation.
B
So
if
you
think
about
app
timed
right
where,
by
default,
it's
one
second
I
can
go
into
I
can
define
a
property
that
overrides
that
one
second
to
ten
seconds
right,
for
instance,
I
can
do
that
at
the
property
level
and
I
can
override
pretty
much
every
parameter
of
every
fault:
tolerance,
annotation,
using
micro
profile
config.
So
you
know,
a
lot
of
thought
has
been
put
into
how
these
specifications
can
work
together
when
they're
you
know
available
inside
the
underlying
platform.
Another
example
client
integrates
with
fault,
tolerance
and
jax-rs.
So
an
example.
B
There
is
the
rest
client,
actually,
the
the
rest
client
basically
says
that
we're
support
card.
So
what
this
affects
it?
It
basically
says
that,
because
fault,
tolerance,
annotations
basically
use
the
interceptor
pattern
that
the
fault,
tolerance,
annotation
interceptors,
have
to
work
with
the
rest
client
right.
B
So
again,
thought
has
been
put
into
how
these
things
have
to
work
together.
Fault
tolerance,
the
fault,
tolerance
specification.
If
you
have
metrics
and
the
fault
tolerance
implementations
with
your
underlying
platform,
then
fault
tolerance
will
automatically
register
metrics
for
you.
So
I
mentioned
that
there's
base
metrics
that
are
provided
by
the
platform
there's
also
vendor
metrics
that
are
specific
to
an
implementation,
or
you
can
write
your
own
metrics.
Those
are
called
application
metrics.
B
How
much
time
is
spent
in
the
open
state,
the
half-open
state
or
the
closed
state,
and
then
you
can
basically
create
a
graph
on
a
dashboard
and
look
at
your
circuit
breakers
right.
If
you
think
about
the
old,
what
was
it
the
hit
rate
hystrix
dashboard?
You
can
recreate
that
using
profile
and
it's
all
had
kind
of
the
metrics
registration
all
happens
out
of
the
box,
and
it's
configurable.
You
can
turn
it
on
or
you
can
check
it
off.
B
Another
example
of
spec
integration,
reactive
streams
operators
operate
on
the
reactive
messaging
pipeline,
so
I
haven't
talked
about
the
reactive
specs
here
because
there
weren't
any
updates
for
micro
profile
3-3.
But
you
you
can
do
active
development
with
micro
profile
using
reactive
messaging,
which
basically
streams
data
between
systems
and
think
about
being
able
to
like
you
might
do
within
a
java
application.
You
can
create
a
pipeline
with
just
Java.
B
Java
streams
and
you
can
use
operators
on
it
like
you,
know,
flat
map
and
collect,
and
that
kind
of
those
kind
of
operators
and
then
with
micro
profile,
reactive
messaging,
that
all
happens
with
back
pressure
in
place
because
you're
doing
streams
between
systems.
So
it's
pretty
cool
stuff
and
they
thought
again
ahead
of
time
about
how
these
app
specifications
work
together
and
one
one
last
one.
It's
a
little
bit
esoteric
but
open.
Api
is
another
market
profile
specification
where
you
can
annotate
your
restful
api
s
to
document
them,
and
then
external
systems
can
query
them.
B
There's
integration
with
the
rest
client
that
basically
says
well,
if
you're
using
the
rest
client,
don't
register
that
with
open
api
right,
because
you're
really
referring
to
an
external
service,
not
something
that's
within
your
application.
Otherwise
I
think
in
the
past
that
would
have
automatically
registered
the
rest
client
annotations,
which
really
aren't
the
part
of
your
app.
It's
part
of
some
other
app
that
you're
calling
so
next
slide.
Please
so.
B
This
is
kind
of
a
one
in
all-in-one
slide
where
you
can
take
a
look
at
and
again
the
link
to
this
slide
deck
is
in
is
in
the
chat
and
you
can
click
on
any
one
of
these.
Where
you
could
look
at
the
project
page
for
the
spec,
you
could
look
at
the
actual
spec
PDF
or
HTML
Docs,
there's
Java
Doc's
that
are
available.
The
TCK
one
thing:
I
forgot
to
link
to
there's
a
book
that
a
locker,
a
bunch
of
micro,
profilers,
wrote,
called
hands-on
hands-on
with
Eclipse
micro
profile.
B
B
Okay
micro
profile
graph
QL
is
a
new
specification,
and
so
basically,
if
you
think
about
how
you
typically
develop
restful
applications,
you
you
make
a
call
to
a
restful
endpoint,
you
get
data
back
and
maybe
it's
a
list
of
you
know
a
list
of
states
and
then
you
want
to
you
know,
for
each
state
figure
out
what
the
top
five
cities
are.
Well,
we'll
look
for
each
state,
you
might
have
to
make
call
another
restful
service
endpoint
and
ask
for
you
know
the
top
cities.
B
So
what
you
have
is
this
a
lot
of
calls
back
and
forth
between
a
micro
service
and
a
back-end
micro
service,
a
front-end
becasue?
You
want
to
service
on
the
backend,
and
so
that's
a
lot
of
round-tripping
increased
latency,
more
load
on
on
the
backend
server,
potentially
or
graph
uql
does.
Is
it
basically
lets
you
define
and
model
your
restful
api
so
that
you
could
actually
conduct
queries?
So
it's
not
quite
pure
sequel
right
where
you're
doing
these
you
know
very
complicated
queries.
B
But
what
you
can
do
is
model
your
api
and
say
you
know
what
I'm
gonna
call
this
back-end
I'm
gonna
write
a
query
that
says,
give
me
the
top
five
cities
in
all
states
right
or
all
provinces
or,
however,
that's
defined
within
your
geography,
and
you
make
one
call
and
ever
turns
you.
It
turns
all
that
data
with
just
the
field
you
want
in
that
call.
So
that's!
B
B
The
the
graph
QL
schema
kind
of
that
that
API
model
using
annotation,
so
you
could
annotate
your
code
and
that
model
is
generated
and
it's
the
runtime
engine
that
has
to
be
of
runtime
and
engine
underneath
it
actually
executes
the
queries
right.
So
that's
what
the
the
graph
QL
micro
profile
graph
QL
spec
does,
and
it's
also
a
standalone
specification.
I'm
gonna
again
explain
that
here
in
a
second.
So
next
slide,
please.
B
B
Thank
you,
okay,
so
version
one
that
o
of
the
graph
QL
spec
was
released
today,
I
provided
there's
a
link.
It's
just
gonna
point
to
the
github
where
that
release
kind
of
shows,
hey
it's
available,
so
I
hope,
I,
didn't
preempt
the
graph
QL
spec
team
by
stealing
any
thunder,
but
I
thought
this
is
a
good
opportunity.
It
was
released
today
so
with
market
profile.
There
isn't
really
the
concept
of
a
reference.
B
Implementation
like
there
was
in
Java
EE,
but
you
do
have
to
have
an
open
source
implementation
in
order
to
release
a
spec,
and
so
the
graph
QL
spec
is
actually
implemented
in
the
project.
Called
small
ride
and
small
write
is
consumed
by
other
runtimes,
so
I
know
Quercus
and
in
thorn
tale
plot
of
thorn.
A
lot
of
small
R,
I,
openly
I
think
pulls
a
couple
of
micro
profile,
implementations
out
of
a
small
riot
project
and
kind
of
the
implementation
behind
this
initial
release
was
defined
in
the
microphone.
Sorry
in
the
a
small
rock
community.
B
B
There
we
go
breaking
news,
yeah
I
was
looking
for
a
nice,
you
know
confetti
or
balloon
type
thing,
but
they
were
all
copyrighted
and
I'm
a
I'm,
a
horrible
artist,
so
I
decided
to
skip
it
so
a
little
bit
about
how
micah
profile
releases
its
specs.
This
provides
a
little
bit
of
history
in
and
some
visualization
of
how
we've
released
our
specs
over
time
right.
So
the
first
Beck
was
in
late
I
think
was
like
in
September
of
2016
Java
1
of
2016.
It
was
as
a
project.
B
It
was
founded
in
June
of
2016
and
you'll,
see
that
initially
we
kind
of
had
this
inconsistent
cadence.
Part
of
that
was
because
we
were
moving
micro
profile
into
the
Eclipse
Foundation,
and
that
took
a
little
bit
of
time
and
we
were
learning
new
processes
as
a
new
project.
I
mean
part
of
it
was
because
we
hadn't
really
defined
a
formalized
lifecycle
early
on
so
next
slide.
Please
so.
B
You
know
we'd
be
gotten
this
specific
cadence,
so
we
kind
of
talked
about
it
in
the
micro
profile
community
in
our
live
hangout
again,
there's
I'm
for
referencing
I'm
a
little
bit,
but
we
kind
of
discussed.
How
do
we
want
to
go
about
delivering
Micah
profile?
In
some
predictable
manners,
we
decided
to
go
on
a
train
model.
We
released
three
times
per
year,
February
June
and
October,
and
if
you're
not
ready
for
a
particular,
for
example,
for
the
February
release.
Well,
then
you'll
have
to
wait
for
the
June
release,
so
this
train
has
been
executing.
B
You
know
on
time,
since
mid-january
start
mid-june,
mid
2018
and
until
you
know
so
far,
we've
got
until
23.3
that
we
released
February,
18th
and
next
slide.
Please
what
you'll
see
is
we've
defined
a
formality
around
like
a
profile
saying
major
releases
are
reserved
for
junior
leases,
so
2.0
happened
in
June
of
2018
3.0
and
June
of
2019.
4.0
is
scheduled
for
June
of
this
year,
which
a
major
release
in
micro
profile
kind
of
like
the
semantic
versioning
in
general,
means
that
it's
an
opportunity
to
break
compatibility
right.
B
This
is
just
just
true
within
a
you
know,
any
project,
it's
it's
a
time
when
you
think
you
know
what
we
we
made
a
decision.
Maybe
it
was
the
wrong
decision,
maybe
want
to
correct
it
or
it's
around.
You
know
it's
a
feature
that
nobody
really
used.
So,
let's
get
it
out
of
the
platform
or
it's
obsolete
right.
It's
it's
no
longer
appropriate
in
the
current
you
know,
programming,
programming,
paradigm
or
or
whatever
right
so
just
update
as
a
concept.
B
B
So
we
split
the
account
at
the
annotation
and
added
a
concurrent
gauge
annotation.
The
kind
of
deal
was
with
this
duality:
I,
don't
wanna
get
into
too
much
detail,
but
what
it
means
is
that
it
did
kind
of
break
functionality
and
we
kind
of
we're.
Okay,
with
that,
my
control
file
pretty
much
so
before.
I
continue
on
to
the
next
slide,
to
explain
that
more
what
you'll
see
is.
We
do
have
four
own
planning
and
in
the
June
release
I'm
setting
the
June
in
the
October
release
of
this
calendar
year.
It's
going
to
be
interesting.
B
B
So
micro
profile
for
row,
as
you
know,
Java
EE
has
moved
into
the
check
harbor
community,
so
it
is
now
Jakarta
EE
in
terms
of
continuing
its
evolution,
and
so
micro
profile
rely
on
the
list
of
specs.
You
can
kind
of
see
here
and
while
the
with
Jakarta
ee8,
the
programming
API
hasn't
changed.
So
your
applications
don't
necessarily
break,
but
the
names
of
the
API
jars
do
change.
So
that
means
your
palm.
That
XML
may
have
to
be
updated
right
and
our
TC
Cades,
for
example,
had
to
be
updated.
B
Well
will
have
to
be
updated
to
utilize
the
right,
jakarta,
api
jars.
So
for
us,
that's
a
breaking
change
for
your
code.
It's
not
necessarily
a
breaking
change.
It
just
depends
on
on
your
market
profile,
runtime
and
in
how
you
define
your
palm
the
xml
worst
case.
It
should
just
be
a
palm
that
a
xml
update,
so
there's
no
API
changes.
There's
no
Jakarta
namespace
changes
right
because
in
the
Jakarta
community
we
know
that
we
have
to
change
the
Java
x-games
base
to
the
Jakarta
namespace
in
order
to
evolve
specs
right.
B
That
is
not
what's
happening
in
micro
profile
for
Dino,
yet
so,
but
that
is
going
to
have
to
happen
relatively
I
think
soon
after
Jakarta
makes
that
switch
in
Jakarta
EE
mine.
So
that's
why
I
said
at
some
point.
We
may
have
to
have
two
releases
in
a
year
unless
you
want
to
wait
until
next
June
our
next
plan
breaking
release
after
4.0,
so
I'm
talking
june
of
2021
in
order
to
update
our
market
profile
specs,
and
so
we
mean
that
want
to
wait
that
long
right,
okay,
so
breaking
changes.
B
You
can
see
the
list
of
specs
here
that
have
breaking
changes
or
are
planning
breaking
changes,
and
so
this
isn't
just
the
API
jar
dependency
breaking
changes.
These
are
the
specs
that
our
planning
may
be
functional
changes,
kind
of
like
we're
described
for
the
other
specs.
Some
of
these
might
be
functionality
that
your
code
might
rely
on,
or
it
might
be
again
just
spec
spec
changes,
spec
clarifications,
TCK,
updates
and
stuff
like
that.
B
So
it's
a
little
bit
early,
so
I
didn't
want
to
point
anything
specific
out,
but
those
links
to
point
to
the
github
milestone
where
we
track.
What's
going
to
be
in
these
releases,
so
in
my
car
profile
to
track
what's
happening
in
a
spec
in
the
next
release,
we
have
formalized
we
formalized
as
a
process
that
you
should
define
a
milestone
and
what
github
issues
will
be
used
to
track.
What's
going
to
happen
in
a
in
a
miles
in
a
milestone
as
it
targets
the
next.
B
The
next
micro
profile
spec
release
right,
so
you'll
see
a
list
of
all
the
planned
changes
in
these
specs.
Some
are
breaking
potential.
Some
are
going
to
be
breaking
in
this
case.
Some
not-
and
this
is
early,
so
it's
gonna
be
a
highly
volatile.
So
some
things
you
might
see
new
issues
pop
in
some
issues,
move
out
so
just
a
little
bit
of
a
heads
up
on
that
and
there's
a
discussion
to
remove
open
tracing
from
the
platform
spec
from
mica
profile
at
the
platform
level.
B
B
The
open,
open
tracing
upstream
as
a
project
is
merging
with
open
census
in
a
way,
so
there's
two
competing
specifications
for
how
to
do
distributed.
Tracing
and
they're
merging
into
a
single
spec
called
open
telemetry.
So
what
we
want
to
do
is
write
an
open,
telemetry
spec.
We
decided
to
not
try
and
update
open
tracing
to
be
open
telemetry
in
terms
of
the
micro
profile
spec,
we
decided
to
create
a
separate
open,
telemetry
spec,
so
we
may
not
want
to
have
to
wait
until
the
June
of
2021
to
incorporate
that.
B
So
that's
why
we
decided
well
or
deciding
this
is
it's
a
discussion
pulling
open
tracing
out
of
the
core
spec
vendors
will
still
implement
it
until
there's
an
open,
telemetry,
spec
and
implementation,
and
then
that
could
be
added
into
the
core
platform.
So
it's
a
little
bit
of
process
as
to
why
that
might
be
pulled
out.
Don't
read
anything
like
negative
into
that?
It's
actually
all
goodness.
B
B
That
discussion
about
open,
telemetry
kind
of
falls
into
a
list
of
things
that
we
are
actively
discussing
within
the
community.
It's
all
public,
we
discuss
them
in
the
micro
profile,
live
hangout
which,
by
the
way,
is
in
an
hour
and
a
half
from
now.
We
are
trying
to
figure
out.
How
do
we
adopt
the
Jakarta
namespace?
B
When
are
we
gonna?
Do
it
which
micro
profile
release?
Are
we
gonna
wait
a
full
year
until
2021,
or
do
we
break
our
policy
and
do
two
major
releases
within
a
single
year?
So
micro
profile
is
pretty
agile
in
that
respect,
actually
I'm
forward
referencing
again,
but
we
are
pretty
agile.
We
do
make
kind
of
late
decisions,
we
don't
pre
optimize
our
decision-making
so,
but
we
are
trying
to
figure
that
out.
We
are
trying
to
figure
out
Jakarta
technical
life
payment.
B
So
if
Jakarta
EE
wants
to
rely
on
micro
profile
specs
and
we're
moving
kind
of
quickly,
we
have
breaking
changes
once
a
year.
How
does
that
work
with
Jakarta
EE
having
a
very
stable
set
of
api's?
So
that's
a
technical
alignment,
discussion
and
I'll
explain
how
you
can
get
involved
and
learn
more
here
in
a
second
there's.
B
Also
more
around
organizational
structure
and
market
profile
has
to
create
a
working
group
within
the
Eclipse
Foundation
and
what
that
basically
mean
the
reason
why
that
has
to
be
done
is
because
in
in
the
move
of
Jakarta
of
Java
EE
to
Jakarta
in
the
Eclipse
Foundation,
there
was,
you
know,
a
recognition
that
well
we
found
a
gap
in
how
IP
flows
from
vendors,
providing
functionality
down
to
implementers
and
up
to
the
end
users,
so
think
of
it.
B
B
Should
we
have
a
standalone
working
group,
or
should
we
kind
of
align
more
formally
in
a
single
working
group
with
Jakarta
right
with
jacquard
EEE
in
some
form
right
in
some
form
or
another?
And
so
that's
an
ongoing
discussion
and
there's
this
discussion
around
growing
pains,
meaning
that
micro
profile
has
eight
homegrown
specs
that
are
part
of
the
core
platform.
We
now
have
four
standalone
specs
and
we
have
a
fifth
one
on
the
way
that
means
13
specs,
and
so
what
does
it
mean
to
be
core?
What
does
it
mean
to
be
outside
of
core?
B
Do
we
need
to
maybe
have
some?
You
know
categorized
in
micro,
the
reactive
specs
and
some
special
category?
Should
we
get
rid
of
a
platform,
spec
and
or
cores
stand
alone
together,
as
a
call
together
is
a
concept.
I
just
have
a
bunch
of
individual
specs
for
now
that's
kind
of
back-burnered
because
of
all
these
other
conversations
we're
having.
But
it's
something
that
we
is
a
background
conversation
a
little
bit
at
the
moment
and
we're
just
trying
to
figure
out
how
the
spec
should
be
organized
within
micro
profile
right.
So
next
slide.
Please.
B
We
don't
define
process,
he's
upfront,
we
kind
of
move
forward
and
if
something
pops
up
and
we
real
hey,
this
is
a
gap
we
need
to
fix.
Then
we
create
a
process
right.
So
in
a
lot
of
ways.
This
is
what
drives
the
agility
of
micro
profile
to
release
on
the
cadence
that
we've
been
releasing,
so
we're
very
careful
about
inserting
new
processes
into
the
way
we
deliver.
Specs.
We
use
consensus
based
decision
making.
We
hop
on
a
live
hangout.
If
we
can't
make
a
decision
there,
we
kind
of
kick
it
into
the
micro
profile.
B
Mailing
list
or
Google
Group
had
the
discussion
in
there
and
it's
pretty
much
decision
decision
is
consensus
based
and
if
we
can't
come
to
a
consensus
to
date,
we
have
when
we
get
to
the
technical
alignments
and
the
working
group.
Those
are
our
bigger
decisions.
Then
it
goes
back
to
rule
number
one.
B
Maybe
we'll
create
a
process
to
solve
that
problem,
right
to
vote
on
technical
alignment,
working
groups
right,
we
meet
bi-weekly
on
a
live
hangout,
it's
informally,
formal,
meaning
you're,
not
going
to
go
to
the
live
hangout
and
see
this
Robert
rules
of
order,
a
very
strict
way
of
doing
things.
It's
it's
like
going
to
a
Java
user
group
in
a
lot
of
ways
right,
we're
we
all
kind
of
collaborate
and
anyone
can
speak.
Anyone
can
ask
questions,
but
we
do
have
some
structure
right.
B
As
joining
the
Google
group
or
the
minimalist
and
saying:
hey
I
have
an
idea
start
the
discussion
others
will
join
in
if
people
think
it's
a
good
idea,
it's
like
hey,
let's
all
go
to
the
sandbox
and
and
try
it
out
right
and
then
it
can
eventually
mature
into
a
specification
if
there's
enough
kind
of
buying.
You
know
if
you
have
enough
people
interested
to
kind
of
help
you
out
with
it.
So
anyone
can
start
a
specification.
So
take
a
look
at
it
next
slide.
Please.
B
Go
to
start
that
micro
profile
that
I
oh.
This
is
a
lot
like
to
start
that
spring
that
I/o
for
spring
developers,
where
you
can
actually
create
the
outline
of
a
project
using
any
one
of
the
market
profile,
runtimes
right
and
I'll.
Note
that
there's
also
a
couple
of
IDE
plugins
that
will
let
you
generate
micro
profile
projects
using
this
back-end
capability,
so
vs
code
and
IntelliJ
will
actually
call
in
to
have
em
extensions
to
generate
projects
that
really
call
in
to
the
functionality
of
start
that
market
profile
that
IO.
B
So
if
you
want
to
create
a
project,
take
a
look
at
that
next
slide
and
this
might
be
the
last
slide
or
not
yet
yes
get
involved.
These
are
clickable
links.
If
you
want
to
see
how
to
join
the
market
profile,
call
a
live
hangout
in
roughly
an
hour
and
a
half
look
in
the
lower
left
hand,
corner,
there's
a
calendar,
and
it's
got
all
the
all
the
logistics
about
how
to
join
the
live
hangout
or
any
individual
spec
meeting.
B
If
you
don't
want
to
start
a
spec,
but
you
want
to
maybe
join
in
to
an
existing
conversation.
Existing
spec
and
contribute
all
the
meetings
are
in
the
calendar
there
again
the
Google
group
linked
in
the
upper
left-hand
project.
If
you
want
to
kind
of
join
the
discussion,
it's
a
mailing
list
level
and
some
additional
links
as
well.
So
if
you're
interested
definitely
take
a
look
and
les
slide
I
think
they
gave
one
more.
Thank
you
slide,
but
one
more.
Oh,
this
is
a
shameless
plug.
I
forgot
about
this
one.
B
Actually
I
do
a
live
training
every
two
months
at
O'reilly,
where
it
gets
into
a
hands-on
work
with
the
various
micro
profile
specifications.
It's
four
hours,
so
I
can't
cover
them
all,
but
you
can
see
a
list
on
the
left-hand
side.
If
you
can't
commit
to
four
hours
completely
understandable,
you
can
go.
Watch
the
replay
right.
B
So
there's
a
link
at
the
bottom
that
you
can
go,
go
to
and
sign
up
for
the
live
training
at
all
right
next
slide,
and
that's
it.
That's
the
end.
I've
been
tracking
the
chat,
I,
don't
see
a
whole
lot
around
questions
in
the
chat
but
I'm
willing
with
the
one
or
two
minutes
we
have
left
to
handle
questions.
B
How
do
you
test
it?
Maybe
in
a
production
environment,
or
how
do
you
check
it?
So
it
depends
you
can
either
if
you're
running
in
docker,
there's
a
health
check
capability
in
docker,
where
you
can
either
in
your
docker
file
and
your
docker
compose
file
or
even
on
the
docker
run
command
line,
specify
a
command
to
run
that
checks
the
health
of
the
application.
So
basically,
what
you'll
be
doing
in
the
case
of
docker
I
think
is
actually
shelling
into
the
container
running
your
app.
B
B
If
it's
healthy
or
unhealthy
and
I
think
when
you
get
to
docker
swarm,
it
will
actually
provide
maybe
some
additional
capability
of
killing
a
container
and
restarting
it.
If
it's,
you
know
unhealthy
for
too
long
from
a
kubernetes
perspective,
there's
a
health
check
probe
that
you
would
define
in
your
yeah
Mille
in
your
deployment,
yeah
Mille
and
there
you
can
either
do
an
HTTP
and
it'll.
It's
basically
a
this
is
an
HTTP
continue
and
there's
a
response
close
like
I,
think
it's
501
on
a
failure
and
a
502.
B
Let's
see
the
cycle
500
or
501
anyway,
the
500
error
range
for
if
an
application
is
either
unhealthy
or
not
ready,
like
I
mentioned
so
with
just
a
simple
yeah
mole
command,
kubernetes
can
check
that
or
you
can
do
something
as
complex,
like
the
docker
use
case,
shell
into
your
shell
into
your
container
and
actually
run
a
more
command,
part
of
which
might
be
checking
the
health
check
endpoint,
but
maybe
also
running
some
internal
commands
as
well
within
the
container.
So
the
underlying
platforms
container
orchestration
platforms
provide
the
capability
to
check.
A
A
A
Okay,
I'm
dragging
a
little
bit
just
to
see
if
there
are
more
questions,
but
there
seems
no,
we
don't
have
any
questions
John.
Thank
you
so
much
reminder
that
John
will
update
couple
of
slides
with
their
titles
and
you
can
you
also
use
the
slides
as
well
for
the
reference
looking
forward
to
the
update
on
for
so
stay
tuned
for
that
session.
Once
we
have
that
release?
Okay
thanks
everyone
and.