►
Description
Speaker: David Belvins
This session gives a short overview of where JMS 2.0 left off and details potential directions for Jakarta Messaging. Attendees should come for education, information on how to participate, and inspiration to roll up their sleeves and help define the future.
///GET SOCIAL!
Subscribe: https://www.youtube.com/user/EclipseFdn
Follow us on Twitter: https://twitter.com/JakartaEE
Follow the conference: https://twitter.com/JakartaOneConf
Like us on Facebook: https://www.facebook.com/JakartaEE/
Become a member of our Jakarta Tech Talks Meetup: https://www.meetup.com/jakartatechtal...
Join us on LinkedIn: https://www.linkedin.com/groups/13597...
Tag us: #JakartaEE #JakartaOneLivestream
A
B
Absolutely-
and
you
know
thanks,
everybody-
who's
been
hanging
out
all
day,
it's
an
incredibly
long
day
of
sessions
both
for
the
organizers
and
the
speakers,
and
it's
really
great
if
you're
still
hanging
around
this
far
after
all,
all
that
we've
seen
today,
okay,
so
I'll,
be
presenting.
You
know
a
topic,
that's
dear
to
my
heart,
which
is
Jakarta
messaging,
so
there's
quite
a
long
history.
B
Behind
this
feature
and-
and
so
I
wanted
to
give
some
perspective
on
it,
and
it's
one
of
those
things
that
didn't
you
know
actually
make
the
Jakarta
Java
EE
8
release
before
it
was,
you
know,
basically
stopped
so
so
this
is
our
chance
to
to
kind
of
you
know,
revisit
something
from
the
past
and
get
it
up
to
speed
and
take
it
a
lot
further
and
so
just
before
I
get
started.
If
you
have
any
questions,
please
do
ask
them
during
the
talk.
B
So
we
have
a
very
packed
agenda
here
and
please
do
let
me
know
if
I'm
losing
you
or
you
getting
confused.
So
a
high-level
is
we're
going
to
take
a
look
at
where
things
left
off
in
JMS
2.1
and
how
things
are
looking
with
with
what
our
options
are
for
Jim
for
basically
what
is
now
called
Jakarta
messaging
under
the
Jakarta
e
space,
we're
gonna
see
what
what
API
options
were
there?
B
What
was
the
work-in-progress
and
what
could
we
possibly
do
with
it
and
what
we're
going
to
call
Jakarta
messaging
3.0?
So
we
opted
for
four
three
versus
calling
it
2.1,
because
the
changes
that
we
have
in
mind
are
just
too
large
so
before
we
do
that
the
two-minute
perspective
of
JMS
2.0,
so
JMS
2.0
really
tried
to
improve
the
kind
of
ceremonial
requirements
for
creating
and
sending
messages
and
both
consuming
messages.
B
So
here's
what
I
like
a
JMS
1.1
consumer,
would
you
know
sender
would
look
like
you
know
it's
it's
a
lot
of
boilerplate
we've
got.
You
know
some
some
duplication
going
on
here
and
it's
it's
a
little
bit
thick.
We
survived
with
this
for
many
many
years
and
then
j-
2.0
basically
broke
that
down
to
be
significantly
smaller
than
it
was
before.
We
have
the
usage
of
auto
closable
to
make
the
trying
with
resources
happen
and
then
once
we
actually
get
down
to
it.
B
This
is
also
a
builder
API,
so
before
we
have,
we
had
to
create
all
these
objects
and-
and
if
you
wanted
to
set
various
options
on
them,
you're
looking
at
code
like
this
and
now
with
the
JMS
context,
object
that
was
added
in
JMS
2.0.
We
have
it
to
be
much
more
fluent,
so
everything,
of
course,
is
a
is
a
builder
fluent
API
and
we
can
get
rid
of
all
the
method.
B
All
the
variable
declarations
that
we
were
doing
before
and
just
trim
that
down
where
this
really
paid
off
is
when
we
compare
something
as
simple
as
sending
a
text
message.
So
in
the
past
you
used
to
have
to
you
know,
pass
in
the
destination
here
at
the
top
here
at
the
bottom,
you
got
duplication
and
you
got
in
the
middle,
some
extremely
mundane
boilerplate
for
creating
a
simple
text
message.
The
Builder
API
now
allows
you
to
do
that
much
more
fluently,
and
so
that's
that's.
A
great
entry.
B
Point
into
Jamis
2.0,
but
if
I
were
to
describe
where
JMS
2.0
left
off
and
where
JMS
2.1
was
aiming
to
pick
up
from,
is
I
would
say
in
your
head,
you
should
imagine
them
as
JMS.
2.0
was
very
much
a
programmatic
improvement
of
the
JMS
api.
So
when
I
say,
programmatic
I
mean
writing
code
at
runtime
in
a
method
block.
That
code
got
significantly
simpler.
That
had
builders
that,
under
the
JMS
context,
JMS
producer
and
JMS
consumer,
and
there
was
some
improved
CDI
support
in
the
way
of
allowing
these
objects
to
be
injected.
B
Jms
2.1
was
aiming
to
do
a
very
similar
revamp,
but
adding
annotation
driven
perspectives
on
all
these
things.
So
where
what
you
would
do
to
programmatically,
you
would
instead
do
declaratively
via
new
annotations
that
were
to
be
added,
and
it
was
also
Ted
had
goals
to
add
much
greater
CDI
support,
so
it
didn't
quite
work
out
so
in
Java,
EE
7,
when
JMS
2.0
was
released.
That
was
2013
immediately
afterwards.
We
started
working
on
what
was
to
be
JMS
2.1.
B
We
had
expert
group
meetings
after
code
1
and
so
on
so
forth,
and
we
continued
until
the
slowdown
that
happened
that
we're
all
familiar
with
and
JMS
2.1
was
withdrawn.
Two
years
later
we
were
5
revisions
into
JMS
2.1
and
it
just
you
know
the
plug
got
pulled.
So
of
course,
today
now
we
have
Jakarta
e8
released
it's
2019.
B
We
have
the
opportunity
to
pick
back
up
where
we
left
off
in
2016
and
finished
two
years
worth
of
work,
that
we
did
and
add
some
new
crazy
awesome
ideas.
So
let's
get
an
idea
of
what
it
was
that
we
were
working
towards
in
JMS,
so
before
I
get
too
far
into
that
there's
a
handful
of
ideas
that
we'd
like
to
add
on
top
of
what
we're
doing
in
JMS-
and
these
are
the
really
cool
ideas
that
in
my
mind,
so
you
know.
B
Obviously
I
spoke
a
lot
about
JMS
2.1
now,
but
I
mean
I
actually
was
presenting
JMS
2.1
in
2014,
15
and
16,
and
so
it's
going
to
be
really
great
honor
to
finish
that
work.
But
now
three
years
have
gone
by
and
we've
learned
a
significant
amount
of
things.
So
not
only
are
we're
gonna
pick
up
where
we
left
off
in
JMS
2.1,
but
we
also
have
this
kind
of
laundry
list
of
possible
crazy
ideas.
B
B
So
here
is
a
message
driven
bean.
This
is
the
only
annotated
way
to
consume
a
JMS
message
in
Java,
EE,
8
and
Jakarta
EE
8,
and
you
know
it
there's
several
things
that
are
wrong
with
it.
I
often
feel
like
when
we
added
annotations
in
to
you,
know
Java
EE,
and
we
made
annotation
versions
of
everything
you
know.
Md
B's
were
basically
last
on
our
list.
In
the
EJB
3
point
expert
group,
we
focused
first
on
JPA
and
making
that
JP
was
actually
built
by
the
EG
big
group.
B
Second
order
of
business
was
making
great
versions
of
session
beans,
so
we
made
an
annotated
versions
of
session
beans
and
very
very
last
on
the
list
was
MD
B's
and
we
didn't
do
such
a
great
job
when
we
did
that.
So
so.
Here's
that
here's
a
big
problem
with
it
one
a
user
manual
is
required.
So
if
you
look
at
the
top,
they've
got
these
strings.
B
Okay,
we
got
property,
name
and
property
value,
and
the
issue
with
this
is
that
you
need
to
reference
the
documentation
in
order
to
figure
out
what
properties
can
go
in
this
annotation.
You
know.
The
funny
thing
is
is
that
an
annotation
itself
is
supposed
to
be
strongly
typed
property
names
and
property
values,
but
we
have
totally
lost
the
advantage
of
annotations.
We
have
a
property
called
property
name
and
its
value
is
a
string
and
another
property
called
property
value
in
its
values
of
string.
So
we've
totally
messed
up
here.
B
We
have
no
way
to
actually
know
it,
and
the
other
thing
is
that
these
are
loosely
typed.
So
here
is
a
class
reference
in
a
string.
Now,
if
we'd
miss
tight,
that
it's
not
going
to
it's
going
to
compile,
but
then
we're
going
to
encounter
a
runtime
issue,
if
we
mention
a
class
that
doesn't
exist,
we
have
a
typo.
This
is
the
exact.
This
is
the
exact
definition
of
a
loosely
typed
language,
and
we
should
really
be
struggling
to
get
this
strongly
typed.
B
The
other
thing
that's
wrong
with
this
is
that
I
would
describe
it
as
poor
targeting
so
the
configuration
is
at
the
top
of
the
class,
and
we
have
it
implicitly
applying
to
the
on
message:
method
which
is
below
and
because
we
only
have
one
configuration
at
the
top
of
the
class.
We
can't
have
several
on
message
methods
we
have
just
the
one,
and
so
we
end
up
with
something
that's
very
servlet
like
in
behavior.
B
The
other
thing
is
message
listener,
as
an
interface
basically
defines
this
one
method
and
says
all
messages
you
consume
have
to
come
in
to
you
as
message,
and
you
need
to
do
the
boilerplate
code
to
pick
that
message
apart
figure
out
what
kind
of
message
it
is
and
go
ahead
and
take
action
upon
it.
If
we
compare
this
to
servlets,
this
is
very
much
like
if
you
were
to
do
all
of
your
modern
API
programming.
B
All
of
your
REST
API
is
in
the
servlet
service
method
right,
it's
ridiculous,
but
we
still
do
this
on
the
JMS
side
of
the
fence
and
I.
Think
it's
truly
one
of
the
reasons
why
you
know
it
is
so
difficult
to
use
as
we've
learned
that
you
can't
get
by
with
one
big
service
method
that
takes
HTTP
requests
and
HP
responds
and
you've
got
to
pick
all
the
stuff
out
of
it.
It's
much
better
that
you
have
an
annotation
API
that
you
can
describe
what
you're
after
and
have
them
basically
hand
it
to
you.
B
So
this
is
so
2004
all
right.
Learning
from
jax-rs
jax-rs,
totally
revamped
how
you
consume
HTTP
messages
and
instead
of
using
servlet
API,
you
can
use
this
API.
It's
got
no
interfaces.
It's
got
full
annotation
based
API
for
for
describing
what
HTTP
messages
you
want
passed
into.
What
methods
you
want!
You
can
have
several
methods
that
consume
messages,
not
just
the
one
servlet
service
method
or
the
do
get,
and
it's
all
very
strongly
typed.
B
It's
very
self
documenting,
because
if
you
want
to
know
what
options
you
have
you
just
go:
look
in
the
JAXA
rice
API
and
has
all
the
descriptors
for
you.
We've
got
mime
types
built
in
and
everything,
and
so
it
is
a
significantly
better
API
and
if
we
steal
the
concepts
that
jax-rs
brought
into
HTTP
and
apply
that
to
JMS,
we
get
an
API.
That
looks
basically
like
this.
B
Instead
of
having
one
method
that
can
consume
generic
message,
we
opt
for
an
annotation
based
met
in
a
API
that
allows
us
to
declare
up
several
methods.
Okay,
so
this
is
significantly
better.
The
top
of
this
message
has
max
s,
obsessions
and
Max
messages
processions.
Those
could
be
ven.
Those
are
basically,
you
know,
equivalent
to
what
our
vendor
specific
properties,
the
properties
on
top
of
an
MDB,
could
be
a
mix
of
standard
properties
and
vendor
specific
properties.
B
So
it
made
it
truly
difficult
to
know
what
would
be
placed
there,
and
so
this
is
where
JMS
2.1
was
headed.
I'll.
Take
a
look
at
that.
More
specifically,
I
have
code
up
here
in
front
of
us
too,
to
see
so
I
have
a
sinner
kind
of
a
sample
application,
we're
writing
a
build
system
and
on
our
build
system,
we're
gonna,
listen
on
a
build
queue
and
when
a
build
event
comes
in,
we
will
take
and
we'll
make
we'll
grab
the
project
object
as
an
object
message.
B
First
thing
to
notice:
this
is
a
new
annotation.
This
was
the
equivalent.
This
would
be
how
you
would
describe
what
is
effectively
the
same
as
jax-rs
at
path.
So
this
would
be
like
the
Jax
rest.
Add
path.
You
could
identify
the
queue
that
you
wanted
to
listen
on,
give
it
a
name
and
then,
as
messages
appear
on
that
queue,
you
would
be
called
now.
B
Header
and
I
want
and
they're
worse
their
standard
headers
in
JMS,
so
you
could
pass
in
what
you'd
like,
and
you
know
one
of
them
could
be
that
you
want.
You
know
the
topic
given
to
you:
I've
got
the
jail
JMS
correlation
ID,
which
is
something
that
can
be
supplied
on
the
client
side
and
we're
going
to
say
that
that's
the
build
ID,
and
this
is
the
project
we
want
to
build,
and
then
so
we
have
our
our
stuff.
B
So
the
full
breadth
of
annotation
is
that
we're
slated
to
be
added
in
in
JMS
is,
is
2.1?
Is
here
so
there's,
of
course,
aside
from
cue
listener,
there's
equivalent
topic,
listener
method,
there's
also
message
selector,
which
you
could
put
below
your
cue
listener
or
topic
listener.
Annotation
and
say:
I
only
want
messages
that
match
this
pattern
and
and
some
pretty
pretty
basic
stuff.
B
So
this
is
ultimately
a
pretty
good.
You
know
API,
it's
fine,
the
way
it
is
now
so
here's
the
consuming
side
of
that
that
saying
we
have
topic
listener
which
listens
on
our
past,
for
our
pass/fail
notifications
accepts
some
other
basic
data.
So
this
is
a
message.
Property
properties
are
basically
like
custom
headers
in
JMS,
and
we
have
the
ability
to
consume
as
many
custom
messages
as
you
want,
and
then
we
have
our
basic
boilerplate
code
of
pass/fail.
B
B
B
B
B
Alright,
so
let's
go
back:
who
is
throwing
the
JMS
exception?
That
would
be
just
part
of
the
standard
api.
So
you
know
you
don't
need
it
and
that's
that's
boilerplate
that
we
could
be
that
could
be
left
out.
So
you
know
that's
a
good
catch
and
someone's
paying
attention
at
this
late
hour
or
early
hour,
if
you're
in
Japan
or
Australia
yeah.
So
we
wouldn't
need
to
have
that
methods
that
that
that
throws
Clause
there.
B
It
would
be
very
much
like
in
jax-rs
how
you
could
throw
a
you
know
an
exception,
a
strongly
typed
servlet
exception
or
not.
It
would
be
optional,
so
we
don't
actually
need
that
to
make
this
code
compile
and
we'd
be
fine
to
leave
it
off
in
a
night
in
an
API
that
we
made
final,
so
I'm
gonna
actually
check
that
change
in.
B
The
other
thing
that
there's
an
additional
thing
that
I
don't
quite
like
about
this-
is
that
you
know
we
have
these
ability
to
to
specify
all
these
different
properties
that
we
want.
But
if
we
look
at
Jack's
arrests,
we
can
have
strongly
typed
objects
as
header,
params
and
path,
params
and
query.
Params
and
jax-rs
will
figure
it
out.
We
don't
have
to
be
stuck
to
just
string,
int
and
boolean
and
the
primitives
right.
So
that
would
be
the
next
thing
that
we
would
do
is
we
would
add,
equivalent
property
conversion
into
the
API.
B
Like
that,
instead
of
a
build
ID
string,
we're
gonna
make
a
build.
Id
strongly-typed
object.
Okay,
instead
of
having
date
has
a
long.
Let's
have
an
actual
date
object
instead
of
passing
in
project
URL,
which
is
obviously
not
used.
But
for
the
sake
of
an
illustration,
it's
fine
we'll
take
a
URL
we'll
take
a
URI
for
the
build
URL
and
for
build
status,
a
simple
enum
of
pass
and
fail
right.
So
now
we're
no
longer
doing
string
checking
here,
which
is
extremely
error-prone.
B
We
look
at
the
way
we
were
doing
it
before
I
mean
this
code
is
very
susceptible
to
breaking,
and
so
by
making
things
strongly
typed
we
actually
improve
the
API
usage
significantly,
so
we're
good.
This
is
already
an
amazing
set
of
improvements,
but
I
think
we
can
go
much
further
right.
So
there's
been
a
topic
that
I
have
really
talked
about
at
conferences
in
the
past
a
handful
of
times
and
we
never
actually
managed
to
get
too
far
with
it,
and
that
is
the
the
concept
of
meta
annotations
or
what
CGI
has
it's
called
stereotypes?
B
Stereotypes
are
the
first
thing
that
we
can
do
to
really
cut
down
some
of
the
boilerplate
that
we
have
even
with
this
simplified
API.
So
if
I
were
to
go
back
to
this
particular
thing
here
and
we're
to
see
this
now,
I
personally
think
that
is
way
too
long.
I
don't
particularly
enjoy
having
to
use
the
message.
Header
annotation,
with
a
very,
very
long
standard
parameter.
B
B
Turns
into
that
code
significantly
smaller,
how
did
we
get
this
to
work?
Well,
ultimately,
what
this
proposal
would
entail
is
that
we
have
a
in
the
Jakarta
messaging
package
right
here.
This
would
obviously
have
to
be
Jakarta
and
not
Java
X.
We
have
a
standard
at
reply
to
you,
annotation.
It's
marked
as
a
CDI
stereotype
and
uses
the
message,
header
annotation,
and
passes
reply
to
specifies
that
we
can
have
this
on
another
annotation
type
or
a
parameter,
and
then
there
we
go.
B
We've
gone
from
that
to
this,
so
we're
starting
to
enter
way
into
something:
that's
really
good,
getting
more
usable
and
not
too
bad
to
look
at.
So
if
you
can
have
standard
annotations,
if
the
API
can
have
standard
stereo
type
annotations,
that's
great,
for
when
there
are
standard
header
parameters,
but
message
properties
are
of
your
own
creation
right.
So
that
still
leads
you
with
the
with
this
kind
of
garbage
here
at
the
top.
B
If
we
were
to
apply
the
stereotype
concept
to
message
properties
as
well
and
while
we're
at
it,
why
not
to
this
basically
anywhere
that
we
have
a
string
that
might
get
copied
and
pasted
and
typed
wrong
were
made
a
night
maintenance
nightmare.
Let's
put
that
in
to
admit
it
into
a
stereotype
and
make
it
reusable
so
the
better
way
to
do
this.
B
B
Let
me
close
this
down
here
at
the
bottom,
so
if
we
had
the
ability
to
use
stereotypes
in
our
own
code,
we
would
take
that
boilerplate
and
we
would
put
it
here
in
the
meta
in
the
stereotype,
annotation
and
we
ourselves
are
defining
our
own
stereotypes.
So
we
got
org
example
properties
and
we
could
have
all
the
different
application
headers
and
things
that
we
want
to
pass
around
standardly
in
our
define
ourselves
in
our
own
code
and
then
reused
in
our
own.
B
You
know
in
our
own
consumer
methods,
so
jax-rs
doesn't
actually
have
this
concept
because
it's
integration
with
CDI
kind
of
stops
at
allowing
you
to
declare
that
your
being,
is
you
know
a
CDI
being,
but
jax-rs
does
not
try
to
unravel
the
the
CDI
stereotype
magic
to
figure
out.
Are
there
jax-rs
annotations
that
I
should
be
concerned
about
used
in
these
serios
DC
CDI
stereotypes?
So
it's
a
very
significantly
underused
feature
of
CDI.
That
I
would
really
like
to
see
Jakarta
messaging
be
one
of
the
first
brave
specifications
to
actually
go.
B
You
know
what
that
feature
is
amazing.
It
could
really
cut
down
on
the
boilerplate.
It
would
keep
us
from
copying
all
of
our
annotation
data
all
over
the
place.
We
could
make
all
of
our
annotations
all
strongly-typed,
no
string
string
parameters
and
at
that
someday
in
the
future.
We
want
to
rename
what
the
property
is.
We
change
it
in
one
place
and
all
the
code
that
references
this
strongly-typed
annotation
will
magically
be
right.
B
Imagine
how
your
life
is
now
with
Jax
arrest,
and
you
want
to
change
the
name
of
a
path
parameter
that
will
take
you
forever
and
you
better
hope.
You
have
great
tests,
because
you're
gonna
miss
a
couple.
A
string
find
and
replace
is
not
safe.
It
is
very,
very,
very
hard
to
maintain
when
you
have
a
lot
of
it
in
your
code,
so
that
right
there
is
a
very
huge
change
that
we
could
take
advantage
of
to
make
the
Jakarta
messaging
3.0
significantly
better
than
even
jax-rs.
B
So
there's
a
certain
point
where
this
API
potential
catches
up
to
jax-rs
and
then
there's
a
certain
point
where
we
start
going
way
beyond,
and
this
is
one
of
those
areas.
So
another
thing
that
I
still
think
is
wrong
with
this
code.
If
we
go
back
to
this
right,
where
I
left
off
we're
still
doing
some
things
that
I
that
I
don't
particularly
care
for
that's
this
line
right
here,
we're
taking
object
message
as
a
parameter
and
we
are
casting
it
to
project
1.
B
I
would
really
like
to
have
project
be
a
parameter
here,
but
3
I
don't
want
it
to
be
a
binary
object.
It
should
not
be
serialization
if
we're
still
passing
passing
around
serialized
objects
because
we're
using
JMS
it
is
a
huge
huge
no-no.
Serialized
objects
are
very,
very
brittle.
If
you
change
the
class
definition
in
certain
ways,
it
will
totally
break
the
ability
to
deserialize,
and
since
we
have
data
it's
in
apparently
distributed
and
asynchronous,
it
could
take
a
long
time
to
be
consumed.
B
It
could
sit
in
a
queue
or
a
topic
for
a
very
while
for
a
while.
It
is
a
very,
very
dangerous
thing
to
be
doing
so.
A
lot
of
us
are
passing
around
text
message
and
we
are
putting
XML
data
in
there
and
then
we
have
to
use
Jack's
B
or
something
of
the
sort
to
marshal
that
so
that
adds
to
the
boilerplate
code
that
we
have
again
jax-rs
simply
says.
If
you
have
mime
types-
and
you
tell
me
what
you
want,
what
you're
giving
me
you're
giving
me
an
application.
B
B
If
we
take
a
look
at
it,
it's
got
JSON
B
property
order
on
it.
It's
got
Jason
V
properties,
and
so
we're
going
to
assume
that
the
message
that
we
get
is
a
text
message
and
that
it
can
be
marshaled
to
something
from
JSON
into
into
this,
and
then
the
you
know
the
basically
the
JMS
connector
that
drives
all
this
would
figure
it
out.
B
Just
like
Jack's
beat
up
just
like
jax-rs
does
one
of
the
tricks
to
making
this
work,
which
was
something
we
need
to
solve,
is
HTTP
has
explicit
content
types,
and
so
we
would
need
to
add
a
very
similar
type
of
concept
into
JMS,
so
we
could
communicate
in
an
outgoing
message.
What
type
of
content
is
in
that?
If
it's
a
text
message
is
that
application
JSON?
Is
that
application
XML
right
now,
there's
no
standard
header.
B
For
that,
so
we
would
need
to
add
a
standard
JMS
header
that
could
basically
be
something
like
content
type,
and
so
that
would
be
one
of
the
necessary
tweaks
that
we
would
have
to
do
into
the
JMS
api
itself
in
order
to
support
the
idea
that
we
could
use
JSON
v
and,
of
course,
perhaps
JSON
Jack's
be
for
XML
version
to
do
that
marshalling.
But
if
we
do,
the
payoff
is
is
quite
significant,
because
now
we
no
longer
need
to
be
accepting.
B
I
personally
think
this
is
way
too
much
code
for
sending
messages.
We
have
this
nice
new
annotation
based
API
that
allows
us
to
describe
in
annotations
how
we
want
things
basically
moved
into
our
code.
The
JMS
message
disappears
and
now
we're
dealing
with
project,
and
so
you
know
we're
we're
we're
telling
the
JMS
implementation
or
that
now
the
Jakarta
messaging
implementation.
B
Just
like
jax-rs
give
me
my
code,
don't
give
me
the
objects
that
you
want,
and
so
that's
great
for
the
consuming
side,
but
on
the
producing
side
we're
still
dealing
with
the
boilerplate
API,
and
so
this
is
sort
of
a
newer
concept
and
I.
Don't
know
if
you're
familiar
with
the
micro
profile,
rest
client,
but
if
you're,
not
it's
incredibly
incredibly
clever,
so
I
have
a
quick
example
in
a
blog
post
to
show
you
that
effectively
looks
like
this.
So
let's
imagine.
A
B
It
is
JMS,
messages
are
in
three
parts,
so
there
are
effectively
message
headers,
which
are
basically
like
standard
HTTP,
headers
they're,
clearly
defined,
and
they
exist
as
metadata
outside
the
message
body
message.
Properties
are
like
user-defined,
HTTP,
headers.
Imagine
in
HTTP,
you
have
X
and
you
make
up
something
that's
effectively
what
message
properties
are,
and
they
also
outside
the
body,
and
so
you
have
effectively
the
two
classes,
headers
and
properties
and
then
the
payload.
B
So
it
would
be
possible
for
us
to
have
a
standard
header
introduced,
called
content
type
and
it
would
never
conflict
with
any
of
your
existing
code.
That
might
have
had
a
message.
Property
called
content
type
because,
unlike
HTTP
JMS
actually
has
the
three
things
not
just
two
HTTP
has
all
headers
and
then
the
body
and
your
hands
and
the
standard
headers
are
mixed
together
and
in
JMS
you
have
a
distinct
section
for
standard
headers,
another
section
for
user-defined
what
they
call
properties
but
they're,
basically
headers
and
then
the
payload.
B
So
selector
is
basically
like
a
sequel
query
statement
for
JMS
messages
and
you
can
do
evaluations
on
either
JMS
headers
or
JMS
properties,
and
you
can
say
things
like
if
the
property
name
is
here
and
it's
an
integrator
than
0
I
want
that
message.
So
they're
pretty
they're,
pretty
cool,
ok,
so
back
on
to
the
concept
of
how
we
might
reduce
this
boilerplate
code,
and
so
we're
on
to
the
last
section
of
this
and
I
hope,
I'm
not
going
way
too
fast.
B
It's
one
of
those
things
when
you
don't
have
a
live
audience
in
front
of
you.
You
don't
see
that
confused
looks
on
people's
faces
to
know
to
stop
and
explain
something
a
little
longer.
So
you
know
I'm
available
for
questions
now.
Please
do
ask
them
now
and
of
course
we
can
have
some
QA
at
the
end
of
the
session
as
well,
and
then,
of
course,
there's
Twitter.
B
So
so
back
on
to
this,
so
micro
profile
introduced
a
concept
which
is
basically
strongly
typed
clients,
and
it
takes
advantage
of
the
fact
that
jax-rs
is
ultimately
an
incredibly
strongly
typed
API
of
your
design.
You
simply
describe
your
API
using
Jack's
or
annotations,
but
it's
largely
your
objects
going
in
and
out,
and
so
what
jax-rs
says
with
with
with
micro
profile,
rest
client,
this
concept
it
adds.
It
says.
Let's
say
you
have
a
jax-rs.
B
Application
arrest,
endpoint
that
looks
like
this:
it's
got
movie
find
movie,
can
be
marshaled
with
JSON
B,
so
it's
application
type
JSON
it
takes
a
pass
per,
am
a
long
which
could
be
the
idea,
the
movie
that
you
want
and
it
does
a
simple,
find
and
returns
it.
It
responds
to
messages
on
the
path
endpoint
and
if
you
have
the
ID
as
a
sub
parameter
under
path,
so
movies
slash
ID,
it's
gonna
go
ahead
and
do
its
thing
now.
B
Many
people
are
using
various
HTTP
clients
to
call
code
like
this,
but
you're
dealing
with
the
standard
HTTP,
looking
interface,
when,
in
fact,
if
you
take
away
these
annotations,
what
you
have
is
real,
just
a
basic
Java
object,
and
so
the
micro
profile
rest
client
says:
let's
take
advantage
of
these
annotations
that
are
describing
in
great
detail
how
the
message
needs
to
be
taken.
Apart
pushed
into
the
various
object
types
and
given
to
the
class.
Let's
do
the
reverse
on
the
client
side,
take
the
same
and
use
them
to
build
an
HTTP
message.
B
B
B
B
Ultimately,
here's
how
it
would
look
in
practice
build
and
notify
now
no
longer
has
that
big
thing.
We
were
dealing
with
the
JMS
message
producer
and
the
Builder
and
all
the
various
things.
Instead,
we
would
simply
take
just
like
with
a
micro
profile,
rest
client.
We
would
go
something
like
messaging
client
builder
new
builder.
B
We
would
pass
in
perhaps
the
connection
factory
that
we
got
injected,
so
we
don't
have
to
do
any
plumbing
or
just
say,
here's
the
the
the
JMS
you
know
broker
I,
want
you
to
talk
to
you
and
then
give
me
a
strongly
typed
view
on
top
of
all
the
topics
and
queues
as
defined
by
this
interface,
and
if
we
look
at
it
basically,
what
we'd
have
is
something
that's
an
interface
version
of
the
listener
code
that
we've
been
looking
at
the
entire
time.
So
it
has
the
same
annotations
that
we're
using
to
consume
messages.
B
B
We
had
a
very
verbose
way
of
sending
messages
and
then
1.1
we
cleaned
it
up
and
in
2.0
we
cleaned
up
further,
but
it
still
doesn't
quite
feel
like
a
regular
Java
code.
It
still
feels
like
I'm,
sending
a
JMS
message.
So
what
is
your
first
instinct
as
a
developer?
You're
gonna
abstract
that
out
you're,
going
to
put
all
that
code
into
a
piece
of
into
it
into
a
wrapper
which
you
give
to
everybody
else,
and
then
it
can
call
your
wrapper
your
wrap.
It
will
build.
The
JMS
object.
B
B
So
we
would
have
effectively
created
an
API
where
all
the
boilerplate
is
gone
when
we
consume
a
JMS
message,
but
we
want
to
produce
one
all
that
boilerplate
is
still
there,
and
you
know
that
is
the
kind
of
genius
that
the
micro
profile
restclient
adds.
Is
it
says
these
two
things
are
two
sides
of
the
same
coin.
B
That
definition
that
describes
the
server
side
can
be
the
definition
that
describes
the
client
side
because
they're
both
supposed
to
match
up,
and
so,
if
we
take
that
perspective-
and
we
add
it
into
messaging,
along
with
the
improvements
that
we
want,
we
end
up
with
a
strongly
type,
sending
API
any
typed
consuming
API.
And
if
we
look
at
how
all
these
things
look
and
feel
together.
B
Our
total
set
of
improvements
basically
boil
down
to
this,
whereas
before
we
had
a
pretty
significant
amount
of
garbage
going
on,
we've
now
shrunk
it
down
to
the
most
minimal
piece
of
code
that
you
could
possibly
have
I
guarantee.
This
is
absolutely
different
than
anything
you're
looking
at
with
with
JMS
right
now,
and
if
we
were
to
get
this.
These
improvements
added
into
the
Jakarta
messaging
I
mean
maybe
3.0
isn't
a
big
enough
version
number
increment.
B
It's
it's.
You
know
I
it's
difficult
to
enumerate
the
various
ways
that
it
would
be
awesome,
and
that
brings
me
you
know
to
to
the
final
thing
is
that
this
is
a
bunch
of
crazy
ideas
and
none
of
them
are
real,
and
when
we
go
to
do
these,
your
input
is
absolutely
necessary
to
make
this
stuff
happen.
We
need
people
to
show
up
on
the
mailing
list.
We
need
people
to
get
involved.
We
need
people
to
give
their
best
ideas
and
how
to
improve
this
stuff.
B
B
Let's
get
you
on
the
JMS
message
list
right:
there
follow
the
JMS
API
git
repo,
and
if
you
want
to
see
any
of
this
code
afterwards
or
take
a
look
at
it,
it's
currently
sitting
at
this
repository.
This
is
a
temporary
location.
All
these
ideas
we
got
to
get
moved
into
the
Jakarta
messaging
project
itself.
We've
just
been
so
hands
down
on
getting
jacquard
ee8
out
the
door
that
you
know
whatever
we
could
do
to
get
this
stuff.
B
Just
written
down
is
what
we
did,
but
ultimately
this
is
all
needs
to
go
into
the
Jakarta
messaging
project,
and
you
know
all
of
us
together
really
need
to
work
our
butt
off
to
make
this
stuff.
Real
ideas
are
cheap
and
they
may
seem
impressive,
but
until
someone
puts
the
work
in,
you
know
they're
just
ideas,
it's
just
a
slide.
You
can't
run
a
slide.
B
A
B
It
potentially
could
I
mean
you
know:
I
I,
don't
have
any
ideas
baked
in
advance.
That
would
take
advantage
of
that.
Certainly
it
is
a
certainly.
There
are
plenty
of
functional
opportunities
in
messaging
in
general.
Right
instead
of
having
annotation
based
and
functional
opportunities,
could
you
know
there's
a
lot
of
functional
opportunities
that
are
different
than
the
annotation
based
versions
right,
so
in
an
annotation
based
API,
you
say:
there's
my
method.
B
B
It
is
I'm
giving
it
to
you
right
now
call
that
when
all
the
things
that
I've
built
up
here
happen-
and
so
there
is
definitely
an
opportunity
for
functional
api's
in
messaging
and
definitely
in
Jakarta,
messaging
and
I-
don't
have
any
of
them
baked
up
right
now
and
that
just
goes
to
show
why
it's
super
important
to
have
many
many
people
on
the
project.
Thinking
about
all
the
different
ways
that
we
can
improve
the
messaging
API
and
so
I
would
say
that's
a
fantastic
suggestion
and
all
and
I
would
definitely
hope.
B
I
don't
know,
I
can't
quite
see
who
asked
it
and
yep.
So
I
really
hope
to
see
you
on
the
the
list
and
if
you
have
any
kind
of
thoughts
on
how
that
might
look,
I
would
really
love
to
see
him,
and
so
you
know
definitely
definitely
do
do
come
over
and
say,
hi
and
and
and
even
if
it's
just
a
question,
maybe
somebody
else
has
an
idea
on
how
to
do
it
right.
People
underestimate
the
impact
of
a
really
good
problem.
B
I
actually
have
a
you
know,
philosophy
on
problems
that
the
more
vividly
you
describe
the
problem,
the
better,
the
qualities
of
a
solution
that
comes
along
round
later,
and
so,
if
you
have
a
specific
use
case
in
mind,
that's
really
the
best
thing
to
to
you
know
to
bring
to
the
project.
So
you
may
not
have
the
best
solution,
but
if
you
have
the
best
problem,
you
win.
B
B
I'm
not
terribly
familiar,
but
I
will
simply
say
message:
selectors
predate
AMQP,
and
so
you
know
AMQP
came
along
later,
and
so
there
will
definitely
be
some
representation
of
them
in
AMQP,
but
I'm,
not
an
expert
in
that
protocol
to
be
able
to
answer
the
question.
I
would
just
simply
say
that
in
the
original
JMS
API,
when
you're
building
up
your
consumers
and
things
like
that,
you
can
say
in
a
sequel
like
syntax.
You
know
select
me
these
messages.
You
know
yes,
I'm
listening
to
this
topic
or
yes,
I'm.
B
Listening
to
this
cue,
but
I
only
want
messages
from
the
keyword
topic
that
matched
this
pattern
and
it
allows
you
to
you
know
to
basically
specify
you
know
filters
on
top
of
the
such
properties
and
message
headers.
So
I
don't
have
the
specific
answer
to
that
question,
but
I
hope
I've
described
it
more
readily
for
you
to
to
imagine
how
that
how
they
work
and.
B
Don't
work
on
open
MQ,
so
you
know
Tommy
tribe
commercially
supports
activemq.
We
have
a
number
of
customers
who
use
activemq
and
Tommy
uses
activemq,
and
it's
an
Apache
project
and
Tommy
tribe
supports
basically
everything
jacquard
EEE,
that's
Apache
and
so
I
personally
wouldn't
be
doing
any
implementation
work
over
an
open,
MQ
and
just
FYI.
That
Jakarta
doesn't
have
reference
implementations
anymore.
So
jacquard
is
a
competitive
space
where
an
idea
is
thrown
out
and
the
first
implementation
to
pass
the
TCK.
For
that
idea.
B
That's
enough
to
call
the
specification
finished.
There
may
be
two
implementations
or
one
implementation
or
four,
and
so
there
is
no.
This
is
the
one
special
implementation.
That's
a
little
bit
more
equal
than
all
the
other
implementations.
And
so
you
know
people
are
definitely
welcome
to
go
contribute
these
types
of
concepts
into
open,
MQ
I'll
be
working
on
ActiveMQ,
and
so
you
know,
whichever
one
you
like
go
ahead
and
contribute.